David Daney wrote:
> Tom Tromey wrote:
>>> "Dave" == Dave Korn writes:
>>
>> Dave> There are a couple of regressions to solve first, but it appears
>> Dave> that I've more-or-less cracked it. Full details are written up
>> Dave> here:
>>
>> Dave> http://gcc.gnu.org/wiki/Internal_depen
Tom Tromey wrote:
"Dave" == Dave Korn writes:
Dave> There are a couple of regressions to solve first, but it appears
Dave> that I've more-or-less cracked it. Full details are written up
Dave> here:
Dave> http://gcc.gnu.org/wiki/Internal_dependencies_of_libgcj
One thing worth conside
> "Dave" == Dave Korn writes:
Dave> There are a couple of regressions to solve first, but it appears
Dave> that I've more-or-less cracked it. Full details are written up
Dave> here:
Dave> http://gcc.gnu.org/wiki/Internal_dependencies_of_libgcj
One thing worth considering is that yo
Andrew Haley wrote:
> One thing that you may like to consider is compiling
> more packages with -findirect-dispatch -fno-indirect-classes. This has a
> smallish performance penalty, but packages compiled this way have no link-
> time dependencies on other packages. Instead, everything gets fixed
Dave Korn wrote:
> Not simple, but not so hard as to be impossible either; as it turns out, the
> internal structure of libgcj looks a lot like a turnip, with a bunch of skinny
> branchy foliage waving around on top, a few shallow roots spreading under the
> ground, and a big ball of hair in the
[ Reviving a thread from 20090506, as the first step toward raising this issue
again on the lists, and just in case anyone was interested in the follow-on ...
]
David Daney wrote:
> Ralf Wildenhues wrote:
>> Hello Dave,
>>
>> * Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
> [...]
>>>
Andrew Haley wrote:
> Dave Korn wrote:
>> Andrew Haley wrote:
>>
>>> Did you try my list of things to lift out? I don't think there will be any
>>> interdependencies; the only problem might be that the reduction is not
>>> enough.
>> Hi Andrew,
>>
>> I've had a quick hack at it now, and it'
Dave Korn wrote:
> Andrew Haley wrote:
>
>> Did you try my list of things to lift out? I don't think there will be any
>> interdependencies; the only problem might be that the reduction is not
>> enough.
>
> Hi Andrew,
>
> I've had a quick hack at it now, and it's not doing what I'd hope
Dave Korn wrote:
> So we have to
> use dlltool first to generate import libs ahead of final-link time (without
> attmepting to build a complete DLL):
>
> dlltool a1.o a2.o a3.o -D cygexample-a.dll -e libexample-a.dll.a
> dlltool b1.o b2.o b3.o -D cygexample-b.dll -e libexample-b.dll.a
> dlltool c1
Andrew Haley wrote:
> Did you try my list of things to lift out? I don't think there will be any
> interdependencies; the only problem might be that the reduction is not enough.
Hi Andrew,
I've had a quick hack at it now, and it's not doing what I'd hoped, so
possibly I've misunderstood w
Andrew Haley wrote:
> Did you try my list of things to lift out? I don't think there will be any
> interdependencies; the only problem might be that the reduction is not enough.
As my other post probably implied, I've just come back to this after a while
pursuing other things, so I haven't tr
Dave Korn wrote:
> Andrew Haley wrote:
>
>> Here's a starter list of non-core packages:
>>
>> gnu/CORBA
>
> By the time I got done annotating all those packages with "non-core" in
> makemake.tcl, it looked like the rule is "all packages of style 'bc' or
> 'bcheader'", is that correct? I'd rath
Andrew Haley wrote:
> Here's a starter list of non-core packages:
>
> gnu/CORBA
By the time I got done annotating all those packages with "non-core" in
makemake.tcl, it looked like the rule is "all packages of style 'bc' or
'bcheader'", is that correct? I'd rather infer the list of non-core p
Dave Korn wrote:
> Ralf Wildenhues wrote:
>> * Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
>>> Ralf Wildenhues wrote:
I don't yet see why you would need any kind of libtool hacking.
>>> Because of this:
>>>
You also have to ensure that the sub libraries are self-contained,
Ralf Wildenhues wrote:
> * Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
>> Ralf Wildenhues wrote:
>>> I don't yet see why you would need any kind of libtool hacking.
>> Because of this:
>>
>>> You also have to ensure that the sub libraries are self-contained, or at
>>> least their int
* Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
> Ralf Wildenhues wrote:
> > I don't yet see why you would need any kind of libtool hacking.
>
> Because of this:
>
> > You also have to ensure that the sub libraries are self-contained, or at
> > least their interdependencies form a di
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>
>>> 1) Would this be a reasonable approach, specifically i) in adding a
>>> configure
>>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>>> construct to crudely subdivide the libraries like this?
>> At pr
Bryce McKinlay wrote:
> If you're going to go to all this trouble, why not consider making libgcj
> compilable with the BC-ABI.
Well, in my case, because I have no idea what that involves or implies. I
was hoping to find a solution that I can get in during this current stage1 and
it not be th
Ralf Wildenhues wrote:
> Hello Dave,
Hiya Ralf,
> I don't yet see why you would need any kind of libtool hacking.
Because of this:
> You also have to ensure that the sub libraries are self-contained, or at
> least their interdependencies form a directed non-cyclic graph (or you
> will need
Andrew Haley wrote:
> Dave Korn wrote:
>
>> 1) Would this be a reasonable approach, specifically i) in adding a
>> configure
>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>> construct to crudely subdivide the libraries like this?
>
> At program startup the firs
Richard Guenther wrote:
> Is it not that maybe most of the exported symbols are not necessary and can
> be made hidden?
We already did that. This is the number of symbols in the public API.
Andrew.
Dave Korn wrote:
> 1) Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?
At program startup the first library would be loaded, it would
On Wed, May 6, 2009 at 6:26 PM, David Daney wrote:
> Ralf Wildenhues wrote:
>>
>> Hello Dave,
>>
>> * Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
>
> [...]
>>>
>>> 1) Would this be a reasonable approach, specifically i) in adding a
>>> configure
>>> option to cause sublibraries to be
Ralf Wildenhues wrote:
Hello Dave,
* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
[...]
1) Would this be a reasonable approach, specifically i) in adding a configure
option to cause sublibraries to be built, and ii) in using gmake's $(filter)
construct to crudely subdivide the lib
Hello Dave,
* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
>
> So I'm currently experimenting with a patch that adds a new option
> "--enable-libgcj-sublibs" in libjava/configure.ac. I may need to add a
> dummy-link-and-relink stage to get the interdependencies working right, or I
[ Boh! I allowed my emailer to autocomplete the address and misdirected this
to the -patches list. Apologies for the reposting to gcc@, but it'll break
the threading if I just send a forward to j...@. ]
Hi,
As I'm sure everyone concerned is aware, libgcj is currently a bit of a
monolith.
Hi,
As I'm sure everyone concerned is aware, libgcj is currently a bit of a
monolith. Wighing in at 93M for a static archive, 73M for a shared library
(win32), it exports 82720 symbols. Which is unfortunately 17184 more than the
system limit (64k) for a Windows DLL.
The idea of breakin
27 matches
Mail list logo
