while building base, freshly reconfigured. I have clang 3.2
Making all for library libgnustep-base...
Compiling file GSLocale.m ...
In file included from GSLocale.m:25:
In file included from ././common.h:62:
In file included from ../Headers/Foundation/NSZone.h:31:
../Headers/GNUstepBase/GSVersionMacros.h:219:10: error: "You are building
gnustep-base using the objc-nonfragile-abi but your gnustep-base was not
configured to use it."
# error "You are building gnustep-base using the...
^
1 error generated.
Perhaps the compiler changed its default and configure is not guessing it?
> while building base, freshly reconfigured. I have clang 3.2
> Making all for library libgnustep-base...
> Compiling file GSLocale.m ...
> In file included from GSLocale.m:25:
> In file included from ././common.h:62:
> In file included from ../Headers/Foundation/NSZone.h:31:
> ../Headers/GNUstepBase/GSVersionMacros.h:219:10: error: "You are building
> gnustep-base using the objc-nonfragile-abi but your gnustep-base
> was not
> configured to use it."
> # error "You are building gnustep-base using the...
> ^
I just re-enabled this line yesterday because it seemed to be commented
out accidentally and does the sane thing (as in checking that the
compiler will actually emit code for the ABI that gnustep-base is
expecting). Maybe you could post the relevant output from config.log
(`checking for non-fragile-abi support'...), since this test is used to
set GS_NONFRAGILE to the correct value?
Niels Grewe wrote:
> Hello Ricardo,
> I just re-enabled this line yesterday because it seemed to be commented
> out accidentally and does the sane thing (as in checking that the
> compiler will actually emit code for the ABI that gnustep-base is
> expecting). Maybe you could post the relevant output from config.log
> (`checking for non-fragile-abi support'...), since this test is used to
> set GS_NONFRAGILE to the correct value?
it is strange: I don't see something relevant in config.log!
> Niels Grewe wrote:
>> Hello Ricardo,
>> I just re-enabled this line yesterday because it seemed to be commented
>> out accidentally and does the sane thing (as in checking that the
>> compiler will actually emit code for the ABI that gnustep-base is
>> expecting). Maybe you could post the relevant output from config.log
>> (`checking for non-fragile-abi support'...), since this test is used to
>> set GS_NONFRAGILE to the correct value?
> it is strange: I don't see something relevant in config.log!
> I execute:
> ./configure CC=/usr/local/bin/clang
>> grep fragile config.log
> (empty result)
Okay, on closer inspection -base only executes this test if you
configured gnustep-make with `--enable-objc-nonfragile-abi'. So maybe we
should have a check there for whether non-fragile is the default. (This
is not by any chance on a *BSD platform? I think David made clang
default to the non-fragile ABI for some of them…)
> This
> is not by any chance on a *BSD platform? I think David made clang
> default to the non-fragile ABI for some of them…)
I believe the current release defaults to the non-fragile ABI on *BSD (including Darwin, but a different non-fragile ABI there) but assumes Linux == GNU == GCC and so defaults to the legacy ABI there.
In trunk, --fobjc-nonfragile-abi is regarded as a legacy-compatibility option. The correct way of selecting it is -fobjc-runtime=gnustep, ideally with a version specified (currently it defaults to 1.7, and each clang release will default to the latest runtime release that it supports).
David Chisnall wrote:
> On 24 Sep 2012, at 09:32, Niels Grewe wrote:
>> This
>> is not by any chance on a *BSD platform? I think David made clang
>> default to the non-fragile ABI for some of them…)
> I believe the current release defaults to the non-fragile ABI on *BSD (including Darwin, but a different non-fragile ABI there) but assumes Linux == GNU == GCC and so defaults to the legacy ABI there.
> In trunk, --fobjc-nonfragile-abi is regarded as a legacy-compatibility option. The correct way of selecting it is -fobjc-runtime=gnustep, ideally with a version specified (currently it defaults to 1.7, and each clang release will default to the latest runtime release that it supports).
configure:5635: checking whether we should use the nonfragile ABI
configure:5676: result: not requested by user
this is my make.log. I did not specifically enable it (= I did not use any extra flag). I suppose that clang enables it anyway? Base is conflicting with what make declares.
It is also fun that GCC is being checked while I use clang :)
configure:5719: checking for the GCC version
configure:5746: result: version: 4.2
configure:5767: checking whether the compiler supports native ObjC exceptions
configure:5795: /usr/local/bin/clang -c -g -O2 -x objective-c -I. -I/usr/local/include -I/Local/Library/Headers -L/usr/local/lib -L/Local/Library/Libraries -fgnu-runtime -DGNU_RUNTIME -fexceptions -fobjc-exceptions conftest.c >&5
clang: warning: argument unused during compilation: '-L/usr/local/lib'
clang: warning: argument unused during compilation: '-L/Local/Library/Libraries'
>> This
>> is not by any chance on a *BSD platform? I think David made clang
>> default to the non-fragile ABI for some of them…)
> I believe the current release defaults to the non-fragile ABI on *BSD (including Darwin, but a different non-fragile ABI there) but assumes Linux == GNU == GCC and so defaults to the legacy ABI there.
> In trunk, --fobjc-nonfragile-abi is regarded as a legacy-compatibility option. The correct way of selecting it is -fobjc-runtime=gnustep, ideally with a version specified (currently it defaults to 1.7, and each clang release will default to the latest runtime release that it supports).
Okay, so we have to keep that in mind for the future. Do the arguments
to the __has_feature() macro change accordingly? For now, I modified
gnustep-make to also check for the compiler default. This should get rid
of any unexpected mismatch, though we still might want an option to
disable it explicitly.
> I did not specifically enable it (= I did not use any extra flag). I suppose that clang enables it anyway? Base is conflicting with what make declares.
I think that's probably correct, yes. The configure test should be fixed to check whether the non-fragile ABI is actually being used. This is easy to do with the test in the header. This command should probably be the one used by the configure script:
This will print 1 if the non-fragile ABI is being used or something else (0 or __has_feature(objc_nonfragile_abi), depending on whether the compiler supports __has_feature) if it isn't.
On an unrelated note, has anyone tried using CMake to compile GNUstep applications? I have been very impressed with the combination of CMake and Ninja as a build system for LLVM.
On 24. 9. 2012., at 11:23, David Chisnall <thera...@sucs.org> wrote:
> On an unrelated note, has anyone tried using CMake to compile GNUstep applications? I have been very impressed with the combination of CMake and Ninja as a build system for LLVM.
I'm not sure why, but I have a dislike for CMake. Whenever I run into it, I run into a problem as well.
For example, over the weekend I was supposed to compile a library for iOS. After figuring out that all configuration tests were failing (so that, for example, the header defining uint32_t and friends could not be found), I spent an afternoon trying to find out which command line is being used to compile the test program so I could see why the compiler is failing.
All online instructions help with getting verbose output from the generated makefile -- but I'm having troubles with generating the makefile.
All in all, I'm not too impressed with CMake. On surface, it indeed looks like a lot easier and readable way to write build systems. But I get the feeling that it comes with its own set of problems.
