Re: problem Boost libraries
Bj?rn Roald wrote:
James Kanze wrote:
Bj?rn Roald wrote:
[...]
In
the distant past, I've even used a linker which processed each
library file sequentially (which required the library file to be
sorted according to dependencies).
I am not sure what you mean, but I guess you refer to sorting the
content (the object files) contained in the library?
Exactly. A bit like on early Unix, if you didn't use ranlib.
Each scan will honor the linking order you
specify. I am not sure whether this is what Visual Studio does, but I
could almost bet on it :-)
That I don't like. What would seem reasonable, however, would
be for the compiler to keep track of all of the symbols it sees
in the first scan, and where they are defined, and then use them
for resolving symbols in object files seen later.
Yep, I have also wondered why that is not done. But it may possibly
break working builds, as legacy link order may resolve to different
symbols. It certainly would avoid rescanning the files.
Whatever you do, you don't want to rescan files. That causes
more problems than it solves.
Historically, of course, the reason why it was not done is
simple: memory. You've got to save those symbols somewhere.
Today, of course, I doubt that this is a valid objection.
To tell the truth, I'm not sure what the "correct" solution here
is. I'm so used to the classical solution (which is still the
usual solution under Unix) that anything else intuitively seems
strange. (The classical solution obviously gives you more
control. It does require more organization, but if the project
is correctly organized, the extra work is minimal. On the other
hand, does the added control ever buy you anything. And of
course, the third party libraries you are using may not be well
organized, or you may not know or understand the organization.)
Yes. What we could ask is if this classical solution make sense in it
self, or is it only an ill formed effect of limitations in legacy tools?
It makes sense. The question is just whether other solutions
make more sense.
As a feature it can be used to verify that dependencies does not violate
the allowed-dependencies in the design, but it is not close to a good
tool for that purpose. The negative result is that libraries can not be
arbitrary collections of translations. As you put it some organization
is required. And what do we gain from that?
Some organization is required in any case. What we get is that
the lack of organization may cause link time errors, rather than
some wierd run-time behavior, or an unmaintainable
configuration. But as you say, it's a side effect, not
guaranteed, and a purpose built tool for this might be a better
idea.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]