This is the mail archive of the
mailing list for the binutils project.
Link order a pain, positional argument --start-group problematic
- From: "R. Diez" <rdiezmail-binutils at yahoo dot de>
- To: binutils at sourceware dot org
- Date: Tue, 5 Jan 2016 10:28:58 +0100
- Subject: Link order a pain, positional argument --start-group problematic
- Authentication-results: sourceware.org; auth=none
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
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++.
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.