naming conflicts in libgcj.a

Bryce McKinlay
Mon Jan 28 16:07:00 GMT 2002

Adam Megacz wrote:

>Tom Tromey <> writes:
>>Bryce's idea is to compile each package into a single large .o file.
>Hrm, is there an advantage to one-package-per-.o instead of
>one-class-per-.o with the naming scheme I mention above

Yes. It would also make compilation much faster and avoid 
command-line-length-limit problems we have on some platforms.

It also makes optimizations easier. Because you don't have to worry so 
much about binary compatibility when the class your refering to is in 
the same complation unit, so you can safely inline its methods etc. We 
could still do the optimizations with a 
-fassume-other-classes-are-in-same-compilation-unit or something, but 
we'd have to parse all the source files every time in order to get the 
inline candidates, at least until the .class parser does functions as 
trees and we can use those for inlining instead.

>I only mention this because putting each package into a .o will cause
>a huge increase in the size of static binaries. I know that's not a
>very high priority for the rest of you, though. The linker does a
>crude amount of unused-section-garbage-collection at the file level
>(if you never reference any symbols in a file, that file is excluded
>from the output). GC at the section level only works on a few
>If I coded up the configure magic to make this a compile-time choice,
>would it be likely to be accepted?

I think the -ffunction-sections GC might be better if we could use that: 
presumably it works on all ELF targets that use binutils, at least? 
Another option might be to continue to build the static libgcj.a the old 

But if the patch wasn't too ugly I would have no objections.



More information about the Java mailing list