This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Link order a pain, positional argument --start-group problematic

R. Diez wrote:
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:

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]