October 10, 2012
Am Wed, 10 Oct 2012 15:59:42 +0300
schrieb Manu <turkeyman@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

October 10, 2012
On 10/10/2012 6:45 AM, Paulo Pinto wrote:
> In C and C++ case I am usually against it, because I favour portability over
> dependencies to a specific compiler vendor. Many years of writing multi-platform
> code do leave some scars.

Certainly, any particular use of this feature will be platform specific.

But you can use the version statement to adjust it for various platforms as required.
October 10, 2012
On 10/10/2012 6:48 AM, Marco Leise wrote:
> 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.

Actually, I think you're right. There's no technical reason why the compiler can't go directly to an executable in one step.

I've often thought of doing this.
October 10, 2012
On 10/10/2012 4:26 AM, Manu wrote:
> I think D's modules make this relationship even stronger, and it's a shame it's
> not a standard part of D.

Some object module formats do not have the ability to embed a library reference in them. Elf (cough cough), Mach-O (wheeze)
October 10, 2012
On 10/10/2012 4:49 AM, Paulo Pinto wrote:
> On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
>> Really? Is it an MS thing? I'm amazed the other compilers haven't adopted
>> that in the last 10 years or whatever.
>
> Yes, it is a Microsoft extension. I never saw it in any other C or C++ compiler.

Digital Mars C and C++ !!
October 10, 2012
On Wednesday, 10 October 2012 at 14:41:56 UTC, Walter Bright wrote:
> On 10/10/2012 6:48 AM, Marco Leise wrote:
>> 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.
>
> Actually, I think you're right. There's no technical reason why the compiler can't go directly to an executable in one step.
>
> I've often thought of doing this.

Turbo Pascal was already doing this back in 1987.

The Pascal family of languages always made me look down to C and C++ toolchains as stone age technology that I have to endure when using those languages.

This is actually one feature that I really like in JVM/.NET worlds, even in the native compiler versions that are available for them.

--
Paulo
October 10, 2012
On Wednesday, 10 October 2012 at 14:44:20 UTC, Walter Bright wrote:
> On 10/10/2012 4:49 AM, Paulo Pinto wrote:
>> On Wednesday, 10 October 2012 at 11:50:29 UTC, Manu wrote:
>>> Really? Is it an MS thing? I'm amazed the other compilers haven't adopted
>>> that in the last 10 years or whatever.
>>
>> Yes, it is a Microsoft extension. I never saw it in any other C or C++ compiler.
>
> Digital Mars C and C++ !!

I only became aware of Digital Mars thanks to D, I must confess.

When I moved away from Turbo Pascal, I started using Turbo C and Turbo C++, followed by Borland C++ and eventually Visual C++.

Then at the university I started to use vendor's C and C++ compilers of the multiple UNIX systems we had access to.

I used to see adverts for Watcom C/C++, High C/C++ and Zortech C/C++ in computer magazines, but never knew anyone that had access to them.

--
Paulo
October 10, 2012
On Wednesday, 10 October 2012 at 11:39:29 UTC, Iain Buclaw wrote:

> NB: GCC has no such equivalent, and IMO libraries should be specified
> during the linking step. Such information simply doesn't belong inside
> a source file as a source file can be compiled or assembled even
> without a linking stage.
>
> Regards,

Well, to comply with the standard it must at least ignore it.

http://dlang.org/pragma.html

I don't see this needing to be outside the source files. Actually I'd be happy if all that was supported was exporting that information, probably to the json. What bothers me with not having this information in the library is that each project I create will now need to copy and paste my lib dependencies, or the general need to remember what library is used by a given library.

Marco,

As for versions. I don't know what version of ole32.dll I'm using or how to find out, I don't really care either. But I guess it would be good to have the option though.
October 10, 2012
Am Wed, 10 Oct 2012 14:22:38 +0100
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:

> To embody the information about the relationship in the object file, one must be able to embody the information about the relationship in the assembler file.  And last time I checked there is no assembly syntax for '#pragma lib'.
> 
> 
> Regards

Waaaait, both ELF .o and COFF .obj files can contain additional free form sections and comments, right?

-- 
Marco

October 10, 2012
Am Wed, 10 Oct 2012 17:03:06 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> Am Wed, 10 Oct 2012 14:22:38 +0100
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
> 
> > To embody the information about the relationship in the object file, one must be able to embody the information about the relationship in the assembler file.  And last time I checked there is no assembly syntax for '#pragma lib'.
> > 
> > 
> > Regards
> 
> Waaaait, both ELF .o and COFF .obj files can contain additional free form sections and comments, right?

Specifically the GNU toolchain adds ".note.GNU-stack" to ELF object files on Linux. What prevents us from doing the same with ".note.D-dynlink"?

-- 
Marco