kris wrote:
> Walter Bright wrote:
> 
>> 3) create a separate module that defines the relevant typeinfo's, and put that first in the library
> 
> Just to satify your stance I tried this; guess what? It has no effect whatsoever, since you /cannot/ dictate the order in which the decls will be inspected in advance.

Then there's something else going on, i.e. another symbol is being referenced that is resolved by core.obj.

kris wrote:
> Walter Bright wrote:
> 
>> 3) create a separate module that defines the relevant typeinfo's, and put that first in the library
> 
> Just to satify your stance I tried this; guess what? It has no effect whatsoever, since you /cannot/ dictate the order in which the decls will be inspected in advance.

Did you verify (using obj2asm) that the separate module actually did define the typeinfo's?

Sean Kelly wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> John Reimer wrote:
>>>> optlink may just be the bane for D acceptance. And Tango gets the pitiful
>>>> opportunity of demonstrating why D is NOT ready for prime-time in the
>>>> commercial realm: the DM support tools it relies on are bogged down in
>>>> the past, reflecting D's lopsided existance on yet another level: a strong
>>>> language relying on a fragile, outdated, and poorly fit tool set.
>>>
>>> Linux's ld exhibits the same behavior. Try compiling the 3 files here according to the instructions below, and try different orderings adding the object files to the librarian (ar). The same behavior as lib/optlink results (using nm to see what symbols are placed into the resulting executable).
>>
>> In your example, no symbols at all from a is referenced in b or in test, and yet it's linked anyway in the first case?
> 
> Forget I said that.  It's the TypeInfo for char[][].

That's right, it picked the FIRST ONE in library, regardless of how many other .o's defined it, and regardless of what else was in that .o, referenced or not.

Walter Bright wrote:
> Sean Kelly wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> John Reimer wrote:
>>>>> optlink may just be the bane for D acceptance. And Tango gets the pitiful
>>>>> opportunity of demonstrating why D is NOT ready for prime-time in the
>>>>> commercial realm: the DM support tools it relies on are bogged down in
>>>>> the past, reflecting D's lopsided existance on yet another level: a strong
>>>>> language relying on a fragile, outdated, and poorly fit tool set.
>>>>
>>>> Linux's ld exhibits the same behavior. Try compiling the 3 files here according to the instructions below, and try different orderings adding the object files to the librarian (ar). The same behavior as lib/optlink results (using nm to see what symbols are placed into the resulting executable).
>>>
>>> In your example, no symbols at all from a is referenced in b or in test, and yet it's linked anyway in the first case?
>>
>> Forget I said that.  It's the TypeInfo for char[][].
> 
> That's right, it picked the FIRST ONE in library, regardless of how many other .o's defined it, and regardless of what else was in that .o, referenced or not.

That makes complete sense.  It's irritating that such matches pull in the entire object, but at least the process is straightforward and logical.

Walter Bright wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> I see hangs occasionally even for small programs.  Even on single files compiled with dmd -run.  Every time it happens if I Ctrl-C kill it and run the same command again, everything is fine.  Frequency is maybe like 1 out of every 50 compiles.
>>
>> I've never seen optlink crash except on known cases where there's a gigantic amount of static data. If you've got more conventional cases, please post a bug report with a reproducible case.
> 
> I'd forgotten, there is a problem with optlink running on multicore machines. There's supposed to be a way to tell Windows to run an exe using only one core, but I can't think of it at the moment.

Is it a threaded application? (That would explain why the error is sporadic)
If so, the obvious workaround would be to tell it to only use one thread.
If not, why does multicore matter?

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>>
>>> Note that there can be only a 1:1 correspondence between publicnames and objectmodules. If a publicname is already in the dictionary, lib issues an error and quits.
>>
>> So how are TypeInfo definitions resolved?  I'd think it would be pretty common to have more than one of the same TypeInfo publicname per library.
> 
> if (name in library.dictionary)
>     readin(library.dictionary[name])
> 
> As I said, only the FIRST ONE of the comdat names makes it into dictionary[], subsequent ones are not.

Oh, so TypeInfo are stored in COMDATs.  Makes perfect sense.  Thanks!

Sean Kelly wrote:
> That makes complete sense.  It's irritating that such matches pull in the entire object, but at least the process is straightforward and logical.

Of course, if matches didn't pull in the entire object then static constructors/destructors, unittests and exceptions wouldn't work without some way to flag specific sections as "always pull this in if anything (or even better: if _certain things_) are pulled in" or "when this is pulled in, also pull in X and Y even though they're not referenced" or something similar...

Frits van Bommel wrote:
> Sean Kelly wrote:
>> That makes complete sense.  It's irritating that such matches pull in the entire object, but at least the process is straightforward and logical.
> 
> Of course, if matches didn't pull in the entire object then static constructors/destructors, unittests and exceptions wouldn't work without some way to flag specific sections as "always pull this in if anything (or even better: if _certain things_) are pulled in" or "when this is pulled in, also pull in X and Y even though they're not referenced" or something similar...

Hm... so how does segment-level linking work at all?

Frits van Bommel wrote:
> Walter Bright wrote:
>> Walter Bright wrote:
>>> Bill Baxter wrote:
>>>> I see hangs occasionally even for small programs.  Even on single files compiled with dmd -run.  Every time it happens if I Ctrl-C kill it and run the same command again, everything is fine.  Frequency is maybe like 1 out of every 50 compiles.
>> I'd forgotten, there is a problem with optlink running on multicore machines. There's supposed to be a way to tell Windows to run an exe using only one core, but I can't think of it at the moment.
> 
> Is it a threaded application?

Yes.

>(That would explain why the error is sporadic)

Yes.

> If so, the obvious workaround would be to tell it to only use one thread.
> If not, why does multicore matter?

The way mutexes are done for multi core is different than for single core. I think optlink multithreads correctly only for single core machines.

jcc7 wrote:
> == Quote from Daniel Keep (daniel.keep.lists@gmail.com)'s article
>> ...
>>
>> So, why not make a small modification to OPTLINK such that if a switch is thrown, and it encounters any missing symbol of the form /_D11TypeInfo_.*/, then it will link only the segment that symbol is in.  In other words, it does what it currently does in all cases except where there's a TypeInfo involved; in which case it links *just* the TypeInfo, not the whole object file.
>>
>> ...
> 
> I don't know enough about how linkers work to know if OPTLINK can just include a TypeInfo segment like that, but it sounds like a good idea to me. I think it's more feasible than my idea was (since Frits helped me see some serious challenges with my idea).
> 
> And if it works, it should directly address Kris's problem.
> 
> jcc7

I had a peek at the TypeInfos that are hard-coded into Phobos.  They do import other stuff, but that "other stuff" is all in Phobos.  Since (ignoring Tango for the moment) all D programs include at least one non-TypeInfo symbol (the *real* main(), if I'm not mistaken), then Phobos will always be linked in.

I think it's also safe to assume that since all other TypeInfos are generated by the compiler, it's not going to start inserting imports to modules all over the shop; at worst, it will import some other modules from Phobos.

So, assuming all my assumptions hold (starts plastering his argument with duct tape), then it should be feasible.

Of course, when it comes down to it, Walter's the expert.  What say ye?

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/