[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where Is 'GSConfig.h'?
Re: Where Is 'GSConfig.h'?
Tue, 9 Sep 2003 16:51:35 +1000
>>>> 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
>>> If you are using gcc-3.x make sure that your compiler's libgcc_s and
>>> 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
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
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
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.
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