Lib change leads to larger executables

jcc7 technocrat7 at gmail.com
Fri Feb 23 05:51:58 PST 2007


== Quote from Frits van Bommel (fvbommel at REMwOVExCAPSs.nl)'s article
> Justin C Calvarese wrote:
> [snip]
> > Oh, I thought the .obj file included mentions of things that are
> > needed, but not contained in a particular .obj. I thought that's
> > why "Error 42: Symbol Undefined" will appear if I don't give the
> > compiler enough source files.
> >
> > If that's not right, that would be a serious flaw in my proposal.
> Oh, you want the compiler to parse the .obj files to generate some
> extra stuff before it tries to link?
> So basically that would be Walters "Put all the TypeInfo
> instantiations into one special module and import it everywhere you
> need TypeInfo", but automated by the compiler when it gets to the
> point of linking an executable?
> I'm not sure if that's workable either since I'm pretty sure it'll
> need to parse the source files to generate the TypeInfo, at the very
> least for user-defined types. At that point it may not even have
> access to those source files, especially when someone is using a
> closed-source library (via .di header files). This is also a problem
> with what I thought you meant, by the way.

Doh! I forgot that the compiler doesn't read the .obj/.lib files, but just hands
them over to the linker.

Yeah, I'm seeing the big problems with my idea now. It's sounding like a lot more
work than we could expect Walter or anyone else to undertake. There might still be
an easy solution (e.g. having the compiler produce a text file that lists the
needed TypeInfo's for each .obj that it outputs), but every solution seems to
bring with it another risk (e.g. too many files floating around that have to be
kept track of).

jcc7



More information about the Digitalmars-d mailing list