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.

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?
> 

"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.

"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.

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

"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.

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:

http://www.digitalmars.com/drn-bin/wwwnews?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

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:
>
>http://www.digitalmars.com/drn-bin/wwwnews?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
>
>

Significantly more commonly, .tar.bz2.

-[Unknown]


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