Bill Baxter wrote:
> Anyone have a clue where to look for how to work around this?

if it's D1.0, maybe try GDC with cygwin.

Jascha Wetzel wrote:

> if it's D1.0, maybe try GDC with cygwin.

You can also use GDC with mingw, if you don't feel like Unix.

http://gdcwin.sourceforge.net/

Not sure how the new D2 support is in GDC, though. Anyone ?

gcc/d/setup-gcc.sh --d-language-version=2

--anders

Bill Baxter wrote:
> Jascha Wetzel wrote:
>> Bill Baxter wrote:
>>> Anyone have a clue where to look for how to work around this?
>>
>> if it's D1.0, maybe try GDC with cygwin.
> 
> I found a workaround.
> 
> I think it's a symbol length issue.
> I was putting an alias for this type:
> S5dflat14SparseGeMatrix48__T14SparseGeMatrixTS5dflat3CCS10__T3CCSTfZ3CCSZ14SparseGeMatrix 
> 
> 
> inside a class with a template paramter of this type:
> C8OpenMesh4Core4Mesh21PolyMesh_ArrayKernelT27__T21PolyMesh_ArrayKernelTZ21PolyMesh_ArrayKernelT 
> 
> 
> Is the combination of those enough to send OPTLINK past it's symbol length limit?

Maybe the same as bugzilla 1439?

Bill Baxter wrote:
> Jascha Wetzel wrote:
> 
>> Bill Baxter wrote:
>>
>>> Anyone have a clue where to look for how to work around this?
>>
>>
>> if it's D1.0, maybe try GDC with cygwin.
> 
> 
> I found a workaround.
> 
> I think it's a symbol length issue.
> I was putting an alias for this type:
> S5dflat14SparseGeMatrix48__T14SparseGeMatrixTS5dflat3CCS10__T3CCSTfZ3CCSZ14SparseGeMatrix 
> 
> 
> inside a class with a template paramter of this type:
> C8OpenMesh4Core4Mesh21PolyMesh_ArrayKernelT27__T21PolyMesh_ArrayKernelTZ21PolyMesh_ArrayKernelT 
> 
> 
> Is the combination of those enough to send OPTLINK past it's symbol length limit?
> 

No, I think not. IIRC DMD runs into symbol length limits somewhere around (?) 11K /after/ gziping them. So if you can read the symbol (no gzip), your not even close.

> Anyway, if I put the alias outside that class it links ok.
> 
> --bb

Bill Baxter wrote:
> ---------------------------
> Unexpected OPTLINK Termination at EIP=0044C37B


I know that optlink can crash if you have a static array that exceeds 16Mb in size.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Bill Baxter wrote:
> > ---------------------------
> > Unexpected OPTLINK Termination at EIP=0044C37B
> I know that optlink can crash if you have a static array that exceeds 16Mb in size.

The bug was reported long time ago:

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

(hey, and you updated it:)

------- Comment #10 From Bill Baxter  2007-11-14 18:55  [reply] -------
....

To reproduce, check out revision 111 of OpenMesh from the svn repository:

If you don't have dsss installed, install it first
(http://www.dsource.org/projects/dsss)

Then:

$ mkdir scratch
$ cd scratch
$ svn co -r111 http://svn.dsource.org/projects/openmeshd/trunk .
$ cd OpenMeshD\OpenMesh\Apps\GLViewer
$ dsss net deps
$ dsss build -version=OPTLINKIsMyFriend

If there are complaints about Helix things, you may need to go to the Helix dir and do a "dsss build && dsss install"


------- Comment #11 From Bill Baxter 2007-11-14 23:37 [reply] -------

Upgrading the severity because I just ran into this again adding to an unrelated part of the main .d file.  Moving the added code to a different file fixed it for now but that may not always be so easy to do if the code needs to be in the generic, templated part of things.  Then it seems it will end up instantiating in the main .obj file no matter where I put it.

Also further rearrangement of the code started triggering the "previous definition different blahblah_initZ" bug.

So, yeh, this is a bad one, and it affects more than just code with gigantic source files.   It appears to affect any template library with a few tens of thousands of lines of code.

Bill Baxter Wrote:
> My problem with GDC is just that it lags so far behind DMD.  But maybe it's time for me to try to become part of the solution there.
> 
> --bb

Yeah, I personally think GDC is the way to go.

On principle it:

1) Uses a standard platform for compilers, sharing optimization techniques and "stuff" with other compilers.

2) Is open source.

3) Is cross platform (including x86-64)

4) Should be less maintenance work than dmd?  (backend doesn't need work?)

That's my take on it anyways.

Bill Baxter Wrote:

> Dan wrote:
> > Bill Baxter Wrote:
> >> My problem with GDC is just that it lags so far behind DMD.  But maybe it's time for me to try to become part of the solution there.
> >>
> >> --bb
> > 
> > Yeah, I personally think GDC is the way to go.
> > 
> > On principle it:
> > 
> > 1) Uses a standard platform for compilers, sharing optimization techniques and "stuff" with other compilers.
> > 
> > 2) Is open source.
> > 
> > 3) Is cross platform (including x86-64)
> > 
> > 4) Should be less maintenance work than dmd?  (backend doesn't need work?)
> > 
> > That's my take on it anyways.
> 
> I just emailed Anders B. and David F. a while ago to see if there's anything I could do to help keep it more up to date.
> 
> That's really my only gripe with it, it just lags behind too much.  And I definitely like the fact that it generates faster FP code than DMD.
> 
> --bb

I would probably take up renewed interest in D if it supported the x86-64 - both from D source and inline assembler.  The x86-32 is obsolete.

At that point, my only major gripe would be that hello world takes up 80kb.

Dan wrote:
> I would probably take up renewed interest in D if it supported the x86-64 - both from D source and inline assembler.  The x86-32 is obsolete.
> 
> At that point, my only major gripe would be that hello world takes up 80kb.

GDC supports x86-64, i'm using it on a daily basis.
The large-executable-discussion has popped up repeatedly. If you're interested in the results, you can search the NG.

Jascha Wetzel Wrote:

> Dan wrote:
> > I would probably take up renewed interest in D if it supported the x86-64 - both from D source and inline assembler.  The x86-32 is obsolete.
> > 
> > At that point, my only major gripe would be that hello world takes up 80kb.
> 
> GDC supports x86-64, i'm using it on a daily basis.
> The large-executable-discussion has popped up repeatedly. If you're
> interested in the results, you can search the NG.

Yeah.  It pops up repeatedly, and still they never fix it.  It ultimately boils down to them including everything

-=[ even when it's not used ]=-

What use does printf("hello world"); have for the GC?  Why does it need to have the entirety of phobos instead of just those things that printf() uses?

It's even getting compiled in for extern(C) main() when you're not even using _moduleInit() and such.

That extra 80kb of unremoveable heft is now the only reason sufficient to prevent me from using D.  I can probably write my entire program in < 100kb in assembler (with huge amounts of time and dedication)

Regards,
Dan