I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_loaded@GLIBC_2.1' zip4_lnx.a(libdl.so): undefined reference to `_dl_open@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_signal_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_global_scope@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol_skip@GLIBC_2.0'
I have the compatibility libraries installed. I have tried using gcc296, gcc, and gcc4 and still get the message. The library,libdl.so.2 is in /lib with a symlink to /usr/lib/libdl.so Using CentOS 4.0.
+++ Edward Croft [Tue Jul 19, 2005 at 01:42:50PM -0400]:
I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_loaded@GLIBC_2.1' zip4_lnx.a(libdl.so): undefined reference to `_dl_open@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_signal_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_global_scope@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol_skip@GLIBC_2.0'
I have the compatibility libraries installed. I have tried using gcc296, gcc, and gcc4 and still get the message. The library,libdl.so.2 is in /lib with a symlink to /usr/lib/libdl.so Using CentOS 4.0.
does libdl.so.2 have _dl_lookup_symbol included? Could nm the libs in the path to ensure that these symbols are correctly being found and linked?
On 7/20/05, Bruno Delbono Bruno.S.Delbono@mail.ac wrote:
+++ Edward Croft [Tue Jul 19, 2005 at 01:42:50PM -0400]:
I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_loaded@GLIBC_2.1' zip4_lnx.a(libdl.so): undefined reference to `_dl_open@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_signal_error@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_global_scope@GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol_skip@GLIBC_2.0'
I have the compatibility libraries installed. I have tried using gcc296, gcc, and gcc4 and still get the message. The library,libdl.so.2 is in /lib with a symlink to /usr/lib/libdl.so Using CentOS 4.0.
does libdl.so.2 have _dl_lookup_symbol included? Could nm the libs in the path to ensure that these symbols are correctly being found and linked?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
How would I find out if libdl.so.2 have _dl_lookup_symbol included? What is nm? Forgive me, I am not a programmer anymore. I last programmed in COBOL days. I am the systems person and we upgraded to CentOS from RHAS21 and now the programmer can't compile. He gave it to me to figure it out. I understand makefiles, et al to a point that I have to compile drivers and such, but my expertise is limited in this area. But always willing to learn a new trick.
Edward Croft wrote:
How would I find out if libdl.so.2 have _dl_lookup_symbol included? What is nm? Forgive me, I am not a programmer anymore. I last programmed in COBOL days. I am the systems person and we upgraded to CentOS from RHAS21 and now the programmer can't compile. He gave it to me to figure it out. I understand makefiles, et al to a point that I have to compile drivers and such, but my expertise is limited in this area. But always willing to learn a new trick.
How are you compiling the program? What are the arguments you're passing?
On 7/20/05, Bruno Delbono bruno.s.delbono@mail.ac wrote:
Edward Croft wrote:
How would I find out if libdl.so.2 have _dl_lookup_symbol included? What is nm? Forgive me, I am not a programmer anymore. I last programmed in COBOL days. I am the systems person and we upgraded to CentOS from RHAS21 and now the programmer can't compile. He gave it to me to figure it out. I understand makefiles, et al to a point that I have to compile drivers and such, but my expertise is limited in this area. But always willing to learn a new trick.
How are you compiling the program? What are the arguments you're passing?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The Makefile looks like this: include ../rapijni/Makefile
USPS_MODULES = standardizer_lib.c zip4_lnx.a
usps: $(USPS_MODULES) gcc $(CFLAGS_JVM) -DUNIX -DDLL_BUILD -shared -o libusps_lib.so $^
standardizer: standardizer.c zip4_lnx.a gcc296 -v -B /usr/lib/i386-redhat-linux3E/lib/ \ -B /usr/lib/i386-redhat-linux7/lib/ \ -I /usr/lib/i386-redhat-linux7/include \ -DUNIX $^ -o standardizer usps_clean: rm -f *.o *.so *test standardizer
And no, I cannot recompile the zip4_lnx.a program. That is the one giving errors.
On Wednesday 20 July 2005 15:50, Edward Croft wrote:
How would I find out if libdl.so.2 have _dl_lookup_symbol included? What is nm? Forgive me, I am not a programmer anymore. I last programmed in COBOL days. I am the systems person and we upgraded to CentOS from RHAS21 and now the programmer can't compile. He gave it to me to figure it out. I understand makefiles, et al to a point that I have to compile drivers and such, but my expertise is limited in this area. But always willing to learn a new trick.
Hmmm - it looks for a symbol that is no longer available in that version... From the error and your statement I guess that your app is linked against a 3rd party library or an internal piece of code that you did not recompile, correct?
If you can't recomipile the code you probably will not be happy. If you are trying to access symbols that were exported but aren't any longer and stuff like that you might be ok with exporting LD_ASSUME_KERNEL=2.2.5 but that will in your case most likely just change the error, not get rid of it. Especially c_type_b... The other thing you can try is install a 6.2 compat glibc. Since 6.2 is so old, its not even part of the distribution anymore, but you can usually get away loading an older glibc-compat (i.e. I loaded the compat-glibc-6.2-2.1.3.2.i386.rpm from RH7.3 on a Fedora Core 1 box)...
Either way, it comes down to your application simply being too old - try get an upgrade to whatever lib holds you back...
Peter.
On 7/20/05, Peter Arremann loony@loonybin.org wrote:
On Wednesday 20 July 2005 15:50, Edward Croft wrote:
How would I find out if libdl.so.2 have _dl_lookup_symbol included? What is nm? Forgive me, I am not a programmer anymore. I last programmed in COBOL days. I am the systems person and we upgraded to CentOS from RHAS21 and now the programmer can't compile. He gave it to me to figure it out. I understand makefiles, et al to a point that I have to compile drivers and such, but my expertise is limited in this area. But always willing to learn a new trick.
Hmmm - it looks for a symbol that is no longer available in that version... From the error and your statement I guess that your app is linked against a 3rd party library or an internal piece of code that you did not recompile, correct?
If you can't recomipile the code you probably will not be happy. If you are trying to access symbols that were exported but aren't any longer and stuff like that you might be ok with exporting LD_ASSUME_KERNEL=2.2.5 but that will in your case most likely just change the error, not get rid of it. Especially c_type_b... The other thing you can try is install a 6.2 compat glibc. Since 6.2 is so old, its not even part of the distribution anymore, but you can usually get away loading an older glibc-compat (i.e. I loaded the compat-glibc-6.2-2.1.3.2.i386.rpm from RH7.3 on a Fedora Core 1 box)...
Either way, it comes down to your application simply being too old - try get an upgrade to whatever lib holds you back...
Peter. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yes the LD_ASSUME_KERNEL=2.2.5 did cause more errors.
-
Bruno Delbono -
Edward Croft -
Peter Arremann