Bug 3635 - undefined symbol: _fxstat in libtiff.so
Summary: undefined symbol: _fxstat in libtiff.so
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ld.so
Version: 6.0
Hardware: sparc
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-22 12:45 UTC by shadow+junk
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-10-05 06:04:11 UTC
Embargoed:


Attachments (Terms of Use)

Description shadow+junk 1999-06-22 12:45:40 UTC
It seems that the libtiff that comes with 6.0 has a problem;
I tried using
ee to open a tiff file, and got:
error in loading shared libraries: /usr/lib/libtiff.so.3:
undefined
symbol: _fxstat
So, for the heck of it, I nm'd the static version (as close
as i could to
nm'ing the shared lib)
nm libtiff.a|grep fxs
                 U __fxstat
and then /usr/lib/libc.a:
nm /usr/lib/libc.a | grep fxs
...
fxstat.o:
0000000000000000 T __fxstat
0000000000000000 W _fxstat
fxstat64.o:
0000000000000000 T __fxstat64
                 U __fxstat
...

So I tried rebuilding libtiff.so.3.4 and explicitly linking
it against libc, still no dice.
More reading revealed that I should look at
/usr/lib/libc.so, and some other comments hinted that
/usr/lib/libc_nonshared.a needed to be linked in, so I tried
linking *that* into libtiff.so, and that didn't help either.
The reference is being inlined correctly but failing to be
resolved. This is presumably actually a dynamic linker
problem since ee is not linked against libtiff. This
indicates it's being dlopen'd. Note that this works just
fine on Redhat 6.0/intel, making the sparc dynamic linker
"different".

Comment 1 Derek Tattersall 1999-06-29 15:51:59 UTC
Note that this seems to occur only on sparc.

Comment 2 Cristian Gafton 1999-07-28 06:39:59 UTC
can I get this verified?

Comment 3 Cristian Gafton 1999-08-24 00:57:59 UTC
assigned to dlt for verification

Comment 4 Cristian Gafton 1999-10-05 06:04:59 UTC
This works for me. There must be some type of other pollution in iyour
environment (like temporarily switching to a different compiler or and
having static object code laying around or soemthing like that?)


Note You need to log in before you can comment on or make changes to this bug.