A.P. Lawrence

compiler flags

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Robert Lipe <robertlipe@usa.net>
Subject: Re: Unixware 7.1.1 & SSH
Date: Fri, 26 Jan 2001 05:33:31 -0000 References: <94i4tu$kfh$1@news1.kornet.net> <3A6D3CBF.B258D4DB@strhold.it>

mschalit@pacbell.net (Matt Schalit) writes:

>In article <t71c6ln0l6lu74@corp.supernews.com>, robertlipe@usa.net says...
>> mschalit@pacbell.net (Matt Schalit) writes:

>> "-I" doesn't mean to the linker what you seem to want it to mean.  Also,
>> why are you telling cc (incorrectly) to look for things in places that
>> it knows to look anyway?  

Lone-Tar Backup and Disaster Recovery
for Linux and Unix

>First of all, before you take my answer wrong, as if I am angry
>or being a jerk, that's not my intention.  I think this says
>it all,

I'm not trying to be a jerk, either.  I'm sorry if the reality was
otherwise.  (If I am being one, perhaps you'll allow me to blame it on
being ill and typing with a pounding head and squinting eyes.)

>I was either thinking that listing them in a certain order gets
>them searched in that order, or I was thinking that the configure 
>program would be able to figure out some issues that were returning 
>a "no."  

That's sometimes a good strategy.  The average configure script these
days takes somewhat of a sperm approach to finding library interfaces.
It tries a billion different ones in the hopes that one of them will
stick.  So don't be too alarmed about seeing an occaisional "no" fly by.

But the tidbit that turned much of your configure line into a placebo
was passing flags for one tool to a different tool.

        LDFLAGS="-I/usr/lib -I....

The common use of -I in a cc invocation isn't a linker (ld) flag at all
but rather a c preprocessor flag to change the include search path.
(There actually is a -I that's valid to ld, but you almost certainly
didn't intend to use that here.)  But the directories you listed don't
contain includes; they contain libraries.  So passing the linker a set
of -I directories is a NOP.

        CPPFLAGS="-L/usr/includ...

Similarly, the common use of -L _is_ to the linker (and not the
stand-alone C preprocessor which is what CPPFLAGS controls) and it's to
add a directory of libraries to the search patch for the link.  Only the
directories you listed don't contain libraries; they contain includes.
So again, this becomes a NOP.

>in what order.  I've been compiling about 25 different archives
>for Uw7.1.1 this last month without the UDK, using either cc or
>gcc 2.95.2.1, and there's no end to the problems I face having to
>shoehorn in this path of that path to get the configure/compile to
>run successfully.  Off the top of my head I recall tcl8.3.2,

I haven't built either one of those lately.  In general, though, if you
have to manually override anything like this in a configure script, it's
a defect and you should work with the authors to get it fixed.  The
whole point of configure is, in fact, to isolate you from this sort of
stuff.

>> (And libucb is evil and should be avoided.  OTOH, you're not linking 
>> with -lucb, so I don't know what that gains you.  

>The configure script was looking for -lucb, so I put it in
>this time.  I don't know why it was, and I don't want to have to

My personal recommendation is to never install libucb.  Then, when
configure tries to find things in it (that are often less functional
than their standards-blessed counterparts) it will cleanly not find them
and use the (better tested) ANSI/XPG functionality instead.

>So now I want to know why it's "evil."  Searching the

It's evil becuase I declared it to be. :-)

I can't find a system with libucb installed on it to cite specific
examples, but libucb is a compatbility crutch for crufty old code
written for BSD systems that hasn't been updated for that newfangled
specs like ANSI/ISO C89.  The interfaces tended to be prone to
corruption and the implementations were poor.  I found it much more
satisfying to just remove these and let programs fail to find these
crutches and learn to walk on their standards-blessed legs.

>> Why you're trying to -I(include) libraries and
>> -L(ibrary) includes is also a bit mysterious to me.

>I wasn't aware of another way to get includes or libraries
>seen by configure, cc, and ld.  

The point was that you reversed the logic.   You want to use -I for 
include paths and -L for library paths.   So
        cc -I/usr/local/include -L/usr/local/lib 
is a sensible thing to do if you have includes and libraries in /usr/local. but
        cc -L/usr/local/include -I/usr/local/lib 
is almost certainly not what you want.

>> Without any testing, I'm wondering if:
>> 
>>  CC="/bin/cc -Kalloca -Kno_host" LIBS=-lgen ./configure \
>>      --host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
>>      --x-libraries=/usr/X/lib
>> 
>> wouldn't actually be as effective.

>Yes your example works fine, as long as someone corrects my typo:

Good.   That supports my theory that those were placebos. :-)

>Thank you very much for helping me to learn how to use cc.

You're welcome.  I can't think of any one (small) place all the
pertinent rules are written down.  Digesting the compiler, linker, c
preprocessor, libtool, configure documentation is a large intellectual
investment.  I just get nervous when I see compiler superstition spread
in the groups. :-)

RJL