• Frank Benoit (8/8) May 10 2007 I have this problem with the big exe on windows with -g.
• Walter Bright (2/3) May 10 2007 Did you try squeezing the duplicates out of the linker commmand?
• Frank Benoit (26/30) May 10 2007 yes, i tried a response file. no change in behaviour.
• Walter Bright (7/8) May 10 2007 noi means case sensitive, yes, it's needed.
• Frank Benoit (9/20) May 10 2007 I deleted some file, and have 3.5 GB free. But if the exe grows bigger
• Walter Bright (6/28) May 10 2007 I (personally) find these days that having less than 10Gb free is
• Georg Wrede (15/36) May 10 2007 Am I understanding this correctly?!
• Walter Bright (6/46) May 10 2007 I have no idea how big the debug info is for all the stuff Frank is
• Frank Benoit (130/130) May 10 2007 Once again I captured the -v output from dsss. I broke the lines after
• Walter Bright (5/9) May 10 2007 Try running obj2asm on the obj file, see what happens.
• Frank Benoit (4/6) May 11 2007 I filed a bug report:
• Walter Bright (2/6) May 11 2007 Thanks for helping with this.

Frank Benoit <keinfarbton googlemail.com> writes:

I have this problem with the big exe on windows with -g.

Can anybody help me? I have no experience with D developement on
windows, so I am not even sure, if my tango install is correct.

When i compile any of the SWT examples, i get a binary of about 12 MB.
If i change the dsss.conf to have -g -debug, the linker starts writting
to disk and does not stop until the disk is full. (Well in my case only
1.5 GB).

Can anybody confirm that?

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 I have this problem with the big exe on windows with -g.

Did you try squeezing the duplicates out of the linker commmand?

Frank Benoit <keinfarbton googlemail.com> writes:

Walter Bright schrieb:
 Frank Benoit wrote:
 I have this problem with the big exe on windows with -g.

 
 Did you try squeezing the duplicates out of the linker commmand?

yes, i tried a response file. no change in behaviour.
It looks like this:

dsss_objs\*,
poseidon.exe,,
Scrc32.lib+
SDD-dejavu.lib+
SDD-org-eclipse-swt.lib+
SDD-tango-core.lib+
SDD-tango-io.lib+
SDD-tango-math.lib+
SDD-tango-stdc.lib+
SDD-tango-sys.lib+
SDD-tango-text.lib+
SDD-tango-util.lib+
Stangobos-etc.lib+
Stangobos.lib+
swt-awt-win32-3235.lib+
swt-gdip-win32-3235.lib+
swt-wgl-win32-3235.lib+
swt-win32-3235.lib+
C:\Programme\dsss\lib\+
C:\Programme\dmd\dmd\lib\+
user32+
kernel32/noi/deb;


i was not sure about these "noi/deb". Are they correct?

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 i was not sure about these "noi/deb". Are they correct?

noi means case sensitive, yes, it's needed.
I'd use /co rather than /deb.

Do you have only 1.5Gb of free disk space?

Optlink tries to do everything in memory. It is entirely possible that 
all this stuff simply exceeds memory. You can try excluding debug info 
for some of the modules/libraries.

Frank Benoit <keinfarbton googlemail.com> writes:

Walter Bright schrieb:
 Frank Benoit wrote:
 i was not sure about these "noi/deb". Are they correct?

 
 noi means case sensitive, yes, it's needed.
 I'd use /co rather than /deb.
 
 Do you have only 1.5Gb of free disk space?
 
 Optlink tries to do everything in memory. It is entirely possible that
 all this stuff simply exceeds memory. You can try excluding debug info
 for some of the modules/libraries.


I deleted some file, and have 3.5 GB free. But if the exe grows bigger
then 1 GB, i do a Ctrl-C.
The notebook has 1.5 GB Ram.

I recompiled all libs without -g -debug and my minimumhelloworld builds
fine with -g -debug. 13MB
Same procedure again with the poseidon, about 3.8MB obj files and the
same libs (hm, tangobos was not used in the mini-hw example). Does not
stop linking, growing exe.

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 Walter Bright schrieb:
 Frank Benoit wrote:
 i was not sure about these "noi/deb". Are they correct?

 noi means case sensitive, yes, it's needed.
 I'd use /co rather than /deb.

 Do you have only 1.5Gb of free disk space?

 Optlink tries to do everything in memory. It is entirely possible that
 all this stuff simply exceeds memory. You can try excluding debug info
 for some of the modules/libraries.

 
 
 I deleted some file, and have 3.5 GB free. But if the exe grows bigger
 then 1 GB, i do a Ctrl-C.

I (personally) find these days that having less than 10Gb free is 
unusable. My laptop doesn't have much space on it, but I use a plug-in 
external 160Gb USB drive.

 The notebook has 1.5 GB Ram.
 
 I recompiled all libs without -g -debug and my minimumhelloworld builds
 fine with -g -debug. 13MB
 Same procedure again with the poseidon, about 3.8MB obj files and the
 same libs (hm, tangobos was not used in the mini-hw example). Does not
 stop linking, growing exe.

Using linker switches like /nodebug, you can control the inclusion of 
debug info on a per-file basis.

Georg Wrede <georg nospam.org> writes:

Walter Bright wrote:
 Frank Benoit wrote:
 Walter Bright schrieb:
 Frank Benoit wrote:

 i was not sure about these "noi/deb". Are they correct?

 noi means case sensitive, yes, it's needed.
 I'd use /co rather than /deb.

 Do you have only 1.5Gb of free disk space?

 Optlink tries to do everything in memory. It is entirely possible that
 all this stuff simply exceeds memory. You can try excluding debug info
 for some of the modules/libraries.

 I deleted some file, and have 3.5 GB free. But if the exe grows bigger
 then 1 GB, i do a Ctrl-C.

 
 I (personally) find these days that having less than 10Gb free is 
 unusable. My laptop doesn't have much space on it, but I use a plug-in 
 external 160Gb USB drive.

Am I understanding this correctly?!

If the end product is supposed to be less than 5MB, I have a hard time 
believing that a compile could ever need more than, say, 50MB hd at any 
moment. That's ten times the binary.

You're surely not seriously suggesting that a compile could need for 
example a gig of hard disk?

(My laptops boast a 20GB hard disk each, evenly split between Linux and 
Windows. (FC4, W2k) I live happily in them, and 10GB for Windows and 
10GB for Fedora seems ample. Sure, I don't use downloaded MP3s, HD-DVDs, 
or whatever; these work laptops are for programming, administration of 
other unixes, company red tape, and statistics and databases. Heh,and D 
NG r/w.)

OTOH, of course, some outlandish template stuff might need amazing 
amounts of memory, but we're talking hard disk here.

Walter Bright <newshound1 digitalmars.com> writes:

Georg Wrede wrote:
 Walter Bright wrote:
 Frank Benoit wrote:
 Walter Bright schrieb:
 Frank Benoit wrote:

 i was not sure about these "noi/deb". Are they correct?

 noi means case sensitive, yes, it's needed.
 I'd use /co rather than /deb.

 Do you have only 1.5Gb of free disk space?

 Optlink tries to do everything in memory. It is entirely possible that
 all this stuff simply exceeds memory. You can try excluding debug info
 for some of the modules/libraries.

 I deleted some file, and have 3.5 GB free. But if the exe grows bigger
 then 1 GB, i do a Ctrl-C.

 I (personally) find these days that having less than 10Gb free is 
 unusable. My laptop doesn't have much space on it, but I use a plug-in 
 external 160Gb USB drive.

 
 Am I understanding this correctly?!
 
 If the end product is supposed to be less than 5MB, I have a hard time 
 believing that a compile could ever need more than, say, 50MB hd at any 
 moment. That's ten times the binary.
 
 You're surely not seriously suggesting that a compile could need for 
 example a gig of hard disk?

I have no idea how big the debug info is for all the stuff Frank is 
linking in. But I do think that 1.5Gb of disk free space is, these days, 
unusable.

 (My laptops boast a 20GB hard disk each, evenly split between Linux and 
 Windows. (FC4, W2k) I live happily in them, and 10GB for Windows and 
 10GB for Fedora seems ample. Sure, I don't use downloaded MP3s, HD-DVDs, 
 or whatever; these work laptops are for programming, administration of 
 other unixes, company red tape, and statistics and databases. Heh,and D 
 NG r/w.)
 
 OTOH, of course, some outlandish template stuff might need amazing 
 amounts of memory, but we're talking hard disk here.

Yes, well, you'll use up a gig of hard disk just for memory swap space. 
Your internet browser will chew up a big chunk, too.

Frank Benoit <keinfarbton googlemail.com> writes:

Once again I captured the -v output from dsss. I broke the lines after
every '+' and make a "sort -u" for the libs. And I added the lib
directory from dmd.

1.) The last three lines, are they OK?
2.) the meaning of /nodebug is "starting with this file, all following
have no more debug info". Correct?

with moving the /nodebug in step to more lines down, the application
size slowly increases. Link time always very short.

But with
dsss_objs\poseidon-scintilla/nodebug+
the linker starts to write endless.

Ok, now i have found the problematic obj file :)

What are possibly problems, that can cause that?
How can i proceed with the search?

dsss_objs\poseidon-style-xpm+
dsss_objs\poseidon-poseidon+
dsss_objs\poseidon-loader+
dsss_objs\poseidon-controller-gui+
dsss_objs\poseidon-controller-bottompanel+
dsss_objs\poseidon-controller-editor+
dsss_objs\poseidon-controller-edititem+
dsss_objs\poseidon-controller-dialog-askreloaddlg+
dsss_objs\poseidon-globals+
dsss_objs\poseidon-model-misc+
dsss_objs\ak-xml-coreXML+
dsss_objs\ak-xml-service+
dsss_objs\poseidon-util-fileutil+
dsss_objs\poseidon-utility+
dsss_objs\poseidon-converter+
dsss_objs\poseidon-model-project+
dsss_objs\poseidon-i18n-translation+
dsss_objs\poseidon-util-iniloader+
dsss_objs\poseidon-model-editorsettings+
dsss_objs\poseidon-style-stylekeeper+
dsss_objs\poseidon-controller-scintillaex+
dsss_objs\poseidon-scintilla+
dsss_objs\poseidon-util-xmlutil+
dsss_objs\poseidon-style-stylefactory+
dsss_objs\poseidon-style-dstyle+
dsss_objs\poseidon-style-xmlstyle+
dsss_objs\poseidon-resourcemanager+
dsss_objs\poseidon-controller-dialog-finddlg+
dsss_objs\poseidon-i18n-itranslatable+
dsss_objs\poseidon-util-miscutil+
dsss_objs\poseidon-i18n-i18nshop+
dsss_objs\poseidon-controller-dialog-generaldialog+
dsss_objs\poseidon-util-layoutshop+
dsss_objs\poseidon-controller-dialog-searchdlg+
dsss_objs\poseidon-controller-packageexplorer+
dsss_objs\poseidon-controller-property-prjproperty+
dsss_objs\poseidon-util-waitcursor+
dsss_objs\poseidon-model-navcache+
dsss_objs\poseidon-controller-actionmanager+
dsss_objs\poseidon-controller-menumanager+
dsss_objs\poseidon-model-executer+
dsss_objs\poseidon-controller-dialog-customtool+
dsss_objs\poseidon-controller-property-preference+
dsss_objs\poseidon-controller-property-editorpage+
dsss_objs\poseidon-controller-property-ipropertypage+
dsss_objs\poseidon-controller-property-fontstylegroup+
dsss_objs\poseidon-controller-property-shortcutpage+
dsss_objs\poseidon-controller-property-dpage+
dsss_objs\poseidon-controller-property-generalpage+
dsss_objs\poseidon-controller-property-compilerpage+
dsss_objs\poseidon-controller-property-parserpage+
dsss_objs\poseidon-controller-dialog-aboutbox+
dsss_objs\poseidon-controller-toolbarmanager+
dsss_objs\syntax-core+
dsss_objs\lexical-tokenized_module+
dsss_objs\syntax-node+
dsss_objs\syntax-rule+
dsss_objs\syntax-terminal+
dsss_objs\lexical-token+
dsss_objs\lexical-token_enum+
dsss_objs\utilCA-string+
dsss_objs\syntax-tokenScanner+
dsss_objs\utilCA-scanner+
dsss_objs\utilCA-treeUtil+
dsss_objs\syntax-tree+
dsss_objs\syntax-parsed_module+
dsss_objs\syntax-decldefs+
dsss_objs\syntax-headers+
dsss_objs\syntax-identifiers+
dsss_objs\syntax-declarations+
dsss_objs\syntax-expressions+
dsss_objs\syntax-baseExpressions+
dsss_objs\syntax-statements+
dsss_objs\syntax-aggregates+
dsss_objs\syntax-attributes+
dsss_objs\syntax-conditionalCompilation+
dsss_objs\syntax-initializers+
dsss_objs\syntax-templates+
dsss_objs\syntax-nodeHsu+
dsss_objs\lexical-coreLex+
dsss_objs\lexical-module_file+
dsss_objs\utilCA-textScanner+
dsss_objs\lexical-whitespace+
dsss_objs\lexical-numbers+
dsss_objs\lexical-identifiersLex+
dsss_objs\lexical-token_tables+
dsss_objs\lexical-strings+
dsss_objs\lexical-operators+
dsss_objs\poseidon-controller-outline+
dsss_objs\poseidon-controller-statusbar+
dsss_objs\poseidon-intellisense-autocomplete+
dsss_objs\poseidon-intellisense-search+
dsss_objs\poseidon-controller-dialog-splash,
poseidon.exe,,
user32+
Scrc32.lib+
SDD-dejavu.lib+
SDD-org-eclipse-swt.lib+
SDD-tango-core.lib+
SDD-tango-io.lib+
SDD-tango-math.lib+
SDD-tango-stdc.lib+
SDD-tango-sys.lib+
SDD-tango-text.lib+
SDD-tango-util.lib+
Stangobos-etc.lib+
Stangobos.lib+
swt-awt-win32-3235.lib+
swt-gdip-win32-3235.lib+
swt-wgl-win32-3235.lib+
swt-win32-3235.lib+
C:\Programme\dmd\dmd\lib\+
.\\+
C:\Programme\dsss\lib\\+
.\+
kernel32/co/noi/SUBSYSTEM:console:5;

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 Ok, now i have found the problematic obj file :)
 
 What are possibly problems, that can cause that?

Don't know. Never encountered it before.

 How can i proceed with the search?

Try running obj2asm on the obj file, see what happens.

In any case, just turn off debug info for that obj file. Or, try cutting 
the source file down, and see what construct causes the failure.

Frank Benoit <keinfarbton googlemail.com> writes:

Walter Bright schrieb:
 In any case, just turn off debug info for that obj file. Or, try cutting
 the source file down, and see what construct causes the failure.

I filed a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=1229

It has to do with unnamed enum with many member values.

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 I filed a bug report:
 http://d.puremagic.com/issues/show_bug.cgi?id=1229
 
 It has to do with unnamed enum with many member values.

Thanks for helping with this.