http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #18 from wbaxter@gmail.com  2008-11-20 18:53 -------
Are you (In reply to comment #17)
> Just got bitten by this one too.  Voted!
> 

Unfortunately I think the only real solution for this is a new linker.
Just out of curiosity, in your case is it the lots of templates getting
instantiated in a single file thing?  Or did you find some other way to trigger
it?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #19 from jarrett.billingsley@gmail.com  2008-11-20 19:23 -------
(In reply to comment #18)
> Are you (In reply to comment #17)
> > Just got bitten by this one too.  Voted!
> > 
> 
> Unfortunately I think the only real solution for this is a new linker.
> Just out of curiosity, in your case is it the lots of templates getting
> instantiated in a single file thing?  Or did you find some other way to trigger
> it?
> 

I'm pretty sure that's what's causing the issue I have.  It compiles with n template instantiations, and fails with n + 1.  Doesn't matter which ones I remove or add.  And I have a *lot* of them in one file.  And they're the deeply nested variadic code-generating kind.

I do horrible things.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #20 from someanon@yahoo.com  2009-02-10 17:52 -------
> Unfortunately I think the only real solution for this is a new linker.

I just thought there maybe a simple solution to implement: add a switch to the DMD compiler, e.g "-mo", means output multiple object files.

So for file foo.d the compiler will output
foo1.o
foo2.o
foo3.o
....

each only contains a limited number of fixups, so in this way, the user can add all these object files to the linker command line. This should work.

What do you think? Walter?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #21 from someanon@yahoo.com  2009-02-10 18:03 -------
Actually even without such switch, the compiler should split the object files " when there are more than 16,000 fixups in a single .obj" -- after all why the compiler should generate such obj file, if the linker cannot link it, while the compiler have all the necessary info to take the right action. (I would consider this is a minor compiler bug in this sense ;-)

And if this happened with no user option specified, the compiler should also print a friendly message, saying: "too many fixups, multiple object file foo1.obj, foo2.obj ... fooN.obj generated, please modify your link command".


(In reply to comment #20)
> > Unfortunately I think the only real solution for this is a new linker.
> 
> I just thought there maybe a simple solution to implement: add a switch to the DMD compiler, e.g "-mo", means output multiple object files.
> 
> So for file foo.d the compiler will output
> foo1.o
> foo2.o
> foo3.o
> ....
> 
> each only contains a limited number of fixups, so in this way, the user can add all these object files to the linker command line. This should work.
> 
> What do you think? Walter?
> 


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #22 from 2korden@gmail.com  2009-02-10 18:11 -------
I disagree about multiple output obj files from one source. This would make linking much harder (e.g. - compilation using makefile). I wouldn't like the build process to depend from some third party tool that would parse compiler output and adjust my linking options.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #23 from someanon@yahoo.com  2009-02-10 18:18 -------
(In reply to comment #22)
> I disagree about multiple output obj files from one source. This would make linking much harder (e.g. - compilation using makefile). I wouldn't like the build process to depend from some third party tool that would parse compiler output and adjust my linking options.
> 

Then have a compiler switch then "-mo+" means on, and "-mo-" turn it off.

I just wonder if you have ever bitten by this bug, what else you can do? The user have control of his own build process, but how the user overcome this linker bug?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #24 from bugzilla@digitalmars.com  2009-02-16 22:31 -------
The compiler already has a switch to generate multiple obj files from one source file: -multiobj. I use it for debugging. But it would be a royal pain to use if there's a lot.

A better way is to compile to a library with the -lib switch. That splits the module into a zillion obj files, and stuffs them all into the library. Then, link with the library (the main() program will still have to be separate).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #25 from someanon@yahoo.com  2009-02-17 16:59 -------
(In reply to comment #24)
> The compiler already has a switch to generate multiple obj files from one source file: -multiobj. I use it for debugging. But it would be a royal pain to use if there's a lot.

Yes, tried that: because there are sequence dependency on the order of the object file, one cannot give "foo*.obj", the linker complains lots of unresolved symbol.

I just wonder if the linker can be changed to be ".obj" order insensitive. Yes, it's a royal pain to let the user try to figure out the correct ".obj" sequence, but the linker should have all the information to find the unresolved symbols in those .objs.


> 
> A better way is to compile to a library with the -lib switch. That splits the module into a zillion obj files, and stuffs them all into the library. Then, link with the library (the main() program will still have to be separate).
> 

Also tried, when linking with the generated .lib file, it also gives "Unexpected OPTLINK Termination" error, not sure it's the same one. But I guess so.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424





------- Comment #26 from bugzilla@digitalmars.com  2009-03-07 14:28 -------
If someone can attach to this an object file with too many fixups, that would be helpful. Or email it to me.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=424


Jarrett Billingsley <jarrett.billingsley@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley@gmail.c
                   |                            |om




--- Comment #27 from Jarrett Billingsley <jarrett.billingsley@gmail.com>  2009-06-20 23:54:07 PDT ---
Open a windows command prompt and run the following line:

for /L %i in (1,1,17000) do @echo void func%i(){} >> test.txt

This creates test.txt with 17,000 functions.

Then create test.d in the same dir:

module test;
mixin(import("test.txt"));
void main() {}

Now, compile *with the following commandline*.

dmd test.d -g -J.

This causes OPTLINK v8.00.1 to crash with EIP=00412793 as sa mentioned.

For more testing, delete test.txt and run the shell line above with different values.  16000 does not crash.  Interestingly, 16500 neither succeeds nor fails; the linker apparently hangs and does not use any CPU.

If you want a real-world test, you're going to have to install some third-party D libraries.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------