When adding configure tests, where does one place flags intended for the compilation phase but not the linking phase? The flag I need to add (-x objective-c) doesn't seem like it should be a problem, but for some reason, using it when linking causes gcc to enter compile mode, rather than linking mode.
Right now, it appears that adding items to either CFLAGS or CPPFLAGS, they all end up in LD (CFLAGS directly, and CPPFLAGS via DEFINES). It seems to me that CPPFLAGS and LDFLAGS should be independent of each other (though I imagine it might occur that certain flags are used in both modes).
Bill
That flag sounds like it would belong in either $OBJC or $OBJCFLAGS, used to compile Objective-C code. $CC and $CFLAGS is for compiling C code, not C++, Objective-C, or FORTRAN.
Well, the problem is that certain headers imply objective-c, so if you try to include them in a file that ends in .c, it gives up, even though it's a completely legitimate thing to do. So, you need to tell it to use the "-x objective-c" flag to quiet it down.
For completeness, I'm trying to put together a Backend object that uses CFRunLoop, which is a valid C API, but one or more of the headers that it brings with it has Objective-C syntax in it.
Bill
On Wed, 21 Dec 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
That flag sounds like it would belong in either $OBJC or $OBJCFLAGS, used to compile Objective-C code. $CC and $CFLAGS is for compiling C code, not C++, Objective-C, or FORTRAN.
Including a header with obj-c syntax from C does not sound like a legitimate thing to do to me. The other way around would probably be legit. If the API is C, it should be defined in header files which are C.
From what I can tell, the source of the problem is what Apple calls
"toll-free" bridging, which is cast-equivalency between C-language Core Foundation datatypes (most of which start with CF) and their Foundation Kit (objective-c) equivalents.
Whether it's proper or not (and I agree that there seems to be some over-reaching in the headers), it's what I need to be able to do. Thus, it seems that there ought to be a way to specify an option for the compile phase and not linking. Truth be told, it's only really necessary for backend.cmod, but that's probably beside the point.
It seems incorrect that where would be various sets of flags (CPPFLAGS, DEFINS and CFLAGS) that all end up being used as part of what is very obviously not a compilation command. After all, LDFLAGS don't end up on the compilation lines, right?
Bill
On Wed, 21 Dec 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Including a header with obj-c syntax from C does not sound like a legitimate thing to do to me. The other way around would probably be legit. If the API is C, it should be defined in header files which are C.
From what I can tell, the source of the problem is what Apple calls "toll-free" bridging, which is cast-equivalency between C-language Core Foundation datatypes (most of which start with CF) and their Foundation Kit (objective-c) equivalents.
Whether it's proper or not (and I agree that there seems to be some over-reaching in the headers), it's what I need to be able to do. Thus, it seems that there ought to be a way to specify an option for the compile phase and not linking. Truth be told, it's only really necessary for backend.cmod, but that's probably beside the point.
Sounds like a way around the problem could be to make some minimal Objective-C glue that the cmod could interface with in turn.
And if you really do need to include headers with contain obj-c, then you should use a compiler which understands obj-c, which is not necessarily the case with $CC.
Well, short of making backend.cmod an mmod file, I don't see a better option. Doing that, though, would break things for the 90% of people who aren't impacted by these header files.
This situation only occurs on systems that have CoreFoundation, which without an exception I'm aware of, are systems that are using gcc that have objective-c mode (ie, Darwin.)
Bill
On Wed, 21 Dec 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
And if you really do need to include headers with contain obj-c, then you should use a compiler which understands obj-c, which is not necessarily the case with $CC.
Are you telling me that the choice of compilers on Darwin is so poor that you only have one (1) to choose from? Doesn't e.g. CodeWarrior run on Darwin?
Not that it actually matters. Deducing which C-compiler is used from the presence of a particular C-API sounds just too broken. What if someone (such as OpenStep) implements the API on some other platform?
I don't think I said that I was determining the c-compiler based on the presence of an API. I'm saying that I have a known combination of OS/API/Compiler that requires a command line flag in order for compilation to be successful. Surely you're not suggesting that's unusual, otherwise we wouldn't have an autoconf script in the first place.
I tried to figure out what variable this flag ought to be placed in. I tried finding the correct spot and it appears (through sloppiness or design) that everything ends up on all invocations of the c compiler or linker. Placing this flag on a linking command causes the linking to fail.
Regarding your comment about available compilers, CodeWarrior hasn't targeted desktop systems for 10 years or so. There are other compilers out there, but the number of people using them is extremely low, to the point of being non-existent among pike-users.
Incidentally, on the latest releases of Darwin, the default compiler (with is llvm-based) aborts when compiling mapping.c. I still use regular gcc, so haven't attempted to report the bug.
Bill
On Wed, 21 Dec 2011, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Are you telling me that the choice of compilers on Darwin is so poor that you only have one (1) to choose from? Doesn't e.g. CodeWarrior run on Darwin?
Not that it actually matters. Deducing which C-compiler is used from the presence of a particular C-API sounds just too broken. What if someone (such as OpenStep) implements the API on some other platform?
Incidentally, on the latest releases of Darwin, the default compiler (with is llvm-based) aborts when compiling mapping.c. I still use regular gcc, so haven't attempted to report the bug.
I've seen that too. It's normally sufficient to manually compile mapping.c with gcc and re-run make (with the default llvm-gcc) after that. We never got around to report that to Apple since there seemed to be tickets on that issue already, though that's a lame excuse if the errors in reality are separate.
It would be nice to support clang natively as well but I guess that will be a major exercise in autoconf/makefile hacking.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
H. William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum