[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
Re: Problem building gnustep-base, David Relson, 2002/02/22