ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi,

I'm developing on LinuxPPC R5, with egcs-1.1.2-12c and
binutils-2.9.1.0.990418-1c installed.  I'm running into a problem with
using the -Bsymbolic flag.  Building a shared library which references
global symbols that are not found in it, we usually use the
--noinhibit-exec flag so that shared library builds even without those
symbols being bound.

The build command looks like this:

    gcc -shared -Wl,-v -Wl,-Bsymbolic -Wl,--noinhibit-exec -o \
     /ax/axexec/axdata/axshlib/libaxel.so -L/ax/axexec/axdata/axshlib \
     -L/ax/axobj/axdata/rts elimports.o elexports.o \
     /ax/axobj/axdata/rts/axel.o

Without the -Bsymbolic flag, the shared library builds fine.  With the
flag, however, it spits out the following errors (which are expected):

GNU ld version 2.9.4 (with BFD 990418)
/ax/axobj/axdata/rts/axel.o: In function `ElfInstallLibModules':
/ax/axobj/axdata/rts/axel.o(.text+0x38): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o(.text+0x48): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o(.text+0x58): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o: In function `ELElfMacroId':
/ax/axobj/axdata/rts/axel.o(.text+0xc0): undefined reference to `ElfGetModuleStartInd'

On other platforms (i.e., Intel, Alpha), we also see these errors, but
because of the --noinhibit-exec flag, the shared library is correctly
built anyway.  But on PPC, ld returns with 1 exit status, and the shared
library is not built.  Not using -Bsymbolic is not an option.

Ideas?

Thanks,
Eric
-- 
Senior Software Engineer / ericding@applix.com               <><
Applix, Inc. / 112 Turnpike Road / Westboro MA 01581-2842

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

At 18:29 16.06.99 , Eric Ding wrote:

>Hi,
>
>I'm developing on LinuxPPC R5, with egcs-1.1.2-12c and
>binutils-2.9.1.0.990418-1c installed.  I'm running into a problem with
>using the -Bsymbolic flag.  Building a shared library which references
>global symbols that are not found in it, we usually use the
>--noinhibit-exec flag so that shared library builds even without those
>symbols being bound.
>
>The build command looks like this:
>
>     gcc -shared -Wl,-v -Wl,-Bsymbolic -Wl,--noinhibit-exec -o \
>      /ax/axexec/axdata/axshlib/libaxel.so -L/ax/axexec/axdata/axshlib \
>      -L/ax/axobj/axdata/rts elimports.o elexports.o \
>      /ax/axobj/axdata/rts/axel.o
>
>Without the -Bsymbolic flag, the shared library builds fine.  With the
>flag, however, it spits out the following errors (which are expected):
>
>GNU ld version 2.9.4 (with BFD 990418)
>/ax/axobj/axdata/rts/axel.o: In function `ElfInstallLibModules':
>/ax/axobj/axdata/rts/axel.o(.text+0x38): undefined reference to 
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o(.text+0x48): undefined reference to 
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o(.text+0x58): undefined reference to 
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o: In function `ELElfMacroId':
>/ax/axobj/axdata/rts/axel.o(.text+0xc0): undefined reference to 
>`ElfGetModuleStartInd'
>
>On other platforms (i.e., Intel, Alpha), we also see these errors, but
>because of the --noinhibit-exec flag, the shared library is correctly
>built anyway.  But on PPC, ld returns with 1 exit status, and the shared
>library is not built.  Not using -Bsymbolic is not an option.

Hmm, what version of binutils are you using on Intel/Alpha? Does it work on 
Intel/Alpha with binutils-2.9.4.0.[3-5]?

In any case, you can try the RPM of binutils-2.9.4.0.5 on 
<ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc> and see if it helps.

Franz.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi Frank,

thanks for your quick reply.  I'm using version 2.9.1.0.15 on Intel.  On
Alpha, I'm using 2.9.1.0.22.

I just downloaded the binutils-2.9.4.0.5 RPM, and it's no more
successful.  :( :(

Eric

>>>>> Franz Sirl <Franz.Sirl@munich.netsurf.de> writes:

> Hmm, what version of binutils are you using on Intel/Alpha? Does it work on 
> Intel/Alpha with binutils-2.9.4.0.[3-5]?

> In any case, you can try the RPM of binutils-2.9.4.0.5 on 
> <ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc> and see if it helps.

> Franz.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

Am Mit, 16 Jun 1999 schrieb Eric Ding:
>Hi Frank,
>
>thanks for your quick reply.  I'm using version 2.9.1.0.15 on Intel.  On
>Alpha, I'm using 2.9.1.0.22.
>
>I just downloaded the binutils-2.9.4.0.5 RPM, and it's no more
>successful.  :( :(

Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's available on
<ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta> as a RPM.

I'm trying to sort out if this is related to newer binutils or if it's PPC
specific.

Franz.

BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi Franz,

>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's
> available on <ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta>
> as a RPM.

> I'm trying to sort out if this is related to newer binutils or if it's
> PPC specific.

just noticed I called you Frank last time.  Sorry 'bout that.  :)

I had a co-worker test out the Intel 2.9.4.0.5 binutils and it worked
without a problem on that hardware platform.

> BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)

I don't have irc access from work (this is irc, right?)...

Eric

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

Am Mit, 16 Jun 1999 schrieb Eric Ding:
>Hi Franz,
>
>>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>> Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's
>> available on <ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta>
>> as a RPM.
>
>> I'm trying to sort out if this is related to newer binutils or if it's
>> PPC specific.
>
>just noticed I called you Frank last time.  Sorry 'bout that.  :)

no problem :-). I didn't even notice...

>I had a co-worker test out the Intel 2.9.4.0.5 binutils and it worked
>without a problem on that hardware platform.

Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
there any chance you can strip that down to a small testcase with a few
symbols? That would help debugging a lot.

>> BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)
>
>I don't have irc access from work (this is irc, right?)...

Yes, irc.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
> there any chance you can strip that down to a small testcase with a few
> symbols? That would help debugging a lot.

Sure can.  Create a file (let's call it foo.c)... it just contains:

     int foo_tester()
     {
          return(twenty());
     }

Then run the following:

     gcc -fPIC -c foo.c

After the compilation, run:

     gcc -shared -o libfoo.so foo.o
     gcc -shared -Wl,-Bsymbolic -o libfoo.so foo.o
     gcc -shared -Wl,--noinhibit-exec -Wl,-Bsymbolic -o libfoo.so foo.o

On Intel, the first succeeds, the second fails (as expected), and the
third succeeds in building a .so file, even with the "undefined
reference" error.

On PPC, the first succeeds, but the second and third both fail.

Eric
-- 
Senior Software Engineer / ericding@applix.com               <><
Applix, Inc. / 112 Turnpike Road / Westboro MA 01581-2842

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

Am Mit, 16 Jun 1999 schrieb Eric Ding:
>>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>> Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
>> there any chance you can strip that down to a small testcase with a few
>> symbols? That would help debugging a lot.
>
>Sure can.  Create a file (let's call it foo.c)... it just contains:
>
>     int foo_tester()
>     {
>          return(twenty());
>     }
>
>Then run the following:
>
>     gcc -fPIC -c foo.c
>
>After the compilation, run:
>
>     gcc -shared -o libfoo.so foo.o
>     gcc -shared -Wl,-Bsymbolic -o libfoo.so foo.o
>     gcc -shared -Wl,--noinhibit-exec -Wl,-Bsymbolic -o libfoo.so foo.o
>
>On Intel, the first succeeds, the second fails (as expected), and the
>third succeeds in building a .so file, even with the "undefined
>reference" error.
>
>On PPC, the first succeeds, but the second and third both fail.

Ok, I've put up a 1b RPM for testing. Let me know if it works as expected. Note
the dev.linuxppc.org has changed IP address, so you might have to use the direct
169.207.161.2.

Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi Franz,

Yes, it works!  At least, it links... :)  There is a strange matter of
it needing LD_RUN_PATH where it seems I didn't need this variable set on
other platforms (according to the ld info page, it should look in
LD_LIBRARY_PATH if LD_RUN_PATH isn't defined).

So now I can say that it links... but Applixware yet does not run.  More
when I discover more...

Eric

>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> Ok, I've put up a 1b RPM for testing. Let me know if it works as
> expected. Note the dev.linuxppc.org has changed IP address, so you
> might have to use the direct 169.207.161.2.

> Franz.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi Franz,

thanks for your help so far.  After upgrading to 1b, linking works, but
actually running against those shared libraries doesn't seem to
necessarily work.  But it's hard for me to tell where the bug is.  

The fact that LD_RUN_PATH needed to be set is still a red flag in my
mind... is that "correct" behavior?  I know that Applixware linked and
ran OK with binutils from R4; would backtracking be an adequate
solution?

Eric
-- 
Senior Software Engineer / ericding@applix.com               <><
Applix Linux Division / 112 Turnpike Road / Westboro MA 01581-2842

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

At 21:54 18.06.99 , Eric Ding wrote:
>Hi Franz,
>
>thanks for your help so far.  After upgrading to 1b, linking works, but
>actually running against those shared libraries doesn't seem to
>necessarily work.  But it's hard for me to tell where the bug is.

If you still have problems after upgrading to 2.9.4.0.6 below, I'm willing 
to look further into it, but I assume it will be difficult, as you don't 
know the exact cause yourself. Can we rule out bugs in your source here? 
Did the executables created with 2.9.4.0.5 on x86 work fine? I'll also post 
my patch for the noinhibit-exec problem on the binutils-list for review 
later today.

>The fact that LD_RUN_PATH needed to be set is still a red flag in my
>mind... is that "correct" behavior?  I know that Applixware linked and
>ran OK with binutils from R4; would backtracking be an adequate
>solution?

Ok, the LD_RUN_PATH should be fixed now with:

ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc/binutils-2.9.4.0.6-1a.ppc.rpm

Franz.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Franz Sirl]

>Ok, the LD_RUN_PATH should be fixed now with:
>
>ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc/binutils-2.9.4.0.6-1a.ppc.rpm

Damned, I forgot a patch, please use the 1b version.

Franz.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)

[Eric Ding]

Hi Franz,

Another one of our developers has installed 2.9.4.0.5 on his x86 box and
it has worked for him.  I'm still having problems with 2.9.4.0.6 (though
no longer with LD_RUN_PATH).  Again, everything links, but the
executables themselves don't run correctly.

While I can't give you a very small test case, do you think you could
work with a somewhat weightier one?  The SHELF open source package is
the core of Applixware, and exhibits the same problems as Applixware as
a whole.  If you'd be willing to download the source, and do a build (I
could give you step by step instructions), then you would be able to
duplicate our issues, hopefully.  The source download is anything but
small -- it's a weighty 6.8 MB.  But the build process is relatively
simple.

What do you think?

Thanks,
Eric
-- 
Senior Software Engineer / ericding@applix.com               <><
Applix Linux Division / 112 Turnpike Road / Westboro MA 01581-2842

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]