This is the mail archive of the
mailing list for the binutils project.
Re: Link order a pain, positional argument --start-group problematic
- From: anonymous <johnandsara2 at cox dot net>
- Cc: binutils at sourceware dot org
- Date: Thu, 07 Jan 2016 19:06:47 -0500
- Subject: Re: Link order a pain, positional argument --start-group problematic
- Authentication-results: sourceware.org; auth=none
- Authentication-results: cox.net; none
- References: <568B8CDA dot 5070306 at yahoo dot de>
R. Diez wrote:
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.
your arguments are weak as water and inept to be discussing a huge change
also: it's absolutely untrue that "in DOS days link order didn't
matter", i was managing C and asm library symbols in and out of .o "in
the DOS days", and dependancy, symbol order certainly did matter
going "your way" we'd all have to throw away all software that worked so
that yours would "work easier for you", and have to wait for you to
finish the work - which you never would
all autmake projects would cease to work and all past sofware would have
to be rewritten by your edicts
NO THANKS - I'LL KEEP AUTOMAKE, WHICH WORKS ALLOT BETTER THAN YOU DO