bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potential bug in library search for libiconv in static build


From: gmail
Subject: Re: Potential bug in library search for libiconv in static build
Date: Tue, 05 Apr 2011 21:22:26 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9


Hello,

I have to apologize because i have not fully read you, there probably a more efficient way to deal with static librariries in the iconv distribution.
Therefore, the suggested patch was of no use.

Another point, i see that the tests/intl2.sub make a direct call to a "/usr/bin/printf" command.

Considering the bash package provide a builtin printf and no printf binary, i wonder if this is a test to check the underlying coreutils... Perhaps because the printf coreutils/shutils command was used in the build process and the tests suite should verify it was effectively usable ?

Regards, Cedric.



Hello,


I have take a deep breath and dive in the autotools documentation.

Here is the resulting patch that i think (hope ?) should be ok with any hosts/shells/archs :


--- bash-4.2_static/aclocal.m4.orig 2011-04-03 14:02:35.000000000 +0200
+++ bash-4.2_static/aclocal.m4  2011-04-05 00:24:55.000000000 +0200
@@ -3098,7 +3098,9 @@
           found_so=
           found_a=
           if test $use_additional = yes; then
- if test -n "$shlibext" && test -f "$additional_libdir/lib$name.$shlibext"; then + dnl A shared AND a static version of the same library could be present, + dnl therefore if build is static only the static version must be looked for. + if test -n "$shlibext" && test -f "$additional_libdir/lib$name.$shlibext" && test "$opt_static_link" = no; then
               found_dir="$additional_libdir"
               found_so="$additional_libdir/lib$name.$shlibext"
               if test -f "$additional_libdir/lib$name.la"; then
@@ -3120,7 +3122,9 @@
               case "$x" in
                 -L*)
                   dir=`echo "X$x" | sed -e 's/^X-L//'`
- if test -n "$shlibext" && test -f "$dir/lib$name.$shlibext"; then + dnl A shared AND a static version of the same library could be present, + dnl therefore if build is static only the static version must be looked for. + if test -n "$shlibext" && test -f "$dir/lib$name.$shlibext" && test "$opt_static_link" = no; then
                     found_dir="$dir"
                     found_so="$dir/lib$name.$shlibext"
                     if test -f "$dir/lib$name.la"; then



04/04/2011 16:04, Chet Ramey :
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]