Lars Ivar Igesund wrote:
> Also, on the topic of OMF, you suggested once that OMF was a better format
> than ELF? I've yet to see any justification for such a claim, currently it
> looks a tad behind the times.

Elf has its problems, too.

kris wrote:

> At this time, it is just not possible for us to construct a reliable Tango.lib which, given our collective D 'expertise', seems entirely bogus :)
> 
> Can you resolve it in some reliable and user-friendly manner?
> 

I'd like to throw in my support for this request. This is my last major gripe about D. Templates should just work out of the box, regardless of the type of output being compiled (executable or library), without requiring any tomfoolery from the programmer to work around shortcomings in the object file format. Build tools like Bud and Rebuild help alleviate the situation for projects that distribute source, but that's no solution.

kris wrote:
> Walter Bright wrote:
> 
>> kris wrote:
>>
>>> Would you perhaps explain why ELF does not have this problem? Thanks
>>
>>
>>
>> The ar format doesn't care if there are multiple definitions of the same symbol. The linker just picks one (presumably the first one it finds) and pulls in that module along with whatever else happens to be in that module.
> 
> 
> For whatever reason, that approach appears to work quite effectively?
> 
> The problem here is that one cannot currently build a production quality lib where templates are involved. It's not reasonable or feasible to expect a user to understand and compensate for the issues involved, nor is it entirely feasible to construct the lib in such a manner that the rather delicate balance is maintained. We wish it were.
> 
> The reality problem is this: the more extensive the lib, and the more use it makes of templates, the fragility of it appears to increase exponentially. As does the difficulty of reverting that fragility.
> 
> At this time, it is just not possible for us to construct a reliable Tango.lib which, given our collective D 'expertise', seems entirely bogus :)
> 
> Can you resolve it in some reliable and user-friendly manner?
> 


For example, I get this when linking certain examples:

..\..\tango.lib(Socket)
 Error 42: Symbol Undefined _D12TypeInfo_AAa6__initZ
--- errorlevel 1

Through a slow and entirely tedious process of 'playing' with the lib contents (which took all day), I discover that removing a very specific set of modules cause this link error to go away. Some of those modules make reference to one of two IFTI modules.

With another module, I find that commenting out a single method eliminates the linker error. There are no templates within this module, but the particular method creates and returns an AA ...... arrgghhhh!

How can anyone deal with that kind of development environment and remain sane? How could they possibly know how to resolve these? I ask you :)

Now it's onto the next example that refuses to link. I'm pretty sure it is cold seawater I can feel around my ankles now

Walter Bright wrote:
> Pragma wrote:
>> That raises an interesting question: seeing as how it's using the same backend, how does DMC handle this problem for C++?
> 
> Unlike D, a C++ compiler has no idea what templates are instantiated in other files. So it instantiates everything. This is one reason why C++ builds are so much slower than D.

It's fairly common for C++ compilers to use some kind
of storage to record which templates are instantiated
from which files, and has been for quite a few years.

-- James

James Dennett wrote:
> Walter Bright wrote:
>> Pragma wrote:
>>> That raises an interesting question: seeing as how it's using the same
>>> backend, how does DMC handle this problem for C++?
>> Unlike D, a C++ compiler has no idea what templates are instantiated in
>> other files. So it instantiates everything. This is one reason why C++
>> builds are so much slower than D.
> 
> It's fairly common for C++ compilers to use some kind
> of storage to record which templates are instantiated
> from which files, and has been for quite a few years.

Yeah, I've considered building such a thing. But it would be complex, and the programmer would have to accommodate its idiosyncracies. Better off fixing the language to support proper modules.

Walter Bright wrote:
> kris wrote:
>
>> If you prefer, we could switch to the #D thread so as not to pollute
>> this one?
>
>
> Ok, but I'll need an example. I'd start by comparing .map files.

The BIG version ... you're gonna love this:

186kb of code
360kb of data           O^O
plus some bss, etc

Debug symbols are not enabled in the lib (no flags at all). Will send you the two map files if you like?

kris wrote:
> Debug symbols are not enabled in the lib (no flags at all). Will send you the two map files if you like?

Won't help me. See the new thread I started on this.

Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> Pragma wrote:
>>>> That raises an interesting question: seeing as how it's using the same
>>>> backend, how does DMC handle this problem for C++?
>>> Unlike D, a C++ compiler has no idea what templates are instantiated in
>>> other files. So it instantiates everything. This is one reason why C++
>>> builds are so much slower than D.
>>
>> It's fairly common for C++ compilers to use some kind
>> of storage to record which templates are instantiated
>> from which files, and has been for quite a few years.
> 
> Yeah, I've considered building such a thing. But it would be complex, and the programmer would have to accommodate its idiosyncracies. Better off fixing the language to support proper modules.

For what it's worth, module support has been removed from the list of features slated for C++ 0x.  They ran out of time.


Sean

Walter Bright wrote:

> Lars Ivar Igesund wrote:
>> Also, on the topic of OMF, you suggested once that OMF was a better format than ELF? I've yet to see any justification for such a claim, currently it looks a tad behind the times.
> 
> Elf has its problems, too.

That may be so, but according to D lore/rumours, it is actually working in all cases, and on all platforms (in the sense that it isn't a factor in hindering adoption to a given platform).

According to your descriptions of the problematics in the template/lib scene, OMF is one of the offending problem areas. According to you, it can't properly handle all use cases of D as a programming language. I have yet to see an example where ELF produce similar problems (or even anyone at all) when using D.

It used to be that D was considered to have second rate support on non-Win32 platforms, but I now mostly feel sorry for those users that need to use that platform for D development (The mess that is DLL is M$ fault, I won't blame Digital Mars for that ;). Of course, helping out on projects that want to be crossplatform, I feel the frustration by proxy.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> Pragma wrote:
>>>> That raises an interesting question: seeing as how it's using the same backend, how does DMC handle this problem for C++?
>>> Unlike D, a C++ compiler has no idea what templates are instantiated in other files. So it instantiates everything. This is one reason why C++ builds are so much slower than D.
>>
>> It's fairly common for C++ compilers to use some kind
>> of storage to record which templates are instantiated
>> from which files, and has been for quite a few years.
> 
> Yeah, I've considered building such a thing. But it would be complex, and the programmer would have to accommodate its idiosyncracies. Better off fixing the language to support proper modules.

You may well be right; while I've seen such systems work
well most of the time, they usually need help if your
build structure is not simple (for example, if you build
multiple different libraries based on overlapping sets
of object files).

-- James