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
