#pragma comment (lib, ...)

Marco Leise Marco.Leise at gmx.de
Wed Oct 10 06:48:03 PDT 2012


Am Wed, 10 Oct 2012 15:59:42 +0300
schrieb Manu <turkeyman at gmail.com>:

> None of those things actually embody the information about the
> relationship, nor can they. The source code does, and nothing else.
> Features that imply the dependency may (and often are) be disabled at
> compile time.
> I rather like that the compiler is able to put a note in the object file
> that it depends on a particular lib, because it does.
> […]

I share your opinion whole-heartedly! I've been on #rust,
yesterday and someone had problems with the bindings generator
not writing out the library name:

#[link_args = "-l"]

As you can see, you see nothing. But the question here really
is: "Don't you force the language into using 'ld' as a linker
if you use it's command-line?"

Linking is just time you wait until you can run your program.
In a modern language I'd like to understand compilation and
linking as one process. LTO and pragma(lib, ...) are steps
in that direction. (And single file compilation should work
without seems compared to one-step compilation.)

Part or all of the linker should be in the compiler, to allow
external(...)-declarations to work without additional platform
and compiler dependent command-line additions. Problematic
cases are for example the 'escape' switches used by different
compilers to pass arguments on to the linker in one-step mode,
or 'missing' .so-names on some distributions that make it
difficult to name a specific version, e.g. lua-4.2.

We should learn from package managers and improve on
pragma(lib, ...) to support dependencies like this:

// lua.dll or liblua.so.4 (or highest liblua.so.4.*)
pragma(lib, "lua-4.*");
// can match mysqlclient.dll or libmysqlclient.so.16
pragma(lib, ">=mysqlclient-12");

This would go through the system specific library paths and
lookup version information from .dlls or so-names. In my
opinion, just linking to a library without version constraints
is not enough.

-- 
Marco



More information about the Digitalmars-d mailing list