configure.in question: compiler but not ld flags

[Bill Welliver-2]

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.

[Bill Welliver-2]

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.

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.

[Bill Welliver-2]

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.
>

[Bill Welliver-2]

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?

[Bill Welliver-2]

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?
>

>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.

> 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.