[PATCH] Delete GCJ

classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Andrew Hughes


----- Original Message -----

> On 10/09/16 12:59, NightStrike wrote:
> > Could we at least reach out and see if there's someone else who could
> > be the maintainer?  I noticed gcj patches recently, so there's still
> > interest.
>
> 1.  It's too late.  We have been discussing this for a long time, and
> we're now doing what we decided.
>
> 2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
> internals.  There are very few people in the world with that
> knowledge, and I'm fairly sure I know them by name.
>

+1.

> 3.  The Classpath library is very old and is unmaintained.  The only
> practical way to update GCJ would be to use the OpenJDK class
> libraries instead, but updating GCJ to use those class libraries is a
> very substantial job.
>

Classpath is not "unmaintained"; we still fix issues which arise during
bootstrapping IcedTea, for example. Rather, it's an example of the lack
of interesting in updating GCJ that no-one has even merged the most
recent GNU Classpath changes into the GCJ codebase, never mind switching
it to a completely different class library.

If someone is genuinely interested in reviving GCJ, the code will always
be there in the history of the GCC codebase. Keeping around unmaintained
code makes life harder for other GCC developers who work on other parts
of the project.
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Andrew Haley
In reply to this post by Gerald Pfeifer
On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
>
> Note I did not include all the removed java/* contents.  Is there
> anything particular you'd like to retain there?

No, please delete it all.

Thanks,

Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Matthias Klose
In reply to this post by Andrew Haley
On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
>
> Andrew.
>

still breaks bootstraps when configured with --enable-objc-gc.

the immediate step should be to fix the bootstrap failure, as an additional step
to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.

Thanks, Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Rainer Orth-2
Hi Matthias,

> On 05.09.2016 17:13, Andrew Haley wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>
> still breaks bootstraps when configured with --enable-objc-gc.
>
> the immediate step should be to fix the bootstrap failure, as an additional step
> to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.

the first part is handled by my unreviewed patch

        https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Andrew Haley
On 04/10/16 09:39, Rainer Orth wrote:

> Hi Matthias,
>
>> On 05.09.2016 17:13, Andrew Haley wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> still breaks bootstraps when configured with --enable-objc-gc.
>>
>> the immediate step should be to fix the bootstrap failure, as an additional step
>> to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.
>
> the first part is handled by my unreviewed patch
>
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Looks obvious to me, fixes bootstrap.  I think no-one will complain
if you check it in.

Andrew.


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Mike Stump-3
On Oct 4, 2016, at 1:41 AM, Andrew Haley <[hidden email]> wrote:

>
> On 04/10/16 09:39, Rainer Orth wrote:
>> Hi Matthias,
>>
>>> On 05.09.2016 17:13, Andrew Haley wrote:
>>>> As discussed.  I think I should ask a Global reviewer to approve this
>>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>>> if anyone would like to try it.
>>>
>>> still breaks bootstraps when configured with --enable-objc-gc.
>>>
>>> the immediate step should be to fix the bootstrap failure, as an additional step
>>> to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.
>>
>> the first part is handled by my unreviewed patch
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>
> Looks obvious to me, fixes bootstrap.  I think no-one will complain
> if you check it in.

I don't know who wants to review it, but if people want me to, Ok.  The idea is that if ObjC is the last remaining user in tree for boehm-gc, then reasonably I'm the last man standing.  Of course, if others want to review approve the patch, I'm fine with that.  

I'm fine with patches to externalize boehm-gc if people want to push that direction.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Andrew Pinski-2
On Tue, Oct 4, 2016 at 10:23 AM, Mike Stump <[hidden email]> wrote:

> On Oct 4, 2016, at 1:41 AM, Andrew Haley <[hidden email]> wrote:
>>
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>>
>>>> On 05.09.2016 17:13, Andrew Haley wrote:
>>>>> As discussed.  I think I should ask a Global reviewer to approve this
>>>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>>>> if anyone would like to try it.
>>>>
>>>> still breaks bootstraps when configured with --enable-objc-gc.
>>>>
>>>> the immediate step should be to fix the bootstrap failure, as an additional step
>>>> to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.
>>>
>>> the first part is handled by my unreviewed patch
>>>
>>>      https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>>
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
>
> I don't know who wants to review it, but if people want me to, Ok.  The idea is that if ObjC is the last remaining user in tree for boehm-gc, then reasonably I'm the last man standing.  Of course, if others want to review approve the patch, I'm fine with that.

From a runtime maintainer position, I am also fine with this patch.

>
> I'm fine with patches to externalize boehm-gc if people want to push that direction.

I am also ok with that too.

Thanks,
Andrew


>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Iain Sandoe-4
In reply to this post by Mike Stump-3

> On 4 Oct 2016, at 18:23, Mike Stump <[hidden email]> wrote:
>
> On Oct 4, 2016, at 1:41 AM, Andrew Haley <[hidden email]> wrote:
>>
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>>
>>>> On 05.09.2016 17:13, Andrew Haley wrote:
>>>>> As discussed.  I think I should ask a Global reviewer to approve this
>>>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>>>> if anyone would like to try it.
>>>>
>>>> still breaks bootstraps when configured with --enable-objc-gc.
>>>>
>>>> the immediate step should be to fix the bootstrap failure, as an additional step
>>>> to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.
>>>
>>> the first part is handled by my unreviewed patch
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>>
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
>
> I don't know who wants to review it, but if people want me to, Ok.  The idea is that if ObjC is the last remaining user in tree for boehm-gc, then reasonably I'm the last man standing.  Of course, if others want to review approve the patch, I'm fine with that.  
>
> I'm fine with patches to externalize boehm-gc if people want to push that direction.

+1

Iain
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Jeff Law
On 10/04/2016 12:39 PM, Iain Sandoe wrote:
>>
>> I don't know who wants to review it, but if people want me to, Ok.  The idea is that if ObjC is the last remaining user in tree for boehm-gc, then reasonably I'm the last man standing.  Of course, if others want to review approve the patch, I'm fine with that.
>>
>> I'm fine with patches to externalize boehm-gc if people want to push that direction.
>
> +1
Works for me as well, particularly since we've been horrible at updating
boehm-gc.  I think the in-tree version is something like 10 years old at
this point -- and there's been over a dozen upstream releases since we
last sync'd.

Jeff
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Matthias Klose-6
On 06.10.2016 18:14, Matthias Klose wrote:

> On 05.10.2016 18:28, Jeff Law wrote:
>> On 10/04/2016 12:39 PM, Iain Sandoe wrote:
>>>>
>>>> I don't know who wants to review it, but if people want me to, Ok.  The idea
>>>> is that if ObjC is the last remaining user in tree for boehm-gc, then
>>>> reasonably I'm the last man standing.  Of course, if others want to review
>>>> approve the patch, I'm fine with that.
>>>>
>>>> I'm fine with patches to externalize boehm-gc if people want to push that
>>>> direction.
>>>
>>> +1
>> Works for me as well, particularly since we've been horrible at updating
>> boehm-gc.  I think the in-tree version is something like 10 years old at this
>> point -- and there's been over a dozen upstream releases since we last sync'd.
>>
>> Jeff
>
> Here's what I tested. This requires a boehm-gc version 7.0 or later (having the
> header files in a gc subdirectory).  Depending on your available library, it
> only builds the GC enabled library for the default multilib library, and just
> skips over building the non-default multilib variants (assuming that most people
> won't have a libgc for that installed).  The --enable-objc-gc option is not
> documented, so I didn't update the documentation.
>
> Matthias
>
> 2016-10-06  Matthias Klose  <[hidden email]>
>
>         * boehm-gc: Remove
>         * Makefile.def: Remove boehm-gc dependencies.
>         * Makefile.in: Regenerate.
>         * configure.ac: Include pkg.m4, check for bdw-gc pkg-config module.
>         * configure: Regenerate.
>
> config/
>
> 2016-10-06  Matthias Klose  <[hidden email]>
>
>         * pkg.m4: New file.
>
> libobjc/
>
> 2016-10-06  Matthias Klose  <[hidden email]>
>
>         * configure.ac: Include pkg.m4, use bdw-gc pkg-config module.
>         * configure: Regenerate.
and sending the attachment again without the boehm-gc removal ...




no-boehm.diff (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Rainer Orth-2
Hi Matthias,

>> Here's what I tested. This requires a boehm-gc version 7.0 or later
>> (having the
>> header files in a gc subdirectory).  Depending on your available library, it
>> only builds the GC enabled library for the default multilib library, and just
>> skips over building the non-default multilib variants (assuming that most
>> people
>> won't have a libgc for that installed).  The --enable-objc-gc option is not

this assumption may not hold, though: in Solaris 11+ where libgc is
bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
that for multilib testing in general, it's bad to test different
multilibs with different configurations, so I'd rather have people doing
multilib testing obtain all variants of libgc.

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Iain Sandoe-4

> On 6 Oct 2016, at 17:42, Rainer Orth <[hidden email]> wrote:
>

>>> Here's what I tested. This requires a boehm-gc version 7.0 or later
>>> (having the
>>> header files in a gc subdirectory).  Depending on your available library, it
>>> only builds the GC enabled library for the default multilib library, and just
>>> skips over building the non-default multilib variants (assuming that most
>>> people
>>> won't have a libgc for that installed).  The --enable-objc-gc option is not
>
> this assumption may not hold, though: in Solaris 11+ where libgc is
> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
> that for multilib testing in general, it's bad to test different
> multilibs with different configurations, so I'd rather have people doing
> multilib testing obtain all variants of libgc.

likewise on Darwin, people may well build “fat” libraries, and I also would encourage testing of m32/m64,
Iain

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Matthias Klose-6
On 06.10.2016 18:46, Iain Sandoe wrote:

>
>> On 6 Oct 2016, at 17:42, Rainer Orth <[hidden email]> wrote:
>>
>
>>>> Here's what I tested. This requires a boehm-gc version 7.0 or later
>>>> (having the
>>>> header files in a gc subdirectory).  Depending on your available library, it
>>>> only builds the GC enabled library for the default multilib library, and just
>>>> skips over building the non-default multilib variants (assuming that most
>>>> people
>>>> won't have a libgc for that installed).  The --enable-objc-gc option is not
>>
>> this assumption may not hold, though: in Solaris 11+ where libgc is
>> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
>> that for multilib testing in general, it's bad to test different
>> multilibs with different configurations, so I'd rather have people doing
>> multilib testing obtain all variants of libgc.
>
> likewise on Darwin, people may well build “fat” libraries, and I also would encourage testing of m32/m64,

so you both prefer to hard-fail if any of the libgc variants needed for the
multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, and
skip those which are not available with -enable-objc-gc=auto?

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Rainer Orth-2
Hi Matthias,

>>> this assumption may not hold, though: in Solaris 11+ where libgc is
>>> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
>>> that for multilib testing in general, it's bad to test different
>>> multilibs with different configurations, so I'd rather have people doing
>>> multilib testing obtain all variants of libgc.
>>
>> likewise on Darwin, people may well build “fat” libraries, and I also
>> would encourage testing of m32/m64,
>
> so you both prefer to hard-fail if any of the libgc variants needed for the
> multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, and
> skip those which are not available with -enable-objc-gc=auto?

I wouldn't hard-fail, but completely disable objc-gc with an appropriate
warning.  The Objective-C maintainers may have other preferences, though.

        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Iain Sandoe-4

> On 6 Oct 2016, at 17:56, Rainer Orth <[hidden email]> wrote:
>

>>>> this assumption may not hold, though: in Solaris 11+ where libgc is
>>>> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
>>>> that for multilib testing in general, it's bad to test different
>>>> multilibs with different configurations, so I'd rather have people doing
>>>> multilib testing obtain all variants of libgc.
>>>
>>> likewise on Darwin, people may well build “fat” libraries, and I also
>>> would encourage testing of m32/m64,
>>
>> so you both prefer to hard-fail if any of the libgc variants needed for the
>> multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, and
>> skip those which are not available with -enable-objc-gc=auto?
>
> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
> warning.  The Objective-C maintainers may have other preferences, though.

that seems a reasonable strategy to me too (disable that capability when the library is not present) - I suspect that most people do not usually build with GC support anyway (but no firm statistics to back the hunch).

Iain

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Mike Stump-3
In reply to this post by Rainer Orth-2
On Oct 6, 2016, at 9:56 AM, Rainer Orth <[hidden email]> wrote:
> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
> warning.  The Objective-C maintainers may have other preferences, though.

gcc historically is fairly weak at complex configurations.  I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?

I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that.  Of course, that's all external to gcc proper.  Doesn't really make gcc any easier to configure and build or advance gcc.

We could smell the system at configure time, and turn on and off multilib variants and things like objc gc.  Target specific, but I think it helps to ponder this in a target independent way.  This can then turn on and off objc gc support directly.  To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc.  I think I might like that the best.  Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present).


So, I think, if I understand what you propose, I'm fine with that.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Matthias Klose-6
On 06.10.2016 20:00, Mike Stump wrote:
> On Oct 6, 2016, at 9:56 AM, Rainer Orth <[hidden email]> wrote:
>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>> warning.  The Objective-C maintainers may have other preferences, though.

I think I can't do that in the top level make file very well (currently I only
have the pkg-config check there for an early failure, but that check doesn't
tell me if the library is present for all multilib variants). And I can't check
for multilibs because I don't know if the bootstrap compiler is multilib aware.

> gcc historically is fairly weak at complex configurations.  I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?
>
> I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that.  Of course, that's all external to gcc proper.  Doesn't really make gcc any easier to configure and build or advance gcc.
>
> We could smell the system at configure time, and turn on and off multilib variants and things like objc gc.  Target specific, but I think it helps to ponder this in a target independent way.  This can then turn on and off objc gc support directly.  To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc.  I think I might like that the best.  Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present).
>
>
> So, I think, if I understand what you propose, I'm fine with that.

So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with
a hard error message and leave it to the user to correctly configure GCC?  That
would rely on the compiler to find the library in a system wide multilib aware
directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
Solaris and Darwin?

I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
where multilib is the default (but objc-gc is not).

Looking back at libjava, I think everybody disabled multilibs for libjava,
because nobody had a complete gtk2 stack for multilibs, however that was a
complete subdir, not just a certain configuration in that subdir. Looking back
at libffi and separate released libffi's I first built multilib'ed libffi
libraries from the libffi source for Debian/Ubuntu, then dropped these because
they were not used, and until today GCC internal and external libffi are
hopelessly out of sync, so you couldn't use an external libffi to build libjava.

In the past I looked at updating boehm-gc to recent sources but never finished
because libjava relied on internals.  Afaics this is not the case for objc-gc,
so maybe you could update boehm-gc. But I don't want to go this road myself ...

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Iain Sandoe-4

> On 7 Oct 2016, at 00:58, Matthias Klose <[hidden email]> wrote:
>
> On 06.10.2016 20:00, Mike Stump wrote:
>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <[hidden email]> wrote:
>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>>> warning.  The Objective-C maintainers may have other preferences, though.
>
> I think I can't do that in the top level make file very well (currently I only
> have the pkg-config check there for an early failure, but that check doesn't
> tell me if the library is present for all multilib variants). And I can't check
> for multilibs because I don't know if the bootstrap compiler is multilib aware.

hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s the configurer’s responsibility to provide a path with appropriate headers/libs for the multi-lib configuration being attempted.

>
>> gcc historically is fairly weak at complex configurations.  I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?
>>
>> I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that.  Of course, that's all external to gcc proper. Doesn't really make gcc any easier to configure and build or advance gcc.
>>
>> We could smell the system at configure time, and turn on and off multilib variants and things like objc gc. Target specific, but I think it helps to ponder this in a target independent way.  This can then turn on and off objc gc support directly.  To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc.  I think I might like that the best.  Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present).
>>
>>
>> So, I think, if I understand what you propose, I'm fine with that.
>
> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with
> a hard error message and leave it to the user to correctly configure GCC?  That
> would rely on the compiler to find the library in a system wide multilib aware
> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
> Solaris and Darwin?

for Darwin, it’s not a default install (but then neither are the host deps such as gmp & friends) - so the toolchain builder on Darwin already needs to make some provisions outside the system.  It’s just that the only target provisions to date have been the sysroot (we haven’t yet made use of add-on target libs).

> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
> where multilib is the default (but objc-gc is not).
>
> Looking back at libjava, I think everybody disabled multilibs for libjava,
> because nobody had a complete gtk2 stack for multilibs, however that was a
> complete subdir, not just a certain configuration in that subdir. Looking back
> at libffi and separate released libffi's I first built multilib'ed libffi
> libraries from the libffi source for Debian/Ubuntu, then dropped these because
> they were not used, and until today GCC internal and external libffi are
> hopelessly out of sync, so you couldn't use an external libffi to build libjava.

Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally libjava (and libffi, gc) were generally built and tested (by those who cared to do it) as multilibs [the default].
>
> In the past I looked at updating boehm-gc to recent sources but never finished
> because libjava relied on internals.  Afaics this is not the case for objc-gc,
> so maybe you could update boehm-gc. But I don't want to go this road myself …

.. and I don’t have cycles to volunteer to try this at present either.
Iain


>
> Matthias

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Matthias Klose-6
On 07.10.2016 10:30, Iain Sandoe wrote:

>
>> On 7 Oct 2016, at 00:58, Matthias Klose <[hidden email]> wrote:
>>
>> On 06.10.2016 20:00, Mike Stump wrote:
>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <[hidden email]> wrote:
>>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>>>> warning.  The Objective-C maintainers may have other preferences, though.
>>
>> I think I can't do that in the top level make file very well (currently I only
>> have the pkg-config check there for an early failure, but that check doesn't
>> tell me if the library is present for all multilib variants). And I can't check
>> for multilibs because I don't know if the bootstrap compiler is multilib aware.
>
> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s the configurer’s responsibility to provide a path with appropriate headers/libs for the multi-lib configuration being attempted.

I don't understand what you are proposing here.

>>> gcc historically is fairly weak at complex configurations.  I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?
>>>
>>> I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that.  Of course, that's all external to gcc proper. Doesn't really make gcc any easier to configure and build or advance gcc.
>>>
>>> We could smell the system at configure time, and turn on and off multilib variants and things like objc gc. Target specific, but I think it helps to ponder this in a target independent way.  This can then turn on and off objc gc support directly.  To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc.  I think I might like that the best.  Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present).
>>>
>>>
>>> So, I think, if I understand what you propose, I'm fine with that.
>>
>> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with
>> a hard error message and leave it to the user to correctly configure GCC?  That
>> would rely on the compiler to find the library in a system wide multilib aware
>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
>> Solaris and Darwin?
>
> for Darwin, it’s not a default install (but then neither are the host deps such as gmp & friends) - so the toolchain builder on Darwin already needs to make some provisions outside the system.  It’s just that the only target provisions to date have been the sysroot (we haven’t yet made use of add-on target libs).
>
>> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
>> where multilib is the default (but objc-gc is not).
>>
>> Looking back at libjava, I think everybody disabled multilibs for libjava,
>> because nobody had a complete gtk2 stack for multilibs, however that was a
>> complete subdir, not just a certain configuration in that subdir. Looking back
>> at libffi and separate released libffi's I first built multilib'ed libffi
>> libraries from the libffi source for Debian/Ubuntu, then dropped these because
>> they were not used, and until today GCC internal and external libffi are
>> hopelessly out of sync, so you couldn't use an external libffi to build libjava.
>
> Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally libjava (and libffi, gc) were generally built and tested (by those who cared to do it) as multilibs [the default].
>>
>> In the past I looked at updating boehm-gc to recent sources but never finished
>> because libjava relied on internals.  Afaics this is not the case for objc-gc,
>> so maybe you could update boehm-gc. But I don't want to go this road myself …
>
> .. and I don’t have cycles to volunteer to try this at present either.
> Iain
>
>
>>
>> Matthias
>

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Delete GCJ

Iain Sandoe-4

> On 10 Oct 2016, at 05:03, Matthias Klose <[hidden email]> wrote:
>
> On 07.10.2016 10:30, Iain Sandoe wrote:
>>
>>> On 7 Oct 2016, at 00:58, Matthias Klose <[hidden email]> wrote:
>>>
>>> On 06.10.2016 20:00, Mike Stump wrote:
>>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <[hidden email]> wrote:
>>>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>>>>> warning.  The Objective-C maintainers may have other preferences, though.
>>>
>>> I think I can't do that in the top level make file very well (currently I only
>>> have the pkg-config check there for an early failure, but that check doesn't
>>> tell me if the library is present for all multilib variants). And I can't check
>>> for multilibs because I don't know if the bootstrap compiler is multilib aware.
>>
>> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s the configurer’s responsibility to provide a path with appropriate headers/libs for the multi-lib configuration being attempted.
>
> I don't understand what you are proposing here.

given that:
 auto-detection of the capabilities could be quite difficult (or, in the general case, unachievable) for the reasons you gave.
 the chosen target libraries might be in a non-standard place.

making it an explicit requirement to point to them, and to ensure that the versions/multi-libs provided are suitable, (by putting —with-target-boehm-gc=/path/to/suitable/) would mean that the dependent configury (for objc-gc) could be just conditional upon the  presence of the "with-target-boehm-gc”.

I suppose that one could make "—with-target-boehm-gc” (no attached path) declare that the library (and requisite mult-lib versions) will be found in the sysroot without any additional work.

The point here was to simplify the dependent configury so that it only needs to test something that the configuring user specifies (i.e. if they specify objc-gc, then they need also to specify the place that the gc lib can be found).

>>>> gcc historically is fairly weak at complex configurations.  I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?
>>>>
>>>> I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that.  Of course, that's all external to gcc proper. Doesn't really make gcc any easier to configure and build or advance gcc.
>>>>
>>>> We could smell the system at configure time, and turn on and off multilib variants and things like objc gc. Target specific, but I think it helps to ponder this in a target independent way.  This can then turn on and off objc gc support directly.  To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc.  I think I might like that the best.  Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present).
>>>>
>>>>
>>>> So, I think, if I understand what you propose, I'm fine with that.
>>>
>>> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with
>>> a hard error message and leave it to the user to correctly configure GCC?  That
>>> would rely on the compiler to find the library in a system wide multilib aware
>>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
>>> Solaris and Darwin?
>>
>> for Darwin, it’s not a default install (but then neither are the host deps such as gmp & friends) - so the toolchain builder on Darwin already needs to make some provisions outside the system.  It’s just that the only target provisions to date have been the sysroot (we haven’t yet made use of add-on target libs).
>>
>>> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
>>> where multilib is the default (but objc-gc is not).
>>>
>>> Looking back at libjava, I think everybody disabled multilibs for libjava,
>>> because nobody had a complete gtk2 stack for multilibs, however that was a
>>> complete subdir, not just a certain configuration in that subdir. Looking back
>>> at libffi and separate released libffi's I first built multilib'ed libffi
>>> libraries from the libffi source for Debian/Ubuntu, then dropped these because
>>> they were not used, and until today GCC internal and external libffi are
>>> hopelessly out of sync, so you couldn't use an external libffi to build libjava.
>>
>> Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally libjava (and libffi, gc) were generally built and tested (by those who cared to do it) as multilibs [the default].
>>>
>>> In the past I looked at updating boehm-gc to recent sources but never finished
>>> because libjava relied on internals.  Afaics this is not the case for objc-gc,
>>> so maybe you could update boehm-gc. But I don't want to go this road myself …
>>
>> .. and I don’t have cycles to volunteer to try this at present either.
>> Iain
>>
>>
>>>
>>> Matthias
>>
>

1234