Bug 12485 - Support for automatic linking via pragma
Summary: Support for automatic linking via pragma
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Ian Lance Taylor
Depends on:
Reported: 2011-02-12 17:01 UTC by Olaf van der Spek
Modified: 2011-03-04 14:26 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Olaf van der Spek 2011-02-12 17:01:49 UTC
MSVC supports the following pragma, which can be used to automatically link a
library when a header file is included. This is used by for example Boost.

#pragma comment(lib, "requiredLibrary.lib")

Unfortunately, gold doesn't support this. Could you add it?

I assume this needs coordination with gcc.

Comment 1 Olaf van der Spek 2011-02-28 15:20:38 UTC
Comment 2 Ian Lance Taylor 2011-02-28 16:13:05 UTC
It sounds like a reasonable idea to me, but to be honest it is not high on my priority list.  No existing Unix linker works that way.  The gold linker is free software, so brand new ideas like this tend to be written by the people who would like to see them implemented.  If you are unable to implement it yourself, I would recommend sending a note to the binutils@sourceware.org mailing list.  However, please do not be surprised if nobody takes this up for you.  Most free software developers are not waiting around trying to think of something to do.  Most of them have far too much to do, and fixing bugs and implementing features that they use themselves is normally going to take priority over implementing a brand new feature which nobody is currently using.

I'm not trying to discourage you or to tell you that you are doing anything wrong.  I'm just describing my perception of how free software development works.  It's driven by volunteers who write code.  Ideas are cheap, and there are far more ideas than will ever be implemented.  Working code is expensive.

I'm also not saying that I will never implement this myself.  But I am unlikely to implement it any time soon.
Comment 3 H.J. Lu 2011-02-28 19:42:19 UTC
Here is a proposal for H/W S/W Attribute:

1. Minimum ISAs:
	a. Only has EM_386 and EM_X86_64
		i. IA32:
			1) i386
			2) i486
			3) Pentium
			4) Pentium Pro
			5) MMX
			6) SSE
			7) AVX
		ii. EM_X86_64:
			1) SSE2
			2) AVX
		iii. Atom:
			1) SSSE3
	b. Executables/DSOs compiled for Atom, … won't run on all x86 platforms:
		i. Loader can't tell  from EM_386/EM_X86_64 to know what ISAs a program requires.
2. GNU binutils supports build attribute and run-time platform compatibility data
	a. Build attribute:
		i. Used by linker to set run-time platform compatibility data
	b. Run-time platform compatibility data
		i. Used by loader to check platform capabilities required by an executable file/DSO.
	c. Extend to x86:
		i. H/W:
			1) Required ISAs.
				a) Define ISAs tags/attributes
		ii. S/W:
			1) Stack size
			2) Additional libraries:
				a) http://sourceware.org/bugzilla/show_bug.cgi?id=12485
		iii. Extendable:
Comment 4 Cary Coutant 2011-02-28 23:00:28 UTC
I think it's a great idea, and have wanted to see this feature in Unix for a long time. Yes, there will need to be some cooperation with gcc, but that could be as simple as a note section, from which the linker could read additional -l options. There will be some additional complexity in determining where in the link order these additional options should be placed: a complete solution would have each library and each relocatable object note all of its direct dependencies so that the linker could construct a topological ordering. At that point, you could in theory just say "ld main.o" and get a working program out.
Comment 5 Olaf van der Spek 2011-03-04 14:26:07 UTC
On Mon, Feb 28, 2011 at 8:42 PM, hjl.tools at gmail dot com
<sourceware-bugzilla@sourceware.org> wrote:
> --- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-28 19:42:19 UTC ---
> Here is a proposal for H/W S/W Attribute:

This does not sound related to this feature request.
Wrong bug number?