Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

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

Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Samuli Suominen-3
# Samuli Suominen <[hidden email]> (05 Jun 2008)
# Masked for removal in ~30 days by treecleaners.
# Replaced by USE libffi in sys-devel/gcc. Bug 163724.
dev-libs/libffi
dev-lang/squeak
x11-libs/gtk-server

Squeak and gtk-server maintainers still have time to rescue their
ebuild, just enough time has passed for handling this (one and half
year)
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Albert Zeyer

On Thu, 2008-06-05 at 14:52 +0300, Samuli Suominen wrote:

> # Samuli Suominen <[hidden email]> (05 Jun 2008)
> # Masked for removal in ~30 days by treecleaners.
> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
> dev-libs/libffi
> dev-lang/squeak
> x11-libs/gtk-server
>
> Squeak and gtk-server maintainers still have time to rescue their
> ebuild, just enough time has passed for handling this (one and half
> year)

Are you sure that Squeak really depends on libffi?

I just compiled it (squeak-3.9.7) fine without having libffi on my
system and with disabled libffi USE-flag.


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

David Leverton-2
On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote:
> Are you sure that Squeak really depends on libffi?
>
> I just compiled it (squeak-3.9.7) fine without having libffi on my
> system and with disabled libffi USE-flag.

According to my reading of the code, it doesn't use libffi on x86-linux,
ppc-linux and ppc-darwin, but does on all other platforms.  In any case, it
should be fine with the libffi in gcc, it's just a case of the maintainer
finding time to update the ebuild.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Samuli Suominen-3
In reply to this post by Albert Zeyer
Thu, 05 Jun 2008 21:21:24 +0300
Albert Zeyer <[hidden email]> kirjoitti:

>
> On Thu, 2008-06-05 at 14:52 +0300, Samuli Suominen wrote:
> > # Samuli Suominen <[hidden email]> (05 Jun 2008)
> > # Masked for removal in ~30 days by treecleaners.
> > # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
> > dev-libs/libffi
> > dev-lang/squeak
> > x11-libs/gtk-server
> >
> > Squeak and gtk-server maintainers still have time to rescue their
> > ebuild, just enough time has passed for handling this (one and half
> > year)
>
> Are you sure that Squeak really depends on libffi?

The ebuild does. Maintainer made it so.

>
> I just compiled it (squeak-3.9.7) fine without having libffi on my
> system and with disabled libffi USE-flag.
>
>

Cool. I hope the new version of squeak with the libffi issue gets
committed before it goes the way of do-do

- Samuli
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Luis Francisco Araujo
In reply to this post by Samuli Suominen-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Samuli Suominen wrote:
| # Samuli Suominen <[hidden email]> (05 Jun 2008)
| # Masked for removal in ~30 days by treecleaners.
| # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
| dev-libs/libffi
| dev-lang/squeak
| x11-libs/gtk-server
|
| Squeak and gtk-server maintainers still have time to rescue their
| ebuild, just enough time has passed for handling this (one and half
| year)

Hello,

I already have an updated version of the Squeak ebuild with the
necessary changes; the problem has been lack of time and of a proper x86
environment to test it.

So, if anyone is interested on testing this ebuild, please, send me an
email, it'd be a matter of just polishing some details and committing then.

In any case, you can keep it masked for now, but I expect to commit this
fix today, I can unmask it afterwards.

Thanks,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhISUgACgkQNir3WYj9aLrjUQCfUcqq/tmHMovjWsDpJOmad+IU
sXsAnA2SD2hncrHJ8ikS/2fs5qN1qI5o
=Xvwh
-----END PGP SIGNATURE-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Albert Zeyer
In reply to this post by David Leverton-2

On Thu, 2008-06-05 at 19:54 +0100, David Leverton wrote:

> On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote:
> > Are you sure that Squeak really depends on libffi?
> >
> > I just compiled it (squeak-3.9.7) fine without having libffi on my
> > system and with disabled libffi USE-flag.
>
> According to my reading of the code, it doesn't use libffi on x86-linux,
> ppc-linux and ppc-darwin, but does on all other platforms.  In any case, it
> should be fine with the libffi in gcc, it's just a case of the maintainer
> finding time to update the ebuild.

Is it possible to add this also to the ebuild, e.g. to only check for
libffi if it is not one of these 3 architectures?

I don't want to spam my system with libs I don't need.


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Donnie Berkholz-2
In reply to this post by Samuli Suominen-3
On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
> # Samuli Suominen <[hidden email]> (05 Jun 2008)
> # Masked for removal in ~30 days by treecleaners.
> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
> dev-libs/libffi
> dev-lang/squeak
> x11-libs/gtk-server

The latest version of g-wrap (1.9.11) requires the external libffi
released a month or two ago, because it looks for the pkgconfig file
installed by that and not gcc:

    - libffi is no longer distributed with g-wrap, as it is available
      as a stand-alone package now (instead of being burried in the
      GCC sources).

Thoughts?

Thanks,
Donnie
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Fabian Groffen-2
On 05-06-2008 22:47:28 -0700, Donnie Berkholz wrote:

> On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
> > # Samuli Suominen <[hidden email]> (05 Jun 2008)
> > # Masked for removal in ~30 days by treecleaners.
> > # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
> > dev-libs/libffi
> > dev-lang/squeak
> > x11-libs/gtk-server
>
> The latest version of g-wrap (1.9.11) requires the external libffi
> released a month or two ago, because it looks for the pkgconfig file
> installed by that and not gcc:
>
>     - libffi is no longer distributed with g-wrap, as it is available
>       as a stand-alone package now (instead of being burried in the
>       GCC sources).
>
> Thoughts?

They might refer to this:
http://sourceware.org/libffi/
which had a "recent" release (3.0.5).  The libffi that's in our tree
right now (3.4.3) is pretty old, matching GCC-3.4.3.  It originally was
used for GNUstep, but that package can also work with GCC's libffi, and
ffcall these days.


--
Fabian Groffen
Gentoo on a different level
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Luis Francisco Araujo
In reply to this post by David Leverton-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Leverton wrote:
| On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote:
|> Are you sure that Squeak really depends on libffi?
|>
|> I just compiled it (squeak-3.9.7) fine without having libffi on my
|> system and with disabled libffi USE-flag.
|
| According to my reading of the code, it doesn't use libffi on x86-linux,
| ppc-linux and ppc-darwin, but does on all other platforms.  In any
case, it
| should be fine with the libffi in gcc, it's just a case of the maintainer
| finding time to update the ebuild.

It used to strictly depend on libffi for some earlier versions of
squeak, so the DEPEND was there long before I added myself as the
maintainer of the package.

It isn't needed right now _unless_ you have squeak packages requiring so
(and we don't have those in the tree), so it is safe to remove such a
dependency and probably add a libffi USE flag conditional for those
willing to use the GCC one.

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhI5VQACgkQNir3WYj9aLro2QCbBm14/mBTjL0UEuSSBZwP1BSm
KJEAn0EA4mzQZutzefHfsGEWIDg6LbKF
=q2lC
-----END PGP SIGNATURE-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Marijn Schouten (hkBst)
In reply to this post by Donnie Berkholz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
| On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
|> # Samuli Suominen <[hidden email]> (05 Jun 2008)
|> # Masked for removal in ~30 days by treecleaners.
|> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
|> dev-libs/libffi
|> dev-lang/squeak
|> x11-libs/gtk-server
|
| The latest version of g-wrap (1.9.11) requires the external libffi
| released a month or two ago, because it looks for the pkgconfig file
| installed by that and not gcc:
|
|     - libffi is no longer distributed with g-wrap, as it is available
|       as a stand-alone package now (instead of being burried in the
|       GCC sources).
|
| Thoughts?

I think we should use this unbundled libffi in favor of the one that will continue to be
bundled with gcc. A normal dep is nicer than a use dep on gcc with libffi for one. I don't
see any reason why this ``new'' libffi should become unmaintained again soon.

Marijn

Relevant bug: http://bugs.gentoo.org/show_bug.cgi?id=163724

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhRU9cACgkQp/VmCx0OL2x56gCfbBE7GiypORQqcyKnjUaGgHc/
0WcAnA31US1030TisMMUN9D2OCJuJZb3
=1xLl
-----END PGP SIGNATURE-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Tiziano Müller-3
In reply to this post by Donnie Berkholz-2
Donnie Berkholz wrote:

> On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
>> # Samuli Suominen <[hidden email]> (05 Jun 2008)
>> # Masked for removal in ~30 days by treecleaners.
>> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
>> dev-libs/libffi
>> dev-lang/squeak
>> x11-libs/gtk-server
>
> The latest version of g-wrap (1.9.11) requires the external libffi
> released a month or two ago, because it looks for the pkgconfig file
> installed by that and not gcc:
>
>     - libffi is no longer distributed with g-wrap, as it is available
>       as a stand-alone package now (instead of being burried in the
>       GCC sources).
>
> Thoughts?

I'd vote for an external libffi as well since python currently has to use
it's bundled version of it (statically linking against it).
Using libffi provided by gcc (and linking dynamically) is no option yet
since portage doesn't protect the user from destroying his system by
re-emerging gcc without gcj or libffi USE flags (rev-dep check and
USE-based deps would be needed).


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Albert Zeyer

On Sat, 2008-06-21 at 09:35 +0200, Tiziano Müller wrote:

> Donnie Berkholz wrote:
>
> > On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
> >> # Samuli Suominen <[hidden email]> (05 Jun 2008)
> >> # Masked for removal in ~30 days by treecleaners.
> >> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
> >> dev-libs/libffi
> >> dev-lang/squeak
> >> x11-libs/gtk-server
> >
> > The latest version of g-wrap (1.9.11) requires the external libffi
> > released a month or two ago, because it looks for the pkgconfig file
> > installed by that and not gcc:
> >
> >     - libffi is no longer distributed with g-wrap, as it is available
> >       as a stand-alone package now (instead of being burried in the
> >       GCC sources).
> >
> > Thoughts?
>
> I'd vote for an external libffi as well since python currently has to use
> it's bundled version of it (statically linking against it).
> Using libffi provided by gcc (and linking dynamically) is no option yet
> since portage doesn't protect the user from destroying his system by
> re-emerging gcc without gcj or libffi USE flags (rev-dep check and
> USE-based deps would be needed).

Isn't it always preferable to separate packages and break them down into
peaces (in this case have an external libffi) instead of having big
packages with lots of stuff (in this case GCC) ?

Perhaps it's more work to maintain, but I as a user would prefer an
external libffi.


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

Petteri Räty-2
Albert Zeyer kirjoitti:

> On Sat, 2008-06-21 at 09:35 +0200, Tiziano Müller wrote:
>> Donnie Berkholz wrote:
>>
>>> On 14:52 Thu 05 Jun     , Samuli Suominen wrote:
>>>> # Samuli Suominen <[hidden email]> (05 Jun 2008)
>>>> # Masked for removal in ~30 days by treecleaners.
>>>> # Replaced by USE libffi in sys-devel/gcc. Bug 163724.
>>>> dev-libs/libffi
>>>> dev-lang/squeak
>>>> x11-libs/gtk-server
>>> The latest version of g-wrap (1.9.11) requires the external libffi
>>> released a month or two ago, because it looks for the pkgconfig file
>>> installed by that and not gcc:
>>>
>>>     - libffi is no longer distributed with g-wrap, as it is available
>>>       as a stand-alone package now (instead of being burried in the
>>>       GCC sources).
>>>
>>> Thoughts?
>> I'd vote for an external libffi as well since python currently has to use
>> it's bundled version of it (statically linking against it).
>> Using libffi provided by gcc (and linking dynamically) is no option yet
>> since portage doesn't protect the user from destroying his system by
>> re-emerging gcc without gcj or libffi USE flags (rev-dep check and
>> USE-based deps would be needed).
>
> Isn't it always preferable to separate packages and break them down into
> peaces (in this case have an external libffi) instead of having big
> packages with lots of stuff (in this case GCC) ?
>
The proper solution is use deps.

Regards,
Petteri


signature.asc (268 bytes) Download Attachment