Re: Where Is 'GSConfig.h'?

[Bill Northcott]

>>>> Philip Mötteli wrote:
>>> configure says also something else:
>>>
>>> checking whether objc really works... no
>>> 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.

>> Do you have more than one gcc installed?

>Well, every Mac OS 10.2 has gcc version 2.x and 3.1 installed.

There seems to be more than a little confusion here between some one using 
MacOS X and some one else unfamiliar with the Apple linkers and gcc 
compilers.

Philip is using MacOS X.

Firstly, the MacOS X linker system.  There is no /etc/ld.so.conf on MacOS 
X.  The static linker ld used at build time only searches specified 
directories and the system directories.  The dynamic linker dyld used at 
runtime searches system directories and the those in DYLD_LIBRARY_PATH. 
AFAIK LD_LIBRARY_PATH has no function on Darwin/MacOS X.

Secondly Apple versus FSF gcc compilers.  Apple have their own version of 
the gcc compiler.  It is unlikely this will ever be identical to the FSF 
version because some of Apple's mods are unacceptable to the FSF 
maintainers and vice versa.  The declared objective is to make them as 
close as possible.  Apple regularly update their sources from the FSF ones 
and as Zem Laski's messages here show they try to feed their changes back 
to the FSF version.

Thirdly, although Apple's compiler sources can be bootstrapped in the 
standard FSF configure/make system, they are normally built using some 
build scripts, primarily build_gcc.  This results in a number of 
differences between an Apple build and an FSF one.  The obvious ones being 
that the binary names are different - always gcc for FSF but gcc-3.3, gcc3 
(3.1) or gcc2 (2.95.2) for Apple.  This is so that different version 
compilers can be installed simultaneously in /usr/bin lib libexec etc 
without trampling on each other.  The default invoked by gcc or cc can be 
changed by running an Apple supplied script gcc_select, which sets up the 
default names as symlinks.

Forthly The Apple build does not include any libobjc.  The FSF build on 
Darwin includes only a static libobjc.  Either compiler built on 
Darwin/MacOS X defaults to the Next runtime, but this can be overridden 
with -fgnu-runtime.

The big differences in behaviour between the FSF and Apple versions are in 
Objective-C.  Indeed there are almost two different compilers one for the 
Next runtime and the other for GNU.  Since Apple never use the GNU 
runtime, that bit of their sources has not been tested in the past.  Hence 
Zem's helpful discussions here which may change that in the future.

Until recently Apple compilers would crash trying to build anything more 
than trivial code with the -fgnu-runtime flag.  This was fixed in their 
sources around 20 June this year.  Recent versions of Apple compilers 
built from the Panther release branch will build complex Objective-C for 
the gnu runtime including Swarm (www.swarm.org).  However, the code 
generated is incorrect for nested functions and some other constructs. 
This problem appears to be fixed by the patch at 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11754.

Recent Apple sources with this patch will build running versions of Swarm. 
 Apple has not so far issued a compiler binary that will build Swarm.  I 
am about to post a binary for such a gcc-3.3 compiler on the Swarm site at 
savannah.gnu.org.  I think it will build a running gnustep on MacOS X and 
I would like to know if it does.

Hope this helps.

Bill Northcott

PS I have spent a lot of time chasing people's suggestions about the wrong 
libgcc.  Believe me it does not happen.  If you force it to happen, which 
is hard, the compiler can no longer build a trivial C program as used by 
autoconf.