discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Problem building gnustep-base


From: Dennis Leeuw
Subject: Re: Problem building gnustep-base
Date: Fri, 22 Feb 2002 18:20:42 +0100

The strange thing is that I am totaly confused by what is happening.
I just installed gcc-3.0.4 in /usr/GNUstep and added
/usr/GNUstep/lib/gcc-lib/i686-pc-linux-gnu/3.0.4
/usr/GNUstep/lib
to my ld.so.conf and ran ldconfig

I set the environment var CC to /usr/GNUstep/bin/gcc, these are to me always 
the standard things I do
when upgrading a compiler. The only thing that is different is the fact that I 
use Debian now and I
used to use Slackware.

And added to the beginning of PATH /usr/GNUstep/bin.

On the commandline the function reveals the correct libobjc.so:
maggy:/usr/src/SPM/gnustep/core/make#$CC -print-file-name=libobjc.so
/usr/GNUstep/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/libobjc.so


> > >
> > > gcc_shared_libobjc=`gcc -print-file-name=libobjc.so`
> > > if test -f "$gcc_shared_libobjc"; then
> > >   gs_cv_objc_libdir=`dirname $gcc_shared_libobjc`
> > > fi
>
> I don't understand how/why this is supposed to work.

This was an already available function and the -print-file-name option just 
returns the entire path to
the libobjc.so file, which is quite handy if everything else fails ;)


>  gcc_shared_libobjc=`$CC -print-file-name=libobjc.so`
>
> otherwise you're using the default gcc shared libobjc, but compiling with
> the newer compiler.

With the above mentioned changes to PATH, CC and ld.so.conf I disagree. I use 
/usr/GNUstep/bin/gcc:
maggy:~# which gcc
/usr/GNUstep/bin/gcc
maggy:~# gcc -v
Reading specs from /usr/GNUstep/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/specs
Configured with: ./configure --prefix=/usr/GNUstep --enable-shared 
--enable-threads
--enable-languages=c,objc --enable-version-specific-runtime-libs : 
(reconfigured) ./configure
--prefix=/usr/GNUstep --enable-shared --enable-threads=pthreads 
--enable-languages=c,objc
--enable-version-specific-runtime-libs
Thread model: pthreads
gcc version 3.0.4

So I don't think I did anything wrong, but still with the default configure 
script I get:
<snip>
checking for shared objc library... NONE
<snip again>
checking whether objc has thread support... no
checking if the compiler supports autodependencies... yes: gcc major version is 
3
</snip again>
</snip>

With:
gcc_shared_libobjc=`gcc -print-file-name=libobjc.so`
I atleast get:
checking for shared objc library... 
/usr/GNUstep/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/libobjc.so
Which seems correct to me


> If you use a stock compiler, but use a custom libobjc, then gnustep-make
> is going to detect the custom libobjc and hack all compilation and
> configuration stuff so that the custom libobjc is used instead of the
> compiler's one.
>
> If you use a stock compiler, and use the compiler's standard libobjc, then
> gnustep-make has nothing to do - yours is a standard compiler
> installation, and the compiler - when properly installed - automatically
> uses the correct libobjc !  If that doesn't work, then it's your problem
> :-)

Yep, I am afraid that is the case. But what I don't understand is what I am 
missing.


> (or your distribution problem)

That might be the problem too. I am new to Debian, so maybe I missed something 
that used to be there
on Slackware.


> > > > > I don't seem to be able to use your Objective-C compiler to produce
> > > > > working binaries!  Please check your Objective-C compiler 
> > > > > installation.
> > > > > If you are using gcc-3.x make sure that your compiler's libgcc_s and
> > > > > libobjc
> > > > > can be found by the dynamic linker - usually that requires you to play
> > > > > with LD_LIBRARY_PATH or /etc/ld.so.conf.
> > > > > Please refer to your compiler installation instructions for more help.
> > > > > configure: error: The Objective-C compiler doesn't work or is not
> > > > > installed properly.
>
> Btw, I'm still puzzled - why did you ignore this message in the first
> place ?  It's telling you where the problem is, and explaining you what to
> do to fix it.

I didn't ignore it. It was the reason I wrote my first e-mail about this. I 
tried setting
LD_LIBRARY_PATH, although I have ld.so.conf setup correctly, and it didn't 
solve the problem. Then I
started looking in the configure log of gnustep-make and found out that it 
didn't find the objc-stuff,
and the rest is history.

What I would like to know is is there one reason, with the above configuration, 
why my Debian system
won't supply to correct information for the gnustep-make system?

Thanks for your help.

Dennis Leeuw




reply via email to

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