https://issues.dlang.org/show_bug.cgi?id=23974

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |dll
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=23177

--

https://issues.dlang.org/show_bug.cgi?id=23974

Richard Cattermole <alphaglosined@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alphaglosined@gmail.com

--- Comment #1 from Richard Cattermole <alphaglosined@gmail.com> ---
This could be solved by implementing: https://issues.dlang.org/show_bug.cgi?id=23850

By knowing when a module is outside of a binary the reference can be elided.

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
A module is imported (and outside the binary) when it contains exported
declarations:

    export extern int x = 3;

    export int foo();

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Walter Bright from comment #2)
> A module is imported (and outside the binary) when it contains exported
> declarations:
> 
>     export extern int x = 3;
> 
>     export int foo();

Argh, I mean:

    module mydll;

    export extern __gshared int x;

    export int foo();

and then mydll is imported.

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #4 from Richard Cattermole <alphaglosined@gmail.com> ---
(In reply to Walter Bright from comment #2)
> A module is imported (and outside the binary) when it contains exported

This may not be true. Separate compilation is quite common when creating shared libraries. To clarify: outside of binary means outside of dll/exe, rather than outside of object file (just so we are all on the same page).

You can have a dependency that was built as a static library, that was later linked in, that must be accessed via internal symbols and not dllimport.

We do this today with dub.

It also depends upon the use of a .di generator that is functioning correctly (which the avoidance of was a motivating factor for Martin in his work with ldc).

This is why we must parameterize export with a version identifier to be able to tell the compiler if a symbol is dllimport or internal based on what stage it is in the compilation process.

We have got to account for modules being bindings, while also containing D code that needs to be compiled and accessed internally.

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
I don't think that is necessary. I fixed the only outstanding .di gen bug I could find in bugzilla.

Taking a pile of modules, and randomly assigning some to a DLL and others to the EXE will never work with Windows DLLs. It'll always need to be designed to be in a DLL.

For example, templates in a DLL meant to be expanded by the EXE will never work properly. They are not like Linux shared libraries.

--

https://issues.dlang.org/show_bug.cgi?id=23974

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #6 from Rainer Schuetze <r.sagitario@gmx.de> ---
I don't think this issue is a real problem:

- it's not easy to create DLLs with cyclic import dependencies, and even if you manage to do it, the system won't load them AFAICT.

- so DLLs already have a "higher level" ordering that respects the required module initializer order

- static initializers already contain a check to avoid multiple executions, so it is no problem that it might get called across DLL boundaries, it just does nothing.

The actual difficulty is that the dependency between modules is part of the ModuleInfo and needs a data relocation through the import table. This is not supported by the OS. https://github.com/dlang/dmd/pull/14849 solves this similar to LDC by running some initializers before most of the C runtime is started. This is needed for other data entries as well (e.g. TypeInfo), so it does not help a lot to avoid it for ModuleInfo.

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #7 from Richard Cattermole <alphaglosined@gmail.com> ---
(In reply to Rainer Schuetze from comment #6)
> This is needed for other data entries as well (e.g. TypeInfo), so it does not help a lot to avoid it for ModuleInfo.

It does help to get binaries sizes down (even if it would be a tiny amount), so the fundamental idea isn't a bad one.

I think it's a worthy change, but only if the user tells the compiler that a module is out of binary. If it's derived, there is a good chance it will get the wrong idea when it comes to mixed builds (which are very common) and could lead to some very unhappy people.

All the stuff like ModuleInfo, TypeInfo ext. (but not RTInfo) is currently
dependent on Rainer's PR.

--

https://issues.dlang.org/show_bug.cgi?id=23974

--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Rainer Schuetze from comment #6)
> so it does not help a lot to avoid it for ModuleInfo.

It's an easy enough change, and it should be solid. I know this doesn't solve the TypeInfo problem, but one by one we knock the problems down.

--

https://issues.dlang.org/show_bug.cgi?id=23974

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #9 from Dlang Bot <dlang-bot@dlang.rocks> ---
@WalterBright created dlang/dmd pull request #15298 "fix Issue 23974 - A ModuleInfo in a separate Windows DLL should not b…" fixing this issue:

- fix Issue 23974 - A ModuleInfo in a separate Windows DLL should not be referred to by MIimportedModules

https://github.com/dlang/dmd/pull/15298

--