[parisc-linux] xfree86 4.2.1-9 build problem

[parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

Hi all,
This started out as an issue with glxinfo program in xfree86.

The basic problem is glxinfo (C program) links against libGLU.so
(C++ built library). But glxinfo fails to link using gcc:
...
gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef     -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm -Wl,-rpath-link,../../exports/lib
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
/usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
/usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
collect2: ld returned 1 exit status
...


If I use g++ instead, glxinfo links just fine since libgcc_eh.a gets
picked up automagically. But it seems wrong to require a C program
link using g++.

Is libGLU.so getting built wrong?  (ie resolved in libGLU.so directly)
Or should C programs not use C++ built libs? (How can the author know?)
Or is this a bug in gcc/binutils? (not picking up libgcc_eh.a)

This might be a generic problem since a few other libs on
my box have _Unwind_SjLj_Resume (for example) unresolved:

libasprintf.a
libgmpxx.a
libncurses++.a

thanks,
grant

RE: [parisc-linux] xfree86 4.2.1-9 build problem

[Joel Soete]

Hi Grant,

> Hi all,
> This started out as an issue with glxinfo program in xfree86.
>
>The basic problem is glxinfo (C program) links against libGLU.so
>(C++ built library). But glxinfo fails to link using gcc:
Which gcc release do you used? (i experiment such a pb with gcc-3.0)
[2 weeks ago, Jul 31 exactly, I play to rebuild this pkg with gcc3.3 but
do not encounter any pb?]

hth,
Joel

------------------------------------------------------
Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003.
On s'habitue vite à payer son ADSL moins cher!
Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Carlos O'Donell]

Grant,

> The basic problem is glxinfo (C program) links against libGLU.so
> (C++ built library). But glxinfo fails to link using gcc:
> ...
> gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef     -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm -Wl,-rpath-link,../../exports/lib
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
> collect2: ld returned 1 exit status
> ...

All of those should resolve to /lib/libgcc_s.so, which gcc should
include for you.
 
> Is libGLU.so getting built wrong?  (ie resolved in libGLU.so directly)
> Or should C programs not use C++ built libs? (How can the author know?)
> Or is this a bug in gcc/binutils? (not picking up libgcc_eh.a)

Doesn't look like it. It looks more like gcc broke.

> This might be a generic problem since a few other libs on
> my box have _Unwind_SjLj_Resume (for example) unresolved:
> 
> libasprintf.a
> libgmpxx.a
> libncurses++.a

That's fine, but they should be linked against /lib/libgcc_s.so.
Run ldd on them, followed by 'readelf -a <lib>' and you'll see that 
that libgcc_s.so provides the symbols as GLOBAL DEFAULT and versioned 
correctly.

c.

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> The basic problem is glxinfo (C program) links against libGLU.so
> (C++ built library). But glxinfo fails to link using gcc:
> ...
> gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef     -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm -Wl,-rpath-link,../../exports/lib
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
> collect2: ld returned 1 exit status
> ...

Did you do the build with one of my private builds of GCC?  They were built
with dwarf2 exception support and don't have these symbols in libgcc_s.so.1.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Mon, Aug 11, 2003 at 10:24:57AM -0400, John David Anglin wrote:
> Did you do the build with one of my private builds of GCC?  They were built
> with dwarf2 exception support and don't have these symbols in libgcc_s.so.1.

nope.  I used:

grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc$ gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.3.1/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-sjlj-exceptions --enable-clocale=gnu --enable-debug --enable-objc-gc hppa-linux
Thread model: posix
gcc version 3.3.1 20030626 (Debian prerelease)


I upgraded to gcc-3.3/unstable and got the same result when attempting
to build glxinfo by hand.

grant

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Joel Soete]

> read model: posix gcc version 3.3.1 20030626 (Debian prerelease)
>
>
>I upgraded to gcc-3.3/unstable and got the same result when attempting
>to build glxinfo by hand.

well I just distupgrade my box (unstable) this morning, I so relaunched the
dpkg-buildpackage ... let you inform tomorrow (sorry I need place so I removed
buildtree)

Joel

PS: I presume that packages are the same  

palx2000:~# dpkg -l gcc\* libc6\* binutils\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                    Version                 Description
+++-=======================-=======================-==============================================================
ii  gcc                     3.3-2                   The GNU C compiler.
ii  gcc-3.0                 3.0.4-16                The GNU C compiler
ii  gcc-3.0-base            3.0.4-16                The GNU Compiler Collection
(base package)
ii  gcc-3.2                 3.2.3-7                 The GNU C compiler
ii  gcc-3.2-base            3.2.3-7                 The GNU Compiler Collection
(base package)
ii  gcc-3.3                 3.3.1-1                 The GNU C compiler
ii  gcc-3.3-base            3.3.1-1                 The GNU Compiler Collection
(base package)
ii  gcc-3.3-doc             3.3.1-1                 Documentation for the
GNU compilers (gcc, gobjc, g++)
ii  gcc-hppa64              3.2.3-0.1               Cross gcc for hppa64
ii  gcc-snapshot            20030728-1              A SNAPSHOT of the GNU
Compiler Collection.
ii  libc6                   2.3.1-17.0.3            GNU C Library: Shared
libraries and Timezone data
ii  libc6-dev               2.3.1-17.0.3            GNU C Library: Development
Libraries and Header Files.
ii  binutils                2.14.90.0.5-0.2         The GNU assembler, linker
and binary utilities
ii  binutils-dev            2.14.90.0.5-0.2         The GNU binary utilities
(BFD development files)

palx2000:~# gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.3.1/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-sjlj-exceptions --enable-clocale=gnu --enable-debug
--enable-objc-gc hppa-linux
Thread model: posix
gcc version 3.3.1 (Debian)


------------------------------------------------------
Soldes Tiscali ADSL : 27,50 euros/mois jusque fin 2003.
On s'habitue vite à payer son ADSL moins cher!
Plus d'info? Cliquez ici... http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> I upgraded to gcc-3.3/unstable and got the same result when attempting
> to build glxinfo by hand.

It's not clear what's going on.  Possibly, linking with libgcc.a
is interacting in a bad way with shared libraries linked with
libgcc_s.so.  You can get more info by adding `-Wl,-v' to the link
command.  Adding `-Wl,-debug' to the gcc link command will show
the full `ld' command.

I am certain that the symbols are defined in libgcc_s.so.  It may
be that the linker isn't looking for dependent libraries correctly.
Using the g++ driver or adding `-shared-libgcc' to the link command
should work around the problem.  But I don't think that it should
be necessary.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Mon, Aug 11, 2003 at 01:30:40PM -0400, John David Anglin wrote:
> It's not clear what's going on.  Possibly, linking with libgcc.a
> is interacting in a bad way with shared libraries linked with
> libgcc_s.so.  You can get more info by adding `-Wl,-v' to the link
> command.  Adding `-Wl,-debug' to the gcc link command will show
> the full `ld' command.

-debug output is attached.
`-Wl,-v' only shows the "ld" command. The -debug output has that too.

What's interesting is the "ld" command has "-lgcc-eh" which is where
the missing symbols are defined:
grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume
0000079c T _Unwind_SjLj_Resume
000008d0 T _Unwind_SjLj_Resume_or_Rethrow
grundler <513>pwd
/usr/lib/gcc-lib/hppa-linux/3.3.1


> I am certain that the symbols are defined in libgcc_s.so.  It may
> be that the linker isn't looking for dependent libraries correctly.

I wonder if "-Wl,-rpath-link,../../exports/lib" is the problem.
I'd normally expect an application to use "-L" to specify additional
lib search paths.

> Using the g++ driver or adding `-shared-libgcc' to the link command
> should work around the problem.  But I don't think that it should
> be necessary.

ok

thanks,
grant

[-- Attachment #2: glxinfo.debug --]
[-- Type: text/plain, Size: 4092 bytes --]

grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef     -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm -lgcc_eh  -Wl,-rpath-link,../../exports/lib -Wl,-debug
Convert string '/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/' into prefixes, separator = ':'
  - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/
  - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/
  - add prefix: /usr/lib/gcc-lib/hppa-linux/
  - add prefix: /usr/lib/gcc/hppa-linux/3.3.1/
  - add prefix: /usr/lib/gcc/hppa-linux/
  - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/
  - add prefix: /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/
Convert string '/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/grundler/bin' into prefixes, separator = ':'
  - add prefix: /usr/local/bin/
  - add prefix: /usr/bin/
  - add prefix: /bin/
  - add prefix: /usr/bin/X11/
  - add prefix: /usr/games/
  - add prefix: /home/grundler/bin/
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'ld'
Looking for 'ld'
Looking for 'gnm'
Looking for 'gnm'
Looking for 'nm'
Looking for 'nm'
Looking for 'gstrip'
Looking for 'gstrip'
Looking for 'strip'
Looking for 'strip'
Looking for 'gcc'
Looking for 'gcc'
collect2 version 3.3.1 (Debian) (hppa)
ld_file_name        = /usr/bin/ld
c_file_name         = /usr/bin/gcc
nm_file_name        = /usr/bin/nm
strip_file_name     = /usr/bin/strip
c_file              = /tmp/ccAA0Eun.c
o_file              = /tmp/cc0QBMNA.o
COLLECT_GCC_OPTIONS = '-o' 'glxinfo' '-g' '-O' '-ansi' '-pedantic' '-Wall' '-Wpointer-arith' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wmissing-declarations' '-Wredundant-decls' '-Wnested-externs' '-Wundef' '-L../../exports/lib'
COLLECT_GCC         = gcc
COMPILER_PATH       = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/bin/
LIBRARY_PATH        = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../:/lib/hppa-linux/3.3.1/:/lib/:/usr/lib/hppa-linux/3.3.1/:/usr/lib/

/usr/bin/ld --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o glxinfo /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crt1.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crti.o /usr/lib/gcc-lib/hppa-linux/3.3.1/crtbegin.o -L../../exports/lib -L/usr/lib/gcc-lib/hppa-linux/3.3.1 -L/usr/lib/gcc-lib/hppa-linux/3.3.1/../../.. glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -lgcc_eh -rpath-link ../../exports/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/hppa-linux/3.3.1/crtend.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crtn.o
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
/usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
/usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
collect2: ld returned 1 exit status
[Leaving /tmp/ccAA0Eun.c]
[Leaving /tmp/cc0QBMNA.o]
[Leaving /tmp/ccGtmF6N.ld]
[Leaving glxinfo]
grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ 

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> What's interesting is the "ld" command has "-lgcc-eh" which is where
> the missing symbols are defined:
> grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume
> 0000079c T _Unwind_SjLj_Resume
> 000008d0 T _Unwind_SjLj_Resume_or_Rethrow
> grundler <513>pwd
> /usr/lib/gcc-lib/hppa-linux/3.3.1

Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared
libraries need.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Carlos O'Donell]

On Mon, Aug 11, 2003 at 03:25:47PM -0400, John David Anglin wrote:
> > What's interesting is the "ld" command has "-lgcc-eh" which is where
> > the missing symbols are defined:
> > grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume
> > 0000079c T _Unwind_SjLj_Resume
> > 000008d0 T _Unwind_SjLj_Resume_or_Rethrow
> > grundler <513>pwd
> > /usr/lib/gcc-lib/hppa-linux/3.3.1
> 
> Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared
> libraries need.

Are we not using libgcc_eh to resolve such symbols in libgcc and libc?

c.

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> On Mon, Aug 11, 2003 at 03:25:47PM -0400, John David Anglin wrote:
> > > What's interesting is the "ld" command has "-lgcc-eh" which is where
> > > the missing symbols are defined:
> > > grundler <512>nm libgcc_eh.a | grep _Unwind_SjLj_Resume
> > > 0000079c T _Unwind_SjLj_Resume
> > > 000008d0 T _Unwind_SjLj_Resume_or_Rethrow
> > > grundler <513>pwd
> > > /usr/lib/gcc-lib/hppa-linux/3.3.1
> > 
> > Yes, but libgcc_eh.a doesn't contain the versioned symbols that the shared
> > libraries need.
> 
> Are we not using libgcc_eh to resolve such symbols in libgcc and libc?

Not for versioned symbols.  For that, you need to link with libgcc_s.so
(i.e., the shared version of libgcc).  The g++ driver does this automatically.
You can also add `-shared-libcc' to your link command when using the gcc
driver.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Carlos O'Donell]

jda,

> LIBRARY_PATH        = /usr/lib/gcc-lib/hppa-linux/3.3.1/:/usr/lib/gcc/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../../hppa-linux/lib/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../hppa-linux/3.3.1/:/usr/lib/gcc-lib/hppa-linux/3.3.1/../../../:/lib/hppa-linux/3.3.1/:/lib/:/usr/lib/hppa-linux/3.3.1/:/usr/lib/
> 
> /usr/bin/ld --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o glxinfo /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crt1.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crti.o /usr/lib/gcc-lib/hppa-linux/3.3.1/crtbegin.o -L../../exports/lib -L/usr/lib/gcc-lib/hppa-linux/3.3.1 -L/usr/lib/gcc-lib/hppa-linux/3.3.1/../../.. 

I'm pretty sure according to our discussion on the proper placement of
libgcc_eh that there is a missing "-lgcc_eh" right here (or rather the
next one should be _after_ the crtbegin?). See the wrapping -lgcc_eh 
around -lc and -lgcc

glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -lgcc_eh -rpath-link ../../exports/lib -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/hppa-linux/3.3.1/crtend.o /usr/lib/gcc-lib/hppa-linux/3.3.1/../../../crtn.o
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
> collect2: ld returned 1 exit status
> [Leaving /tmp/ccAA0Eun.c]
> [Leaving /tmp/cc0QBMNA.o]
> [Leaving /tmp/ccGtmF6N.ld]
> [Leaving glxinfo]
> grundler@gsyprf11:/usr/src/xfree86-4.2.1/build-tree/xc/programs/glxinfo$ 

This is an issue we've seen in the detection of unwind info from
autoconf. Glibc has a patch to hack around a proper detection by placing
the appropirate -lgcc_eh in the front.

c.

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Mon, Aug 11, 2003 at 01:30:40PM -0400, John David Anglin wrote:
> Using the g++ driver or adding `-shared-libgcc' to the link command
> should work around the problem.

I already knew g++ did.
I just confirmed adding `-shared-libgcc' did too.

thanks,
grant

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> The basic problem is glxinfo (C program) links against libGLU.so
> (C++ built library). But glxinfo fails to link using gcc:
> ...
> gcc -o glxinfo -g -O -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef     -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11  -lpthread -lm -Wl,-rpath-link,../../exports/lib
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Resume@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Register@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_RaiseException@GCC_3.0'
> ../../exports/lib/libGLU.so: undefined reference to `_Unwind_SjLj_Unregister@GCC_3.0'
> /usr/bin/../lib/libstdc++.so.5: undefined reference to `_Unwind_SjLj_Resume_or_Rethrow@GCC_3.3'
> collect2: ld returned 1 exit status
> ...

Ok, here is what is happening.

First, I gave you the wrong advice on the option to get verbose info from ld.
I gave you the hpux option.  The GNU option is `--verbose' or `-Wl,--verbose'
when using the gcc driver.

Here is the linker path on gsyprf11:

SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib");

Here is where ld found libgcc_s.so.1:
found libgcc_s.so.1 at /usr/local/lib/libgcc_s.so.1

The version of libgcc_s.so.1 in /usr/local/lib is old and appears to have
been built using dwarf2 exception support.

Probably, the version of GCC installed in /usr/local should be removed.
I believe it was the initial port with support for Ada.  However, this
is now part of the regular debian distro.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> Ok, here is what is happening.
> 
> First, I gave you the wrong advice on the option to get verbose info from ld.
> I gave you the hpux option.  The GNU option is `--verbose' or `-Wl,--verbose'
> when using the gcc driver.
> 
> Here is the linker path on gsyprf11:
> 
> SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib");

One further note: The default search path used by ldd doesn't agree
with the default path used by ld.  So, I think binutils and glibc
need to get together on this.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Mon, Aug 11, 2003 at 04:38:06PM -0400, John David Anglin wrote:
> First, I gave you the wrong advice on the option to get verbose info from ld.
> I gave you the hpux option.  The GNU option is `--verbose' or `-Wl,--verbose'
> when using the gcc driver.

ok. -debug was good.

> Here is the linker path on gsyprf11:
> 
> SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib");
> 
> Here is where ld found libgcc_s.so.1:
> found libgcc_s.so.1 at /usr/local/lib/libgcc_s.so.1

ugh. `dpkg -S /usr/local/lib' comes up empty.
I've deleted everything older than a few days (python/texmf remain).
My expectation is hppa64-linux-* tool chain is self contained in
/opt/palinux and can go away when someone points me at a hppa64 .deb.

> The version of libgcc_s.so.1 in /usr/local/lib is old and appears to have
> been built using dwarf2 exception support.
> 
> Probably, the version of GCC installed in /usr/local should be removed.
> I believe it was the initial port with support for Ada.  However, this
> is now part of the regular debian distro.

deleted. Apologies for the goose chase.

But this is probably an excellent example for versioned symbols.
glxinfo would have broken in other weird ways at run time and
would have been even harder to track down.

Now I can go back and rebuild xfree86 again...

thanks,
grant

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> > when using the gcc driver.
> 
> ok. -debug was good.

This shows what collect2 is doing.  It is useful to see the exact way
in which gcc is running ld.  -Wl,--verbose shows what ld is doing.

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[John David Anglin]

> Here is the linker path on gsyprf11:
> 
> SEARCH_DIR("/usr/hppa-linux/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib");

This search path seems somewhat strange.  It appears debian used the
`--with-lib-path=dir1:dir2...  set default LIB_PATH' configure option
in building binutils.  I believe that the default binutils order would
be "/usr/local/lib", "/lib" and then "/usr/lib".

On the otherhand, ld.so has the default order "/usr/lib", then "/lib".
Don't know why the search order for the system directories in glibc
is opposite to binutils.

On gsyprf11, /etc/ld.so.conf contains:
/usr/X11R6/lib
/usr/lib/postfix

So, the dynamic loader will use the following path as the default search:
/usr/X11R6/lib:/usr/lib/postfix:/usr/lib:/lib

The dynamic loader doesn't search /usr/local/lib and it has a different
search order than ld.  Because /usr/local/lib is normally searched before
the system library directories, you have to be careful what you put there.

It would be nice if the linker and dynamic linker were consistent :)

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

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Sun, Aug 10, 2003 at 10:34:57PM -0600, Grant Grundler wrote:
> This started out as an issue with glxinfo program in xfree86.

I've built a full set of xfree86-4.2.1-9 hppa debs with gcc 3.3.1.
(last ones in "testing" are 4.2.1-6 and built with gcc 3.0.1 IIRC)

Public URL	http://gsyprf11.external.hp.com/hppa/xfree86-4.2.1-9/
HP Internal 	http://debian.cup.hp.com/parisc/xfree86-4.2.1-9/

The bits seem to run fine on my c3k...but xpdf still fails:

grundler <513>xpdf -cmap dino31.pdf 
Error: Unresolved inheritance operation
grundler <514>
...
grundler <516>dpkg -l xlibs
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  xlibs          4.2.1-9        X Window System client libraries

*sigh*.
Do I need to restart X11 or something?

grant

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[James Bottomley]

On Wed, 2003-08-13 at 12:53, Grant Grundler wrote:
> grundler <513>xpdf -cmap dino31.pdf 
> Error: Unresolved inheritance operation
> grundler <514>

Hmm, it looks like you still have the libXt problem.  Are you sure you
installed the newly compiled one?

> *sigh*.
> Do I need to restart X11 or something?

I didn't.  All I did was pull libXt.so.6.0 out of the gcc-3.3.1 build
and copy it into /usr/X11R6/lib.  Then xpdf worked for me.

James

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Wed, Aug 13, 2003 at 03:11:42PM -0500, James Bottomley wrote:
> Hmm, it looks like you still have the libXt problem.  Are you sure you
> installed the newly compiled one?

I did...but you are definitely asking the right qustion.
I didn't see:
grundler@debian:~$ ls -l /usr/X11R6/lib/libXt.so*
lrwxrwxrwx    1 root     root           10 Jul 10 11:13 /usr/X11R6/lib/libXt.so -> libXt.so.6
lrwxrwxrwx    1 root     root           17 Aug 12 10:29 /usr/X11R6/lib/libXt.so.6 -> libXt.so.6.0-orig
-rw-r--r--    1 root     root       402072 Aug 11 19:55 /usr/X11R6/lib/libXt.so.6.0
-rw-r--r--    1 root     root       397408 Feb 25 21:57 /usr/X11R6/lib/libXt.so.6.0-orig

deleting the -orig file(s!) and fixing up the symlink(s) got xpdf
working again.  Yeah!
I found 6 or 7 X11/libs had been redirected to the -orig files.

Thanks for asking the right stupid question....and I'll have
to take the blame for leaving -orig files laying around.
Randolph observed ldconfig will fixup the links if something
"newer" (based on filename) is available. And "man ldconfig"
talks about how that works. *sigh*

Besides the /lib and /usr/lib directories (default), ldconfig
also looks at:
grundler <525>cat /etc/ld.so.conf 
/usr/X11R6/lib
grundler <526>


if I can just figure out what's botching the colors for xchat2 now...

thanks,
grant

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[James Bottomley]

On Wed, 2003-08-13 at 16:32, Grant Grundler wrote:
> if I can just figure out what's botching the colors for xchat2 now...

Is this with one of the Visualize cards?  They only do 8bpp at all
resolutions, so if you run a colourful window manager, you run out
pretty quickly.  Even using the default fvwm, I had to run xpdf with a
private colourmap (-cmap option) to get my slides to show up as anything
like reasonable).

A lot of modern applications (particularly of the kde or gnome variety)
pay absolutely no attention to potential colour map limitations and can
blithely request more colours than you have available (and sometimes not
even check for failure returns).

James

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Alan Cox]

On Mer, 2003-08-13 at 23:53, James Bottomley wrote:
> A lot of modern applications (particularly of the kde or gnome variety)
> pay absolutely no attention to potential colour map limitations and can
> blithely request more colours than you have available (and sometimes not
> even check for failure returns).

Set the display to a fixed colour mapping is the simplest approach.
XFree 4.x is quite happy to let you set different visuals and get
things like an 8bit fixed palette

Re: [parisc-linux] xfree86 4.2.1-9 build problem

[Grant Grundler]

On Wed, Aug 13, 2003 at 05:53:33PM -0500, James Bottomley wrote:
> Is this with one of the Visualize cards?  They only do 8bpp at all
> resolutions, so if you run a colourful window manager, you run out
> pretty quickly.  Even using the default fvwm, I had to run xpdf with a
> private colourmap (-cmap option) to get my slides to show up as anything
> like reasonable).

yes. And I'm using fvwm2 which I thought was supposed to be a fairly
(not totally) light weight window manager. I'll see if there are
knobs to reduce the FVWM color consumption.

> A lot of modern applications (particularly of the kde or gnome variety)
> pay absolutely no attention to potential colour map limitations and can
> blithely request more colours than you have available (and sometimes not
> even check for failure returns).

yup - I was looking to find the code to and at least print a warning
so I know that's the problem. I've spent < 1h hunting through the code
to figure out where the colors for the text box was allocated. Haven't
found it yet though.