Hi all:
I grew up with MS-DOS and the like, where link order did not matter (as
far as I remember). In fact, I still find ld's link order
counterintuitive. In my experience, it is a common source of unexpected
link errors.
I personally find disturbing that a duplicate symbol may or may not be
detected depending on the link order, which can be pretty hard to
control in complex or even automatically-generated makefiles.
Reordering libraries in the makefile because of this is a pain, and
sometimes there is the issue or circular dependencies.
Furthermore, link order issues have multipled with the advent of C++.
For example:
https://stackoverflow.com/questions/3363398/g-linking-order-dependency-when-linking-c-code-to-c-code
Using the --undefine flag is difficult with C++ mangled names, and not
really practicable in large projects.
One of the often-suggested work-arounds is to list static libraries
twice, but I am not sure whether that would slow down the link process.
Maybe someone here can shed some light on this aspect.
Another common advice is to use --start-group / --end-group and/or
--whole-archive . The problem is, the position of these command-line
arguments is significant, and that is a problem with some build tools.
For example, libtool does not support them:
> Please also note that libtool currently does not support position
> dependent linker flags such as --whole-archive, --start-group,
> --add-needed, --as-needed, or -Bstatic. Lifting that restriction
> is planned, as possible, at some point in the future.
libtool is part or the autotools, which could be considered dead as far
as real development is concerned, so I do not think that a fix is in sight.
As a work-around, I suggest adding alternative command-line arguments
that are not position dependent. I guess in most situations a global
flag like --whole-archive-all would provide a simpler, more intuitive
and more reliable experience.
Please copy me on the answers, as I am not subscribed to this list.
Regards,
rdiez