Re: problem Boost libraries
Bj?rn Roald wrote:
James Kanze wrote:
Gennaro Prota wrote:
On Sat, 27 Jan 2007 06:36:18 CST, James Kanze wrote:
Dependencies in the order of inclusion of header files are a
serious defect. Other dependencies may be unavoidable: order of
inclusion of libraries, for example.
Could you please elaborate on the latter point? What is the order of
inclusion of libraries?
If library A uses library B, then you must include library A
before library B in the link phase; i.e. under Unix, -lA -lB,
and not -lB -lA.
From what I understand, Windows doesn't have this restriction.
On the other hand, eliminating it probably has other problems:
how do you ensure that your implementation of operator new and
operator delete is found before the one in the standard library.
(It works; if under Windows I list my librarys in the same order
as I do under Unix, I get the same modules in the final
executable. But I've not had the time to look into the whys and
wherefors of this yet.)
The normal strategy for this used by some compiler/linkers are to rescan
the libraries until no new symbols are defined in a complete scan or all
symbols are defined.
Historically, the "normal" strategy (although I'm not sure that
"normal" is the appropriate word, given the amount of variation)
is for the compiler to process the files in the order given. 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).
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.
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.)
--
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! ]