incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: stdcxx building problem on the gcc 3.2.2/Linux RedHat9
Date Thu, 06 Jul 2006 17:58:57 GMT
Farid Zaripov wrote:
>>But I don't understand why a change in the order of dependencies
>>makes a difference in the order of libraries on the command line.
>>Can you explain it to me?
> 
> 
>   I don't know.
> 
>   I think it's works because used implicit rule which passes the target
> dependenses to the command line

Yes, that seems to match the observed behavior. I don't have
a problem making the change you suggest but I would like us
to understand if it works by design or if it's just a lucky
happenstance.

The other thing that's wrong here and that's really causing
the problem is that the implicit rule is kicking in at all
when an explicit rule exists. I don't understand why that
happens either. I see no problem using the implicit rules
(in fact I would prefer to rely on them) just as long as
we do so deliberately. Right now they happen to work almost
right (save for the library ordering issue), we just don't
know why they are triggered.

> 
>   In command line I see that librwtest.a and libstd.a is specified
> twice:
> 
> From $(LDFLAGS):
> -L/usr/src/Incubator/stdcxx/trunk/build/rwtest -lrwtest
> -L/usr/src/Incubator/stdcxx/trunk/build/lib -lstd
> 
> Appended target dependenses:
> /usr/src/Incubator/stdcxx/trunk/build/lib/libstd.a
> /usr/src/Incubator/stdcxx/trunk/build/rwtest/librwtest.a  -lsupc++ -lm
> -o 21.string.io
> 
>   And I think that LD first uses the libraries specified in the command
> line directly, and only after that the libraries from -l options.

UNIX linkers always process arguments left to right. Note that
we don't want to specify any libraries using a full pathname.
We always want to use -L flag to specify the directory and -l
to name the library. That's how users will use the library so
we need to make sure we build and test it the same way. This
is another problem with the implicit rules that we need to
understand and avoid before using them.

If you're interested in looking into this here's GNU make manual:
http://www.gnu.org/software/make/manual/. I suggest using the
latest release of GNU make (3.81) for experimenting so as to avoid
any known bugs (I've been using 3.79 but we document that versions
as old as 3.70 work -- that may not be true anymore, I'm not sure).

Martin

Mime
View raw message