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

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--

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

Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com

--- Comment #1 from Jacob Carlborg <doob@me.com> ---
Hmm, I actually fixed this, but only for Objective-C module info. I'll see if I can come up with a fix.

--

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

--- Comment #2 from Jacob Carlborg <doob@me.com> ---
https://github.com/dlang/dmd/pull/6076

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code@dawg.eu
         Resolution|---                         |WONTFIX

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
It goes against the intention of static libraries to drag unused classes and
module into a binary, and that also goes against our permanent fight against
giant binaries.
In fact there is issue 14555 and a PR (https://github.com/dlang/dmd/pull/4638)
in the adverse direction.

If you really want to drag in all classes from a static library, one approach
is to reference all of them from a common module.
Having an explicit list of all classes kind of contradicts the purpose of
Object.factory, but I don't see how we can easily achieve both.

Another approach is to generate object files for each module and explicitly link against all of them (the linker won't discard object files).

Dub supports this as --build-mode=singleFile IIRC.

Yet another approach is to use shared libraries instead.

--

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

--- Comment #4 from Martin Nowak <code@dawg.eu> ---
Another rather obvious solution is to tell the linker to include the whole archive, sensibly named --whole-archive/--no-whole-archive for ld.

Unfortunately dmd currently reorders linker flags (see issue 15574), so the
following doesn't work.

  -L--whole-archive mystaticlib.a -L--no-whole-archive

Instead you'll have to invoke cc for linking yourself atm.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Martin Nowak from comment #3)
> It goes against the intention of static libraries to drag unused classes and module into a binary, and that also goes against our permanent fight against giant binaries.

This is penny-wise and pound-foolish. First we need to solve megabyte sized template symbol names. Then we need full shared library support. The few kilobytes that moduleinfo adds is nothing. Trim out unused classinfo? Then we need to remove Object.factory method.

> In fact there is issue 14555 and a PR (https://github.com/dlang/dmd/pull/4638) in the adverse direction.
> 
> If you really want to drag in all classes from a static library, one approach is to reference all of them from a common module.

I referenced the class info from within the module, and called that function. Why is the linker excluding it? This seems like a real bug.

In fact, I actually TRY your suggestion to solve the original problem and it doesn't work. See the PR: https://github.com/dlang/phobos/pull/4744#issuecomment-241876407

> Having an explicit list of all classes kind of contradicts the purpose of Object.factory, but I don't see how we can easily achieve both.

We can't have Object.factory and then trim out all classinfo that aren't used directly. But in this case, I AM using it directly, and it's STILL being trimmed out.

--

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

--- Comment #6 from Jacob Carlborg <doob@me.com> ---
(In reply to Steven Schveighoffer from comment #5)

> In fact, I actually TRY your suggestion to solve the original problem and it doesn't work. See the PR: https://github.com/dlang/phobos/pull/4744#issuecomment-241876407

No module info is generated if -lib is passed unless coverage, static
constructor , destructor or unittest calls are used. This is regardless if
classes are referenced or not.
https://github.com/jacob-carlborg/dmd/blob/204b4b3b5a2ccbc697fb4e9ae422294ee21867d2/src/glue.c#L457

I think the simplest workaround is to not use -lib but archive the object files manually using "ar".

--

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

--- Comment #7 from Martin Nowak <code@dawg.eu> ---
(In reply to Steven Schveighoffer from comment #5)
> This is penny-wise and pound-foolish. First we need to solve megabyte sized template symbol names. Then we need full shared library support. The few kilobytes that moduleinfo adds is nothing. Trim out unused classinfo? Then we need to remove Object.factory method.

- Yes we need to solve the long symbol names, but they don't bloat the code
segment or affect the performance
- shared libraries were just one workaround I named (and they can be fully used
on linux/FreeBSD atm.)
- It's not the ModuleInfo or the ClassInfo, it's the fact, that this drags in
the complete tree of symbols reachable by any referenced class, i.e. the whole
module in most cases. The static constructors and class references are one of
the main reasons for our huge binaries (code segment, not file size which is
just a distribution problem).
- Object.factory is slow by design, it's in the interest of everyone to avoid
that facility if possible, and there aren't many use-cases that really require
it

If we have enough prove that it's a necessary pattern, I'd be in favor of
adding a global, synchronized, namespaced dynamic class registration facility
in phobos or druntime. That could be used for certain patterns such as
registering deserializable subclasses, factory.register!("orange.deserializer",
MyOpenSubclass).
It could also make use of a hash table to speed up instantiating, and maybe
even support non-standard constructors.
The question is really, do we really need it, and who builds it.

--

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

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Whether we need it or not, it's currently a feature of the runtime. Do we not care about existing code anymore?

I'm totally in favor of deprecating Object.factory, and also in favor of your update to std.encoding that makes this issue moot for phobos at least. But there may be code out there which expects Object.factory to work, and in some cases, it will not.

Note, that in the example I give, including the module info does little to increase the binary size. The ClassInfo is already present in the binary, and therefore pulls in everything else the class may use.

Not only that, but building with the -lib switch does not work, but building without does. This kind of inconsistency is not good for D, regardless of the utility of the Object.factory feature. It makes no sense that the compiler is "stupider" about trimming fat when it has full code access than the linker.

--

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

--- Comment #9 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to Steven Schveighoffer from comment #8)
> But there may be code out there which expects Object.factory to work, and in some cases, it will not.

and there is. some of my UI parsers *depends* on the fact that class list and factory are there. i did that exactly to avoid manual registering of UI classes, which is highly error-prone.

that is, some features are not removed 'cause there *may* be the code that depends on those. now there *is* the code that depends on full module/class infos and factory. this alone should rule "let's remove object.factory" out. let's see if real code has more weight than imaginary code. ;-)

--