compilation issue on Irix 6.3



I have encountered an interesting compilation issue with libgnorba in
the libgnome package on Irix 6.3 using gcc version 2.95.2 19991024
(release).  ld32 attempts to link loadshlib, I receive the following
error:

ld32: WARNING 84: /local/lib32/libz.a is not used for resolving any... 
ld32: WARNING 84: /local/lib32/libORBitCosNaming.a is not used for...
ld32: WARNING 84: /local/lib32/libORBit.a is not used for resolving
any..
ld32: WARNING 84: /local/lib32/libIIOP.a is not used for resolving
any...
ld32: WARNING 84: /local/lib32/libORBitutil.a is not used for
resolving..
ld32: WARNING 84: /local/lib32/libz.a is not used for resolving any...
ld32: WARNING 84: /local/BerkeleyDB/lib/libdb.a is not used for
resolving 
ld32: WARNING 84: /local/lib32/libz.a is not used for resolving any...
ld32: WARNING 84: ../libart_lgpl/.libs/libart_lgpl.a is not used for...
ld32: WARNING 84: /local/lib32/libz.a is not used for resolving any...
ld32: WARNING 84: /local/lib32/libesd.a is not used for resolving any...
ld32: WARNING 84: /local/BerkeleyDB/lib/libdb.a is not used for
resolving 
ld32: WARNING 84: /local/lib32/libesd.a is not used for resolving any...
ld32: WARNING 84: /local/BerkeleyDB/lib/libdb.a is not used for
resolving 
ld32: WARNING 84: /local/lib32/libz.a is not used for resolving any...
ld32: FATAL 9: I/O error (-lgcc): No such file or directory

However, I have checked, and yes, libgcc.a does reside in the same
directory as the compiler.  In fact, the compiler has been able to
compile everything else up to this point, so I find it hard to believe
that it simply can't find libgcc due to a system configuration issue.  I
have even gone so far as to `ln -s' libgcc.a to some other place in my
library search path.  That just causes ld32 to seg fault (I didn't think
it would work, but I tried).  I have tried removing all library linkage
flags that are unused, but that still results in the same linking
problem.

What are the possible causes of this?  What paths should I go down?

Here is the compile string make (and libtool) are using:

gcc -I/local/include -I/local/BerkeleyDB/include -Wall -Wunused
-L/local/lib32 -L/local/BerkeleyDB/lib -o loadshlib loadshlib.o
.libs/libgnorba.a -lORBitCosNaming -lORBit -lIIOP -lORBitutil -lglib -lm
-lglib -lm -lz -lm -L/local/lib32 -lORBitCosNaming -lORBit -lIIOP
-lORBitutil -lglib -lm ../libgnome/.libs/libgnome.a -lglib -lm -lz -lm
../libgnomeui/.libs/libgnomeui.a -lesd -laudiofile -lm -laudio
-laudiofile -lm -ldb -lglib -lgdk_imlib -lgtk -lgdk -lgmodule -lglib
-lXext -lX11 -lm -lSM -lICE -lgtk -lgdk -lgmodule -lglib -lXext -lX11
-lm -lz -lm ../libart_lgpl/.libs/libart_lgpl.a
../support/.libs/libgnomesupport.a -lz -lm -L/local/lib32 -lesd
-laudiofile -lm -laudio -L/local/lib32 -laudiofile -lm -ldb
-L/local/lib32 -lglib -L/local/lib32 -lgdk_imlib -L/local/lib32 -lgtk
-lgdk -lgmodule -lglib -lXext -lX11 -lm -lSM -lICE -L/local/lib32 -lgtk
-lgdk -lgmodule -lglib -lXext -lX11 -lm -L/local/lib32 -lesd -laudiofile
-lm -laudio -L/local/lib32 -laudiofile -lm -ldb -L/local/lib32 -lglib
-lintl -lz -lm


Lastly, I configured gnomelib using
"./configure --prefix=/local --libdir=/local/lib32 --disable-shared
--enable-static"
Should it even be trying to compile/link something called "loadshlib"? 
Also, I only have libgcc.a, and no libgcc.so.  This hasn't caused a
problem in the past, though, and I have had better luck with the SGI
linker and static linking than shared objects.

Nathan





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]