discuss-gnustep
[Top][All Lists]
Advanced

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

Re: problem with gnustep-base+gcc 3.0


From: Nicola Pero
Subject: Re: problem with gnustep-base+gcc 3.0
Date: Thu, 26 Jul 2001 10:46:56 +0100 (BST)

> ----------------------------------------------
> #import <Foundation/Foundation.h>
> 
> int
> main (void)
> { 
>   NSLog (@"Executing");
>   return 0;
> }
> ------------------------------------------
> I've got this warning :
> /usr/bin/ld: warning: type and size of dynamic symbol
> `__objc_class_name_NSConstantString' are not defined

Well - this is actually a good sign :-) the class is called
NSConstantString rather than NXConstantString which means that at least
the configure scripts detected your gcc 3.0 :-)
 

> Then, if I try to execute the program I get "segmentation fault".

yes - I know - this is annoying - the problem might be that you have not
set up library path for the dynamic linker, so it's not finding the
correct libobjc.so and libgcc_s.so.

For example, to use the gcc-3.0 compiler, I install it into /opt/gcc-3.0/,
and then when I want to switch to it, I use the following little shell 
stuff:

export PATH=/opt/gcc-3.0/bin:$PATH
export 
LD_LIBRARY_PATH=/opt/gcc-3.0/lib/:/opt/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0.1:$LD_LIBRARY_PATH

/opt/gcc-3.0/bin is the path to the compiler itself,
/opt/gcc-3.0/lib is the path to libgcc_s.so, and
/opt/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0.1 is the path to libobjc.so

(please notice the 3.0.1 - you need 3.0.0 or 3.0.1 depending on the actual
compiler version you're using) the first thing you want to do is to check
that you have setup your library paths correctly (you might as well add
the paths to /etc/ld.so.conf and run ldconfig).

To check it, try running `ldd' on your compiled tool which crashes.  ldd
shows the dynamic libraries the tool is compiled with, and where the
dynamic linker finds them.  Check very carefully libobjc.so - it must be
the one installed with your compiler, and check also libgcc_s.so.

Here is an example of the dynamic linker output when I switch to gcc-3.0.1
on my system:

nicola:/opt/nicola/core/base-3.0/Tools/shared_obj/ix86/linux-gnu/gnu-gnu-gnu$
ldd defaults
        libgnustep-base.so.1 =>
/usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1
(0x40015000)
        libobjc.so.1 =>
/opt/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/libobjc.so.1 (0x401f6000)
        libxml.so.2 => /usr/lib/libxml.so.2 (0x40213000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4027c000)
        libgmp.so.2 => /usr/lib/libgmp.so.2 (0x4028b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402a2000)
        libdl.so.2 => /lib/libdl.so.2 (0x402b5000)
        libm.so.6 => /lib/libm.so.6 (0x402b9000)
        libc.so.6 => /lib/libc.so.6 (0x402d6000)
        libgcc_s.so.1 => /opt/gcc-3.0/lib/libgcc_s.so.1 (0x403cc000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
nicola:/opt/nicola/core/base-3.0/Tools/shared_obj/ix86/linux-gnu/gnu-gnu-gnu$ 

This is the correct output for libobjc.so and libgcc_s.so.

If this doesn't help, try the classical `rm -Rf /usr/GNUstep' and rebuild
everything - sometimes that helps because you might have some old
experiment (such as a dirty libobjc.so hanging in there).  If it still
doesn't work, you need to send us more information so that we can help you
- eg the output of ./configure in the base library, ldd output on the
tool.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]