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?  


>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

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.