www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Object file generation

reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
Hello,

I've recently tried using minTL and it seems dmd does strange things
depending on if all the *.d files are compiled via:
dmd -c <list of all relevant mintl files>

and then turned into a static library.

Versus running dmd -c on each file individually and then making the
static library from the object files.
Running DMD on each file individually seems to cause the ending library
to be missing symbols.  Where as letting dmd have all the files at once
generates good object files.
The default for minTL's linux makefile is to compile them all
separately, and that's why I ran into this trouble.  So I tried it the other way
and it worked fine.  Seems like DMD should generate the same object files
regardless?

-- 
Email works.
Jan 02 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Some additional thoughts here; (I was Mr Chancellor's sparring partner
during his research on this)

one of the problems encountered was that equal instances of the template in
different object files in some cases collided. It seems to be a problem in
the linker, that it isn't able to find that they are equal inside, or
possibly resolving this differently in different settings.

Another solution (that would admittedly create several instances of the
template in the binary) is to mangle the template instances according to
the modules they are instantiated and not the where they are defined.

Lars Ivar Igesund 

S. Chancellor wrote:

 
 
 Hello,
 
 I've recently tried using minTL and it seems dmd does strange things
 depending on if all the *.d files are compiled via:
 dmd -c <list of all relevant mintl files>
 
 and then turned into a static library.
 
 Versus running dmd -c on each file individually and then making the
 static library from the object files.
 Running DMD on each file individually seems to cause the ending library
 to be missing symbols.  Where as letting dmd have all the files at once
 generates good object files.
 The default for minTL's linux makefile is to compile them all
 separately, and that's why I ran into this trouble.  So I tried it the
 other way
 and it worked fine.  Seems like DMD should generate the same object files
 regardless?
 

Jan 02 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message 
news:dpc2lq$1q2d$1 digitaldaemon.com...
 Running DMD on each file individually seems to cause the ending library
 to be missing symbols.

You can verify what is in the object file by running obj2asm on it. In any case, I need a reproducible example to do anything about it.
Jan 02 2006
parent reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote in message 
news:dpc2lq$1q2d$1 digitaldaemon.com...
 Running DMD on each file individually seems to cause the ending library
 to be missing symbols.

You can verify what is in the object file by running obj2asm on it. In any case, I need a reproducible example to do anything about it.

Sorry, My original post was a bit confused. The problem wasn't exactly what I thought it was. This is the problem here: (Sorry my newsreader doesn't support binaries) http://lws.mine.nu/~lws/fubartemplates.tbz2 Basically untar that, and run make all. You will see the two different make styles and the one that works a breaks. Compare the sizes of templates.o between the two builds (You'll have to build one a time with `make okay`, and `make broken` to compare) The template instances are stored in templates.o, instead of test.o like they should be. Aside from these compilation errors which cause template libraries to be useless, (You have to include all 20 source files for mintl every time you make a source file that use them instead of a library and imports since it probably doesn't have instantiations for your custom classes you might want lists of.) it doesn't seem to make sense to me for templates to be at the project level, rather than the module level. Since variables are the same throughout a template instantiation, two modules might run into problems accessing and setting variables in a template instance they make. If they both have the same instance of a template. -Shammah Chancellor -- Email works.
Jan 02 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
Thanks, but what is a .tbz2 format? Can you do a zip file? 
Jan 03 2006
next sibling parent S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote:
Thanks, but what is a .tbz2 format? Can you do a zip file? 

Here is a zip file of the problem. http://lws.mine.nu/~lws/fubartemplates.zip Thanks for taking a look at it. (PS: tbz2 is a Bzip2'd tarfile. tar -jvxf file.tbz2 will extract it if you're using gnutar) -- Email works.
Jan 03 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Significantly more commonly, .tar.bz2.

-[Unknown]


 Thanks, but what is a .tbz2 format? Can you do a zip file? 

Jan 04 2006
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
I've experienced various difficulties similar to your before, it may or may not
be the same problem. Also, it may be the same as, or related to, this bug:

digitalmars.D.bugs/3998

I hope it is possible to fix this. Keep up the good work, Walter :-)

Nick

In article <dpcl7u$auu$1 digitaldaemon.com>, S. Chancellor says...
Sorry, My original post was a bit confused.  The problem wasn't exactly
what I thought it was.  This is the problem here: (Sorry my newsreader
doesn't support binaries)
http://lws.mine.nu/~lws/fubartemplates.tbz2

Basically untar that, and run make all.  You will see the two different
make styles and the one that works a breaks.  Compare the sizes of
templates.o between the two builds  (You'll have to build one a time with
`make okay`, and `make broken` to compare)  The template instances are
stored in templates.o, instead of test.o like they should be.

Aside from these compilation errors which cause template libraries to be
useless, (You have to include all 20 source files for mintl every time
you make a source file that use them instead of a library and imports
since it probably doesn't have instantiations for your custom classes you
might want lists of.)  it doesn't seem to make sense to me for templates
to be at the project level, rather than the module level.  Since
variables are the same throughout a template instantiation, two modules might
run into problems accessing and setting variables in a template instance
they make.  If they both have the same instance of a template.
-Shammah Chancellor

Jan 04 2006
parent S. Chancellor <S._member pathlink.com> writes:
Sounds like exactly the same bug.  The reason it compiles when writefln is gone
is because the template is empty and is therefor not really used.  Thanks for
responding to my post, I know I'm not alone now :)

-S.

In article <dpgna9$2v2r$1 digitaldaemon.com>, Nick says...
I've experienced various difficulties similar to your before, it may or may not
be the same problem. Also, it may be the same as, or related to, this bug:

digitalmars.D.bugs/3998

I hope it is possible to fix this. Keep up the good work, Walter :-)

Nick

In article <dpcl7u$auu$1 digitaldaemon.com>, S. Chancellor says...
Sorry, My original post was a bit confused.  The problem wasn't exactly
what I thought it was.  This is the problem here: (Sorry my newsreader
doesn't support binaries)
http://lws.mine.nu/~lws/fubartemplates.tbz2

Basically untar that, and run make all.  You will see the two different
make styles and the one that works a breaks.  Compare the sizes of
templates.o between the two builds  (You'll have to build one a time with
`make okay`, and `make broken` to compare)  The template instances are
stored in templates.o, instead of test.o like they should be.

Aside from these compilation errors which cause template libraries to be
useless, (You have to include all 20 source files for mintl every time
you make a source file that use them instead of a library and imports
since it probably doesn't have instantiations for your custom classes you
might want lists of.)  it doesn't seem to make sense to me for templates
to be at the project level, rather than the module level.  Since
variables are the same throughout a template instantiation, two modules might
run into problems accessing and setting variables in a template instance
they make.  If they both have the same instance of a template.
-Shammah Chancellor


Jan 04 2006