Hi Arne,
I don't think the symlink is such a big deal, it only makes sure that
some stupid configure scripts with hard-coded library paths find the
loader. Ofcourse it should be better to fix all the sources upstream,
and it's definitly something that should be done. But I don't think
this li
Hi Erich,
>But seperating binaries would mean yet another dependency and again
>an extra package.
>
>
>More flexibility though
Why? You need haserl and pwcrypt anyway, I don't see why seperating
it would be more flexible.
>I disagree about mini-httpd to be part of webconf, both haserl and
>pwcr
Eric Spakman wrote:
Erich,
Sure, I have no problem with backporting this when necessary. Like I
said, buildtool will makes this a matter of minutes. In the case we
change to a new uClibc version, I (we) will keep the previous
crosscompiler around.
I agree that seperating binaries from scripts e
On Thu, 2005-04-07 at 11:56 -0700, Paul Traina wrote:
Hi Paul!
> Warning:The symlink from /lib/ld-uClibc.so.0 -->
> /home/pst/LEAF/buildtool/staging/lib/ld-uClibc.so.0 does not exist,
> this may cause problems with some configure scripts that try to run
> a compiled program
>
>
>
> Do we still
Erich,
Sure, I have no problem with backporting this when necessary. Like I
said, buildtool will makes this a matter of minutes. In the case we
change to a new uClibc version, I (we) will keep the previous
crosscompiler around.
I agree that seperating binaries from scripts eliminates this to s
Eric
Eric Spakman wrote:
Erich,
Webconf is ported to buildtool, so making packages for a new uClibc
version would only mean run buildtool to automatically recompile and
create the packages.
Sure, but will you backport? Separating binaries from scripts eliminates
this. Else one could argue tha
Erich,
Webconf is ported to buildtool, so making packages for a new uClibc
version would only mean run buildtool to automatically recompile and
create the packages.
Eric
-
I recall suggesting this. Just as an example, one fine
