On 4/3/11 9:01 AM, gmail wrote:
> Hello,
>
> This is my first contact and mail with bash mailing list, to summarize i'm
> a coder maintening a personnal home server using several GNU tools since
> the late 90's.
>
>
> I configure BASH-4.2.0 in a chroot jail (gcc 4.5.2/libc 2.13/binutils
> 2.21/make 3.82) with an athlon architecture on ext3 FS with
> --enable-static-link --with-libiconv-prefix=/ and, as root, and notice the
> configure script can't find the jail's static libiconv :
> [...]
> So, as you could see, the configure script try to build a static elf by
> linking object output with a shared libiconv.so library.
> Guessing that this behavior was not the script real goal, i then adapt the
> configure script this way :
It's usually better to modify configure.in/aclocal.m4 and then rebuild
configure, but I see what you're trying to do. I picked up these macros
from the libiconv distribution, so I'll have to take a look at what that
distribution needs to inhibit searching for static libraries. It's
probably something as simple as setting a different shell variable in
configure.
> For information, the configure script needs other adaptations to produce a
> functionnal STATIC bash elf with glibc 2.13 due to specific dlopen issue.
> I have currently inhibit getaddrinfo, gethostbyname, getpwent, getpwam,
> getpwuid, getservbyname, getservent use in configure script when STATIC
> build is required and alter some sources to behave differently if in static
> build.
> This way i have actually a functionnal static bash 4.2 elf which passes all
> the tests except the multybite printf2.sub test (return 195 and not 192,
> i'm currently investigating).
> I can provide the related patchs, if you think it's worth it.
Sure, I'd be interested in taking a look at your patches. Note that this
is mostly a linux-specific issue.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
