www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - * Win32 issues with Templates and Libs *

reply kris <foo bar.com> writes:
dmd on Win32 has recently become much better at handling Templates and 
libs, but it still has some issues. I got lucky and isolated one of 
them, listed below:

Two modules, one called test.d and the other tester.d -- add test.d to a 
library called test.lib, and then compile+link tester.d against said 
lib. You should get a correctly linked app that runs and emits "hello".

============
module test;

extern (C) int printf (char*, ...);

class Test (T)
{
         final void show (T[] msg)
         {
                 printf ("%.*s\n", msg);
         }
}

//Test!(char) Global;
==========


==========
module tester;

pragma (lib, "test.lib");

import test;

void main()
{
         auto t = new Test!(char);
         t.show ("hello");
}
==========

Now, remove the comment in test.d so that 'Global' is exposed, and 
rebuild the lib. You should now get linker errors of this nature:

dmd tester
C:\d\dmd\bin\..\..\dm\bin\link.exe tester,,,user32+kernel32/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved tester.obj(tester) Error 42: Symbol Undefined _D4test11__T4TestTaZ4Test7__ClassZ tester.obj(tester) Error 42: Symbol Undefined _D4test11__T4TestTaZ4Test4showMFAaZv --- errorlevel 2 This error does not occur with dmd on linux, nor when using GDC on any supported platform that we've tried. It's only the dmd/Win32 combination Please can we have this fixed soon?
Feb 19 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
The problem is that one of two kinds of COMDAT sections can be generated:

1) Only one COMDAT with a particular name may appear
2) Any number of COMDATs with the same name may appear, pick one and 
discard the others

Instantiating a template produces a COMDAT section. Since multiple 
modules may instantiate a template with the same arguments, without 
knowing about each other, option (2) is used.

When a module is put into a library, a dictionary is created for the 
library, essentially an associative array of object modules indexed by 
symbol names. COMDATs of option (1) get put into the dictionary, ones of 
option (2) do not. Why not? Because if there's more than one of (2), 
which object module do you pull in? No way to tell.

Thus, the problem you're seeing. The solution is:

1) have another global in module test that gets pulled in, thus also 
pulling the COMDAT along with it, and resolving the symbol.

2) explicitly link in module test

So, you might ask, why not just regenerate the template instantiation 
every time you use it? Because it would lead to a lot of object file bloat.
Feb 20 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Mmm... yummy technical details :P

There seem to be quite a few problems/annoyances due to limitations in
the object file formats.  It makes one wonder whether it wouldn't be a
good idea to simply make a new one that properly supported D's feature
set...

Of course, that would involve touching OPTLINK, something I gather no
one is particularly keen on :P

	-- Daniel

Walter Bright wrote:
 The problem is that one of two kinds of COMDAT sections can be generated:
 
 1) Only one COMDAT with a particular name may appear
 2) Any number of COMDATs with the same name may appear, pick one and
 discard the others
 
 Instantiating a template produces a COMDAT section. Since multiple
 modules may instantiate a template with the same arguments, without
 knowing about each other, option (2) is used.
 
 When a module is put into a library, a dictionary is created for the
 library, essentially an associative array of object modules indexed by
 symbol names. COMDATs of option (1) get put into the dictionary, ones of
 option (2) do not. Why not? Because if there's more than one of (2),
 which object module do you pull in? No way to tell.
 
 Thus, the problem you're seeing. The solution is:
 
 1) have another global in module test that gets pulled in, thus also
 pulling the COMDAT along with it, and resolving the symbol.
 
 2) explicitly link in module test
 
 So, you might ask, why not just regenerate the template instantiation
 every time you use it? Because it would lead to a lot of object file bloat.
-- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Feb 20 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:eret4n$2ors$1 digitalmars.com...
 Mmm... yummy technical details :P

 There seem to be quite a few problems/annoyances due to limitations in
 the object file formats.  It makes one wonder whether it wouldn't be a
 good idea to simply make a new one that properly supported D's feature
 set...
That would be awesome. If D compilers could still generate some kind of "standard" object file for linking with other languages, and then a "D object" for D compilers that had extra features. The D object format could even be standardized and made sure to be compatible across D compilers (something C++ sure can't promise!). I always thought it would be cool if templates were sort of .. compiled almost into a scripting language intermediate representation. Then, to instantiate a template, either one it just compiled or one it loaded from a D object, the compiler would just interpret the script. This way a generic "how to instantiate template X" would be stored in the object file, and you wouldn't need the original definition. This is probably a lot of work though.
 Of course, that would involve touching OPTLINK, something I gather no
 one is particularly keen on :P
Phh, if it means getting away from OMF, I'm all for it ;)
Feb 20 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 The problem is that one of two kinds of COMDAT sections can be generated:
 
 1) Only one COMDAT with a particular name may appear
 2) Any number of COMDATs with the same name may appear, pick one and 
 discard the others
 
 Instantiating a template produces a COMDAT section. Since multiple 
 modules may instantiate a template with the same arguments, without 
 knowing about each other, option (2) is used.
 
 When a module is put into a library, a dictionary is created for the 
 library, essentially an associative array of object modules indexed by 
 symbol names. COMDATs of option (1) get put into the dictionary, ones of 
 option (2) do not. Why not? Because if there's more than one of (2), 
 which object module do you pull in? No way to tell.
Let's back up for a second. First, in the situation Kris mentioned, how many instances of Test!(char) exist altogether? I had expected there to be two: one in test.lib and one in tester.obj. But in this case I wouldn't expect the link error to occur, so perhaps you're saying that when the compiler sees "Test!(char) Global" in module test, it doesn't bother to create one in tester.obj? Also, how do COMDATs differ from normal code blocks? ie. Why is the linker able to resolve normal symbols in libraries but not templates? Wouldn't the symbol name in both cases be enough to sort things out?
 Thus, the problem you're seeing. The solution is:
 
 1) have another global in module test that gets pulled in, thus also 
 pulling the COMDAT along with it, and resolving the symbol.
 
 2) explicitly link in module test
 
 So, you might ask, why not just regenerate the template instantiation 
 every time you use it? Because it would lead to a lot of object file bloat.
I guess this answers my question above: the compiler sees "Test!(char) Global" and doesn't bother to create another instance of the code. But surely being able to create a functional application is preferable in this case. Won't an optimizing linker throw out duplicates anyway? Who cares if the object files are bloated, if that's the only workable option here? Or perhaps this suggests the need for a D linker that builds a catalog of symbols inside libraries before linking instead of the behavior you describe above? Sean
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 Let's back up for a second.  First, in the situation Kris mentioned, how 
 many instances of Test!(char) exist altogether?
One.
 I had expected there to 
 be two: one in test.lib and one in tester.obj.  But in this case I 
 wouldn't expect the link error to occur, so perhaps you're saying that 
 when the compiler sees "Test!(char) Global" in module test, it doesn't 
 bother to create one in tester.obj?
That's right.
 Also, how do COMDATs differ from normal code blocks?
COMDATs are each placed in their own segment.
 ie. Why is the 
 linker able to resolve normal symbols in libraries but not templates? 
Because normal symbols cannot appear multiple times (if they did, you get multiple definition errors at link time).
 Wouldn't the symbol name in both cases be enough to sort things out?
No.
 I guess this answers my question above: the compiler sees "Test!(char) 
 Global" and doesn't bother to create another instance of the code.  But 
 surely being able to create a functional application is preferable in 
 this case.  Won't an optimizing linker throw out duplicates anyway?
The problem is not knowing which module to link in - after all, there are (possibly) other global symbols in the module.
 Who 
 cares if the object files are bloated, if that's the only workable 
 option here?
You'll care <g> once templates get complex enough. It's been a big problem with C++.
 Or perhaps this suggests the need for a D linker that 
 builds a catalog of symbols inside libraries before linking instead of 
 the behavior you describe above?
Building a linker or object file with non-standard semantics has its own set of problems.
Feb 20 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Who cares if the object files are bloated, if that's the only workable 
 option here?
You'll care <g> once templates get complex enough. It's been a big problem with C++.
I'd prefer bloated object files over link errors as well... Perhaps a command-line option could be added to emit templates in situations like this, so object files don't increase in size because of this unless necessary?
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:
 Walter Bright wrote:
 You'll care <g> once templates get complex enough. It's been a big 
 problem with C++.
I'd prefer bloated object files over link errors as well... Perhaps a command-line option could be added to emit templates in situations like this, so object files don't increase in size because of this unless necessary?
My experience with those command line options is almost nobody is able to use them successfully. (They were used in the early days of C++ before COMDATs.)
Feb 20 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 Walter Bright wrote:
 You'll care <g> once templates get complex enough. It's been a big 
 problem with C++.
I'd prefer bloated object files over link errors as well... Perhaps a command-line option could be added to emit templates in situations like this, so object files don't increase in size because of this unless necessary?
My experience with those command line options is almost nobody is able to use them successfully. (They were used in the early days of C++ before COMDATs.)
That raises an interesting question: seeing as how it's using the same backend, how does DMC handle this problem for C++? -- - EricAnderton at yahoo
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Feb 20 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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.
Shouldn't this reasoning make it easier to provide working and efficient template instances together with libs in D? 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. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Feb 20 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Feb 21 2007
prev sibling parent reply James Dennett <jdennett acm.org> writes:
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
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Feb 21 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Feb 21 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
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
Feb 21 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 
 Who cares if the object files are bloated, if that's the only workable 
 option here?
You'll care <g> once templates get complex enough. It's been a big problem with C++.
 Or perhaps this suggests the need for a D linker that builds a catalog 
 of symbols inside libraries before linking instead of the behavior you 
 describe above?
Building a linker or object file with non-standard semantics has its own set of problems.
Thanks for the reply. Your proposed solution finally reminded me that we had this exact conversation a few years ago :-) It's a nasty hack, but what if the compiler performed your proposed solution during compilation:
 1) have another global in module test that gets pulled in, thus also
 pulling the COMDAT along with it, and resolving the symbol.
In modules containing global template instances, generate a symbol, let's say _Dforcelink, which is implicitly referenced in importing modules. Is this possible? Sean
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 Thanks for the reply.  Your proposed solution finally reminded me that 
 we had this exact conversation a few years ago :-)  It's a nasty hack, 
 but what if the compiler performed your proposed solution during 
 compilation:
 
  > 1) have another global in module test that gets pulled in, thus also
  > pulling the COMDAT along with it, and resolving the symbol.
 
 In modules containing global template instances, generate a symbol, 
 let's say _Dforcelink, which is implicitly referenced in importing 
 modules.  Is this possible?
What happens if you have two such modules in a library?
Feb 20 2007
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Thanks for the reply.  Your proposed solution finally reminded me that 
 we had this exact conversation a few years ago :-)  It's a nasty hack, 
 but what if the compiler performed your proposed solution during 
 compilation:

  > 1) have another global in module test that gets pulled in, thus also
  > pulling the COMDAT along with it, and resolving the symbol.

 In modules containing global template instances, generate a symbol, 
 let's say _Dforcelink, which is implicitly referenced in importing 
 modules.  Is this possible?
What happens if you have two such modules in a library?
Oops... the name would have to be mangled to include the module name. I suppose this still raises issues for some corner-cases, but it's all I can think of. Sean
Feb 20 2007
prev sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Tue, 20 Feb 2007 20:46:39 +0200, Walter Bright  
<newshound digitalmars.com> wrote:
 Sean Kelly wrote:
 Let's back up for a second.  First, in the situation Kris mentioned,  
 how many instances of Test!(char) exist altogether?
One.
 I had expected there to be two: one in test.lib and one in tester.obj.   
 But in this case I wouldn't expect the link error to occur, so perhaps  
 you're saying that when the compiler sees "Test!(char) Global" in  
 module test, it doesn't bother to create one in tester.obj?
That's right.
[snip] For a person which doesn't know how linkers and object files work, this seems to be an 'interesting' problem. <g> I mean, there is an instance of Test!(char) in test.lib, but the linker doesn't found it because there might be another instance in another object file? And at the same time, the compiler tries to ensure that there will be only one instance of Test!(char)... What will be the number of instances of Test!(char) if test.d does not contain 'Test!(char) Global;', and I have another module tester2.d, similar to tester.d, which also uses the Test!(char) class? I except two, one for tester.d and one for tester2.d. That is, at least, when the files are compiled independently. And if the compiler would be smart enough to create only one instance in that case, doesn't it mean the same linker error will occur then too?
Feb 20 2007
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:
 The problem is that one of two kinds of COMDAT sections can be generated:
 
 1) Only one COMDAT with a particular name may appear
 2) Any number of COMDATs with the same name may appear, pick one and 
 discard the others
 
 Instantiating a template produces a COMDAT section. Since multiple 
 modules may instantiate a template with the same arguments, without 
 knowing about each other, option (2) is used.
 
 When a module is put into a library, a dictionary is created for the 
 library, essentially an associative array of object modules indexed by 
 symbol names. COMDATs of option (1) get put into the dictionary, ones of 
 option (2) do not. Why not? Because if there's more than one of (2), 
 which object module do you pull in? No way to tell.
 
 Thus, the problem you're seeing. The solution is:
 
 1) have another global in module test that gets pulled in, thus also 
 pulling the COMDAT along with it, and resolving the symbol.
 
 2) explicitly link in module test
 
 So, you might ask, why not just regenerate the template instantiation 
 every time you use it? Because it would lead to a lot of object file bloat.
Would you perhaps explain why ELF does not have this problem? Thanks
Feb 20 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Feb 20 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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.
That's not entirely true. Symbols in ELF can be said to be either LOCAL, GLOBAL or WEAK. The local ones are per module, the global ones you can only have one of, whereas the weak ones you can have multiple of and one (probably the first, depending on linker etc) is chosen. IIRC -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Feb 20 2007
parent Walter Bright <newshound digitalmars.com> writes:
Lars Ivar Igesund 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.
That's not entirely true. Symbols in ELF can be said to be either LOCAL, GLOBAL or WEAK. The local ones are per module, the global ones you can only have one of, whereas the weak ones you can have multiple of and one (probably the first, depending on linker etc) is chosen.
The template instances are put in the .o file as GLOBAL ones.
Feb 20 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
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?
Feb 20 2007
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Feb 20 2007
prev sibling parent kris <foo bar.com> writes:
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
Feb 20 2007
prev sibling parent reply kris <foo bar.com> writes:
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?
Feb 21 2007
parent Walter Bright <newshound digitalmars.com> writes:
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.
Feb 21 2007