Hi,
Original question:
> I have been trying to setup xfig on a Tru64 v5.0A using gcc. In amongst
all
> the things one has to get before even getting down to xfig, for jpeg
support
> you need
> (a) zlib
> (b) libpng
> (c) jpeg
>
> Having collected all this stuff and copyied libs and .h files to the
> appropriate places (because some of these packages don't seem to want to
> install what I would call properly), I tried to setup xfig. Ignoring all
the
> warnings, it got down to the load and reported
> Unresolved:
> jpeg_std_error
> jpeg_destroy_decompress
> jpeg_CreateDecompress
> jpeg_stdio_src
> jpeg_read_header
> jpeg_start_decompress
> jpeg_read_scanlines
> jpeg_finish_decompress
> __builtin_va_start
> collect2: ld returned 1 exit status
> make: *** [xfig] Error 1
>
> I just don't get it, the end of the compile line that generated this
message
> looks like this
> -L/usr/local/lib -ljpeg -lpng -lz -lXi -lXaw -lXmu -lXt -lSM -lICE
-lXext
> -lX11 -lm
>
> which I guess is saying that it is looking in /usr/local/lib for the file
> libjpeg, but not finding it, maybe it is looking for a libjpeg.so file
> instead of libjpeg.a. So far I have only been able to generate a libjpeg.a
> file. I have used stdump -c on libjpeg.a and the symbols are definitely in
> the file. I also made a link in /usr/lib pointing to the .a file. I tried
to
> create a .so file, but when I added --enable-static to the ./configure
> command, the thing went off and tried to check on the OS and the chip, and
> failed because it didn't like version 5 or ev6 (I couldn't track down how
it
> was doing the check in the configure file - I could see the general area,
> but it must of been calling something to do the check, plus it was mixed
in
> with other checks (like libtool) that may or may not have been switched
on).
>
>
> It would also appear that besides the jpeg stuff there is a
builtin_va_start
> symbol that is missing.
>
> If anyone has any ideas on how to solve for the missing symbols, I'd
> certainly like to hear from you. If I get no joy then I guess I could
switch
> off jpeg support in xfig.
Answer:
The problem with the jpeg stuff is that the the java stuff that is loaded as
part of the OS creates a link in /usr/shlib called libjpeg.so, and either
this dir is searched before /usr/local/lib or preference is given by the
loader for .so libraries over .a libraries. To overcome this, I renamed my
/usr/local/lib file to libjpeg2.a and changed the local library definition
in the Makefile to jpeg2. I guess if I was really smart I should have been
able to force the loader to create a static version of the program, which
should of skipped over the shared libraries.
As for the missing builtin_va_start, that was resolved by using cc instead
of gcc. Maybe, I could of got hold of the gnu ld which is packaged in
binutils distribution, instead of using Tur64 ld.
Thanks:
Dan Riley [dsr_at_mail.lns.cornell.edu] who answered all the questions and
included a way of making a shared lib from a .a file (vis ld -shared -o
libjpeg.so -all /usr/local/lib/libjpeg.a -none -lc)
and others who basically knew that Tru64 stuck shared libraries in a
directory called /usr/shlib
Thomas M. Payerle [payerle_at_physics.umd.edu]
bob.marcan_at_aster.si
LHERCAUD_at_bouyguestelecom.fr
Peter.Stern_at_weizmann.ac.il
Uwe Lienig [Uwe.Lienig_at_fif.mw.htw-dresden.de]
Olle Eriksson [olle_at_cb.uu.se]
Long live the list.
Dennis
######################################
Dennis Macdonell
Systems Administrator
National Mapping Division, Geoscience Australia
mail: PO Box 2, Belconnen, ACT 2617
email: mcdonell_at_auslig.gov.au
ph: 61 2 6201 4326
fax: 61 2 6201 4377
######################################
Received on Fri Jan 11 2002 - 01:25:14 NZDT