On 11 October 2012 12:47, Manu <turkeyman@gmail.com> wrote:
> On 11 October 2012 14:35, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>> On 10/10/2012 11:49 PM, Jacob Carlborg wrote:
>>>
>>> Maybe it's time to update the old tool chain that we inherited form the
>>> 70s, but
>>> this is a totally different discussion.
>>
>>
>> Writing a new linker for each platform is a major undertaking.
>
>
> Well Microsoft's linker is obviously capable of finding lib details in the
> object files.
> Iain almost sounded like he had a working theory for ld.
> I know nothing of OSX. LLVM?

I also said talk is cheap, and there are more great ideas than what will ever be implemented.  In open source development, if you want to see a feature implemented, you are usually left to do it yourself and send patches to the right places.  Core devs love patches, code is expensive. :~)


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 11 October 2012 at 12:11:47 UTC, Manu wrote:
> LLVM?

LLVM is capable of emitting directly to object files, but linking is not part of its (core) agenda. In LDC, we currently depend on "the system linker", i.e. GCC on Unixen and link.exe on MSVC/Windows. This might change if/when LLD (http://lld.llvm.org/) becomes stable, though.

David

On 10/11/2012 4:59 AM, Jacob Carlborg wrote:
> On 2012-10-11 13:35, Walter Bright wrote:
>
>> Writing a new linker for each platform is a major undertaking.
>
> Of course, but isn't writing a new compiler for each platform that as well?
>

Are you saying that just to support pragma(lib), we should write a new linker?

On Thu, Oct 11, 2012 at 08:46:49AM +0200, Jacob Carlborg wrote:
> On 2012-10-11 04:54, Jesse Phillips wrote:
[...]
> >"Mister programmer man, you have unspecified library versions for... What do would you like to do with them? Did the currently selected version work out for you?" The PM tells the programmer.
> 
> So this is just a guessing game, trail and error?
> 
> I think it would be much better to work with packages and not individual libraries. You would just tell the build tool, compiler or whatever to use package "foo". Then the package manager figures out what libraries and dependencies it needs to link to and also the path to the import files.
[...]

Yeah, one of the poor design decisions of the early Redhat packaging system was to allow packages to depend on individual files, rather than packages. The result was a disastrous mess: some packages export different versions of the same file, and only a subset of them will work, leading to hair-tearing dependencies. Packages would step over each other's files, causing problems with each other and the rest of the system that depended on the same files, ad nauseum.

More modern packaging systems deal with packages as units, and do not allow packages to export the same files. Plus, packages can come with metadata that specify the exact version, build, etc., of a library, making it possible for multiple versions of the same library to exist on a system, and programs to pick up the exact version they were compiled with. A huge improvement indeed.

You'll be surprised at how many applications will fail horribly because a careless library author changed the ABI (often without changing the API) without bumping the library version, causing calls to the old library functions to fail inexplicably, or worse, produce subtly wrong results.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and those who can't.

On 11 October 2012 13:18, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 11 October 2012 at 12:11:47 UTC, Manu wrote:
>>
>> LLVM?
>
>
> LLVM is capable of emitting directly to object files, but linking is not part of its (core) agenda. In LDC, we currently depend on "the system linker", i.e. GCC on Unixen and link.exe on MSVC/Windows. This might change if/when LLD (http://lld.llvm.org/) becomes stable, though.
>
> David

Does LDC only build one executable?



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote:
> Does LDC only build one executable?

What do you mean by "only one executable" – only one object file? If the latter, then the answer depends on whether you pass the -singleobj switch at compile time. If it is specified, all the LLVM modules which would be codegen'd as separate object files are linked together internally before emitting them, if not, individual object files are generated.

David

On 11 October 2012 16:29, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote:
>>
>> Does LDC only build one executable?
>
>
> What do you mean by "only one executable" – only one object file? If the latter, then the answer depends on whether you pass the -singleobj switch at compile time. If it is specified, all the LLVM modules which would be codegen'd as separate object files are linked together internally before emitting them, if not, individual object files are generated.
>
> David

Not what the LDC compiler does, the actual /usr/bin/ldc executable itself.  Is it in one pieces, or in pieces?  eg:  GDC is in two pieces, gdc and cc1d.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 11 October 2012 17:00, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 11 October 2012 16:29, David Nadlinger <see@klickverbot.at> wrote:
>> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote:
>>>
>>> Does LDC only build one executable?
>>
>>
>> What do you mean by "only one executable" – only one object file? If the latter, then the answer depends on whether you pass the -singleobj switch at compile time. If it is specified, all the LLVM modules which would be codegen'd as separate object files are linked together internally before emitting them, if not, individual object files are generated.
>>
>> David
>
> Not what the LDC compiler does, the actual /usr/bin/ldc executable itself.  Is it in one pieces, or in pieces?  eg:  GDC is in two pieces, gdc and cc1d.
>

Effectively, is it one executable that handles the entire compilation process from parsing options, compiling and linking.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 11 October 2012 at 16:01:09 UTC, Iain Buclaw wrote:
> On 11 October 2012 16:29, David Nadlinger <see@klickverbot.at> wrote:
>> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote:
>>>
>>> Does LDC only build one executable?
>> […]
>
> Not what the LDC compiler does, the actual /usr/bin/ldc executable
> itself.  Is it in one pieces, or in pieces?  eg:  GDC is in two
> pieces, gdc and cc1d.

Ah, now I see what you mean. Yes, LDC consists of only one executable.

David

On 2012-10-11 16:23, H. S. Teoh wrote:

> Yeah, one of the poor design decisions of the early Redhat packaging
> system was to allow packages to depend on individual files, rather than
> packages. The result was a disastrous mess: some packages export
> different versions of the same file, and only a subset of them will
> work, leading to hair-tearing dependencies. Packages would step over
> each other's files, causing problems with each other and the rest of the
> system that depended on the same files, ad nauseum.

That sounds even worse, a terrible, terrible idea.

-- 
/Jacob Carlborg