[parisc-linux] still getting $$dyncall refs in shlibs

[parisc-linux] still getting $$dyncall refs in shlibs

[LaMont Jones]

With the new toolchain, sipp still builds a libsipp.so.3.1 trips the
bug checker.  Checking everything on the system doesn't find any bad
libs.  Here is the build output for libsipp.so:

gcc -pipe -O3 -fPIC -I../libsipp   -c -o rendering.o rendering.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o geometric.o geometric.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o lightsource.o lightsource.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o objects.o objects.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o smalloc.o smalloc.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o transforms.o transforms.c
...
gcc -pipe -O3 -fPIC -I../libsipp   -c -o xalloca.o xalloca.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o phong.o phong.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o strauss.o strauss.c
gcc -pipe -O3 -fPIC -I../libsipp   -c -o teapot.o teapot.c
ld --shared -o libsipp.so.3.1 rendering.o geometric.o lightsource.o objects.o smalloc.o transforms.o viewpoint.o basic_shader.o marble.o granite.o mask.o bozo.o bumpy.o planet.o noise.o bezier.o bezier_lex.o pixelbuf.o torus.o cone.o ellipsoid.o prism.o sipp_pixmap.o sipp_bitmap.o wood.o xalloca.o phong.o strauss.o teapot.o  -soname libsipp.so.3 -lc
ld: bfd assertion fail ../../bfd/elf32-hppa.c:941
ld: bfd assertion fail ../../bfd/elf32-hppa.c:941

Of course, if the assertion failure actually killed the linker, that
would help...

I'm at a loss from here - and give it to those who have a clue...
lamont

Re: [parisc-linux] still getting $$dyncall refs in shlibs

[Matthew Wilcox]

On Thu, May 24, 2001 at 03:32:59PM -0600, LaMont Jones wrote:
> With the new toolchain, sipp still builds a libsipp.so.3.1 trips the
> bug checker.  Checking everything on the system doesn't find any bad
> libs.  Here is the build output for libsipp.so:

I dug up a machine with binutils 2.11.90.0.1 and tried the same thing..

ld --shared -o libsipp.so.3.1 rendering.o geometric.o lightsource.o objects.o smalloc.o transforms.o viewpoint.o basic_shader.o marble.o granite.o mask.o bozo.o bumpy.o planet.o noise.o bezier.o bezier_lex.o pixelbuf.o torus.o cone.o ellipsoid.o prism.o sipp_pixmap.o sipp_bitmap.o wood.o xalloca.o phong.o strauss.o teapot.o  -soname libsipp.so.3 -lc
make[2]: Leaving directory `/home/demo/sipp/sipp-3.1/libsipp'

$ ls -l libsipp.so.3.1
-rwxr-xr-x    1 demo     demo       128429 May 24 15:36 libsipp.so.3.1
$ nm --dynamic libsipp.so.3.1 |grep '\$\$'
         U $$dyncall

so is there some other bug at work here?

> I'm at a loss from here - and give it to those who have a clue...

Likewise, i wish merely to report a data point.

-- 
Revolutions do not require corporate support.

[parisc-linux] Re: still getting $$dyncall refs in shlibs

[LaMont Jones]

> With the new toolchain, sipp still builds a libsipp.so.3.1 trips the
> bug checker.  Checking everything on the system doesn't find any bad
> libs.  Here is the build output for libsipp.so:

Add the following .debs to the list of things that still build borken:
    auto-apt_0.3.11.0.1_hppa.deb
    installwatch_0.5.5-3.0.1_hppa.deb
    libc-client2000_2000cdebian-2_hppa.deb
    libg20_0.42.20010417-1.0.1_hppa.deb
    libmagick++5_5.3.3-5_hppa.deb
    libmimelib1_2.1.0-1.0.1_hppa.deb
    libpam-radius-auth_1.3.11-3.0.1_hppa.deb
    libseal1_1.07-4.0.1_hppa.deb
    sciplot1_1.36-8.0.1_hppa.deb
    sipp_3.1-7.0.1_hppa.deb
    slatec_4.1-4.0.1_hppa.deb

lamont

Re: [parisc-linux] Re: still getting $$dyncall refs in shlibs

[John David Anglin]

> On Thu, May 24, 2001 at 03:59:30PM -0600, LaMont Jones wrote:
> > > With the new toolchain, sipp still builds a libsipp.so.3.1 trips the
> > > bug checker.  Checking everything on the system doesn't find any bad
> > > libs.  Here is the build output for libsipp.so:
> 
> Too much can go wrong building shared libs just using ld.  It's far
> better to build using gcc -shared.  In this case, the problem is that
> the shlib needs to be built linked against libgcc to satisfy the
> millicode reference.

That also applies to libtool which uses `ld' directly.  Gcc will run
collect2 if needed.  This is necessary for correctly processing
constructors and destructors.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Re: still getting $$dyncall refs in shlibs

[amodra]

On Thu, May 24, 2001 at 03:59:30PM -0600, LaMont Jones wrote:
> > With the new toolchain, sipp still builds a libsipp.so.3.1 trips the
> > bug checker.  Checking everything on the system doesn't find any bad
> > libs.  Here is the build output for libsipp.so:

Too much can go wrong building shared libs just using ld.  It's far
better to build using gcc -shared.  In this case, the problem is that
the shlib needs to be built linked against libgcc to satisfy the
millicode reference.

Alan

Re: [parisc-linux] Re: still getting $$dyncall refs in shlibs

[LaMont Jones]

> That also applies to libtool which uses `ld' directly.  Gcc will run
> collect2 if needed.  This is necessary for correctly processing
> constructors and destructors.

Will someone file the defect against libtool, please?

lamont

Re: [parisc-linux] Re: still getting $$dyncall refs in shlibs

[John David Anglin]

> Will someone file the defect against libtool, please?

Done.  There is a PR (objc/2902) against gcc 3.0 (prerelease).  This
is where I noticed the problem first.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)