Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On Sat, 29 Sep 2012 10:53:29 +0200 Michał Górny mgo...@gentoo.org wrote: Instead of the floating patches and p-d-ng modifications I sent earlier, here are the two complete (so far, well, initial :P) eclasses for review. They are designed as 'mostly' drop-in python-distutils-ng replacement. Conversion of all ebuilds in my overlay: http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=commitdiff;h=c0c8c4ea Conversion of all ebuilds in gx86: https://bitbucket.org/mgorny/gx86-working-tree/changeset/6442b5d5b -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] packages which won't support x32
This is the case with dev-lang/v8: it doesn't build on x32 (https://bugs.gentoo.org/423815), and upstream said they *won't* support x32 (https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ). Note that with v8 it's not just about getting v8 itself to compile, but also making it generate correct JIT code on x32, which would require substantial changes to v8 code (in fact, a whole new 40K arch port, see the discussion linked to above). Should dev-lang/v8 get p.masked on x32 profile, or is there some better way to handle it? What are your suggestions? I had a crazy idea to just build v8 and v8-dependent packages using non-x32 ABI, but I'm not sure if it's possible and if it would be the right thing to do. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] packages which won't support x32
On Fri, Oct 5, 2012 at 7:28 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This is the case with dev-lang/v8: it doesn't build on x32 (https://bugs.gentoo.org/423815), and upstream said they *won't* support x32 (https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ). Note that with v8 it's not just about getting v8 itself to compile, but also making it generate correct JIT code on x32, which would require substantial changes to v8 code (in fact, a whole new 40K arch port, see the discussion linked to above). Is it possible to disable the JIT engine? Should dev-lang/v8 get p.masked on x32 profile, or is there some better way to handle it? What are your suggestions? Qt5 uses a forked version of v8 for QML/QtQuick. So this means that x11-libs/qt-jsbackend:5 (available in qt overlay) and all the packages depending on it, including qt-declarative:5 and kde, won't be available on x32 :-/ I had a crazy idea to just build v8 and v8-dependent packages using non-x32 ABI, but I'm not sure if it's possible and if it would be the right thing to do. Paweł Thanks, Davide
Re: [gentoo-dev] packages which won't support x32
On Fri, Oct 5, 2012 at 2:11 PM, Davide Pesavento p...@gentoo.org wrote: Is it possible to disable the JIT engine? Well, if you're going to wholesale disable functionality, how about client-side rendering? It drives me nuts as it is REALLY SLOW!!! That is, unless the graphics hardware is local to the client (who has that kind of configuration anyway?). Ok, that's my tangent for the day - no need to respond - I'm one of the 3 people who have starred it upstream, and I'll sit quiet and watch it not happen like everybody else. :) Rich
[gentoo-dev] [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
[ eclass/flag-o-matic.eclass ]-8-
--- PORTAGE/eclass/flag-o-matic.eclass
+++ OVERLAY/eclass/flag-o-matic.eclass
@@ -117,6 +117,42 @@
return 0
}
+# @FUNCTION: prepend-ldpath
+# @USAGE: path
+# @DESCRIPTION:
+# Place the specified ldpath into LDFLAGS before any options which could
+# add additional paths to ld's search path. Specifically, it will place
+# the new path /foo into LDFLAGS as -L/foo just before the first
+# occurance matching any of the globs: '-L*', '-T', '--library-path*',
+# and '--script*', but not matching any of the globs: '-Tbss=*',
+# '-Tdata=*', '-Ttext=*', and '-Ttext-segment=*'. If no such match is
+# found, then this is equivalent to append-ldflags -Lpath.
+prepend-ldpath() {
+ local new=()
+ local f
+ local done=no
+ for f in ${LDFLAGS} ; do
+ case ${f} in
+ -Tbss=*|-Tdata=*|-Ttext=*|-Ttext-segment=*)
+ new+=( ${f} )
+ ;;
+ -L*|-T*|--library-path*|--script*)
+ if [[ ${done} == yes ]] ; then
+ new+=( ${f} )
+ else
+ new+=( -L${1} ${f} )
+ done=yes
+ fi
+ ;;
+ *)
+ new+=( ${f} )
+ ;;
+ esac
+ done
+ [[ ${done} == no ]] new+=( -L${1} )
+ export LDFLAGS=${new[*]}
+}
+
# @FUNCTION: filter-lfs-flags
# @DESCRIPTION:
# Remove flags that enable Large File Support.
-8-
I think my code is probably fine, or if it's buggy, so be it. A prior
question is: does this have sufficient utility?
I need (not exactly... keep reading) something like this for python.
Currently python*.ebuild contains:
append-ldflags -L.
which is required in order to pull in the newly-rebuilt
libpython${VERSION}.so at ebuild-time, instead of the system version
(perhaps it's only so on obscure platforms?).
The problem is, LDFLAGS may already have some library paths coming in
from the environment. In this case, we end up with something like:
LDFLAGS=-Wl,--engage-warp-engines -L/random/prefix/usr/lib -L.
and python goes ahead links everything against, i.e.:
/random/prefix/usr/lib/libpython3.2.so,
or whatever is the version in question, so we achieve precisely nothing,
effecting the outcome we are trying to prevent (the problem manifests in
subtle, hard-to-diagnose ways, unfortunately).
In general, when we say append-ldflags -Lsomething, we may or may not
mean always use something/libfoo, not $(libdir)/libfoo to link. In
the case where we do mean always, append-ldflags is a broken approach.
An alternative would be to just replace
append-ldflags -L.
with
export LDFLAGS=-L. ${LDFLAGS}.
however, there are problems with this:
First, it's aesthetically annoying that this spreads out the -L*
arguments into two different zones in LDFLAGS. No big deal, but it
definitely doesn't make visually scanning the logs any easier.
Second, although I'm not aware of any ld arguments which act as
modifiers to -L arguments (except the other -L arguments and
ldscript arguments, which the above patch scans for), ld does use
order-dependent patterns for other arguments.
For example: -lfoo -( -lbar -lbaz -) is not the same thing as -(
-lfoo -lbar -) -lbaz. So order-dependencies might emerge in some
future binutils... in that case we'd still probably need to extend the
case statement above to include the new order-affecting arguments, but
at least we'd have a place in which to do so.
Third, although the meaning of -L* options may not be affected by other
arguments in an order-dependant manner, the reverse is not so. For
example, see --mri-script, --script (which both can affect and be
affected by the command-line library search path in an order-dependent
manner!), -rpath-link (SunOS only), etc...
One could certainly argue that, in practice, points two and three amount
to hopelessly obscure nitpicking and that nobody in their right mind
should be relying on this type of stuff in their LDFLAGS.
I'm not sure I'd state it quite so strongly as that, (after all these
might come just from profile.bashrc and be targeted to a particular
ebuild) but justification is clearly on the thin side.
Indeed, if we're going to worry about side effects, it's not entirely
clear that what what my patch does is safe. For example, if the
environment supplied -L/foo/bar --script baz, and python for some
reason had a baz file in ${S}, then some kind of breakage would
surely happen when we did
prepend-ldpath .
Also, we might also legitimately worry that the presence of this
function in flag-o-matic will somehow encourage people to do this
more, and, I'd have to agree that it's a
Re: [gentoo-dev] packages which won't support x32
On 5 October 2012 22:28, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This is the case with dev-lang/v8: it doesn't build on x32 (https://bugs.gentoo.org/423815), and upstream said they *won't* support x32 (https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ). Note that with v8 it's not just about getting v8 itself to compile, but also making it generate correct JIT code on x32, which would require substantial changes to v8 code (in fact, a whole new 40K arch port, see the discussion linked to above). Should dev-lang/v8 get p.masked on x32 profile, or is there some better way to handle it? What are your suggestions? From what Diego wrote about it, I would say we shouldn't spend much time and effort on x32. I know it's the new and shiny thing, but it doesn't seem very useful. I think arm64/aarch64/armv8 is more promising, if you want to play around with a new arch. I had a crazy idea to just build v8 and v8-dependent packages using non-x32 ABI, but I'm not sure if it's possible and if it would be the right thing to do. If it's easy to do a kind of multilib setup, then it might be worth doing. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-portage-dev] Try to specify how to get that a USE flag is present in current ebuild
El dom, 23-09-2012 a las 09:36 +0200, Pacho Ramos escribió:
El dom, 23-09-2012 a las 05:52 +, Alec Warner escribió:
On Sat, Sep 22, 2012 at 7:22 PM, Pacho Ramos pa...@gentoo.org wrote:
El sáb, 22-09-2012 a las 13:54 -0400, Mike Frysinger escribió:
On Friday 21 September 2012 15:08:20 Pacho Ramos wrote:
In that one, we try to use the following:
has vala ${IUSE//+/} ! use vala return 0
inherit eutils
use_if_iuse vala
-mike
I am aware of that one also, but Ciaran also wants to forbid it for the
same reason :S
Well I assume Ciaran wants to forbid it because he is attempting to
write a PMS compliant PM; but in order to use these ebuilds properly
he has to emulate the unspecified behavior that the ebuilds rely on
upon. His claim is that the council is supposed to forbid this
behavior (presumably to make his job less horrible) but I don't see
them beating down your door to change it (and the behavior is not
new.)
-A
My point of view is that, as this is already supported in portage (and
probably in other PMs as, otherwise, they would have had a lot of
problems with, for example, a lot of packages inheritting important
eclasses like gnome2, cmake-utils or xorg-2) and also used in the tree
for years, the easiest solution is to simply specify current behavior
for existing eapis, needing to wait for a new one to change that
behavior.
As I pointed in http://www.gossamer-threads.com/lists/gentoo/dev/260662
other options would be:
- wait for next eapi to specify that, the problem is that, if that eapi
take a long time to be approved, we would need to move all
eclasses/ebuilds to the other non-automatic way to later revert
them back.
- include this specification in eapi5 as it's still not allowed in the
tree (maybe for this a council meeting should be soon enough I guess)
As looks like this topic got stalled :(, not sure how hard would be to
implement (and document for PMS) the IUSE_FLATTENED idea over current
portage implementation:
http://www.gossamer-threads.com/lists/gentoo/dev/260812#260812
signature.asc
Description: This is a digitally signed message part
