DIP 45 - approval discussion

[Benjamin Thaut]

Am 08.11.2013 20:32, schrieb Walter Bright:
 > It looks pretty good, except I have serious reservations about the 
-lib switch proposed behavior:
I'm glad you like the proposal.

 >
 > 1. It's too blunt. A user could conceivably want to export some 
symbols and not others. This is all or nothing.
A user is already able to control which symbols are exported and which 
are not by using the "export" attribute. Talking about expectations, 
when you come from C/C++ you usually expect that static libraries do 
_not_ contain any dll-exported symbols. At least I have never seen a 
single C or C++ static library that does contain dll-exported symbols. 
The -lib switch just deactivates dll-exporting symbols. I would also be 
fine with adding a additional compiler switch "--disable-export" or 
something like that. But I would strongly prefer a solution where I 
don't have to run additional tools on the generted object files to get 
rid of dll-exported symbols I didn't want in the first place, because I 
was compiling my code for a static library.

 >
 > 2. It requires the compiler to rewrite the .obj files, even ones that 
dmd did not create. I would consider this very surprising behavior. The 
user will be "WTF the object files in the lib are different from on my 
disk! D sux!" -lib is a simple-minded creature that currently does 
exactly what one would expect it to.
I can agree with that. The consensus in the newsgroup dicussion was 
though, that this is better then adding another compiler switch for 
disabeling dll-exported symbols, because that compiler switch would need 
to be added manually, whereas the -lib solution would work "magically". 
So the -lib solution whas thought to have better usability.

 >
 > 3. I've never heard anyone complain about the issue of a DLL 
referencing another DLL and the combined list of exports being the 
concatenation of both. It can be annoying, but it would be a minor 
issue. If it really is one, we can write a separate simple tool that 
strips exports from object files.

I don't think you understood the issue correctly. The issue is that you 
don't want to have dll-exported symbols from a static library inside a 
DLL. Static libraries are usually expected to not have any dll-exported 
smybols at all. For example when creating a DLL and you link against 
phobos you will always have all symbols from phobos & druntime inside 
your DLL, if we follow your suggested behaviour. This not only will lead 
to linker errors if you use two dlls that both link against phobos 
statically. But it will also make debugging and inspecting dll-exports 
harder as the dll will always have tons of exports you have to filter out.

 >
 > And:
 >
 > Exporting of TLS variables is a minor issue. Frankly, I think people 
who export global variables should be burned at the stake anyway, why 
should we make it even easier? Anyhow, if the user really, really wants 
to get himself immolated and export a TLS variable, he can always 
manually write the thunk (it is, after all, trivial).
I don't agree with that. It should be possible to create shared 
libraries which use all the capbailites of the language. And not 
restirct them to a arbitrary subset. In D TLS is a special issue because 
so many variables end up in TLS automatically. I'm especially thinking 
about inlining of small methods across dll boundaries. Also a shared 
library should really work the same way as a static one. Requiering a 
different design for a static versus a shared library seems inconsistent 
to me.
 >
 > (Perhaps we could take this one step further - export doesn't apply 
to global variables, either, unless they are extern(C)?)
 >
 > I do like the idea that this proposal enables better code performance 
on Linux - better than C!
 >
I fully agree here, although this basically happened by accident. I was 
really astonished when I learned how much mostly useless indirections 
are added when compiling with -fPIC. Windows Dlls seem to have the 
better solution here regarding performance.

We should really continue this discussion on the newsgroup. If this is 
ok with you, just copy the e-mail conversation to a new newsgroup 
thread, or send me a message and I will do so.

Kind Regards
Benjamin Thaut