Error when building dev-lang/python-2.7.2-r3

Hey,
I'm trying to build Gentoo-alt on a Mac OS X 10.7.4 machine with gcc 
4.2.1 installed. During compilation of python, I'm getting the build 
error below. Any
hints?

Thanks,
Lars.

/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGDataProvider.h:8: 
error: declaration for parameter 'CGDataProviderRef' but no such

parameter
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGColorSpace.h:8: 
error: declaration for parameter 'CGColorSpaceRef' but no such
parameter
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGColor.h:8: 
error: declaration for parameter 'CGColorRef' but no such
parameter
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGContext.h:8: 
error: declaration for parameter 'CGContextRef' but no such
parameter
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGAffineTransform.h:109: 
error: declaration for parameter 'CGRectApplyAffineTransform' but no 
such
parameter
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGAffineTransform.h:99: 
error: declaration for parameter 'CGSizeApplyAffineTransform' but no 
such
parameter

Error while building gcc-4.5.3-r1 on x86_64-pc-solaris2.10.

How can I resolve the below error when building gcc-4.5.3-r1 on
x86_64-pc-solaris2.10?

Thanks,

Drew

/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/xgcc
-B/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/
-B/develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/bin/
-B/develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/lib/
-isystem /develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/include
-isystem /develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/sys-include
   -g -march=native -O2 -pipe -O2 -O2  -g -march=native -O2 -pipe -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC
-g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED    -I.
-I. -I../.././gcc
-I/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc
-I/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/.
-I/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc
-I/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../include
 -DHAVE_CC_TLS  -o gthr-gnat_s.o -MT gthr-gnat_s.o -MD -MP -MF
gthr-gnat_s.dep -DSHARED -fexceptions -c
/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/gthr-gnat.c
/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/xgcc
-B/develop/richanh/x86_64-pc-solaris2.10/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/
-B/develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/bin/
-B/develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/lib/
-isystem /develop/richanh/x86_64-pc-solaris2.10/usr/x86_64-pc-solaris2.10/include

OpenRC on Prefix for service daemons

media-gfx/xfig

Dear all;

I'm not sure what's causing this, given the changes in how the prefix portage tree and the main ditto are
synchronised.  In the main tree I've got media-gfx/xfig-3.2.5b-r2, whereas in the prefix the latest
version is 3.2.5b.  This is important because the latter doesn't have the necessary patches to build with
libpng-1.5.  Enlightenment, anyone?

// Best wishes; Johan

patch for autotools-utils.eclass

Hi all,

Patch for FreeMiNT autotools-utils.eclass.

Should I submit to bugzilla ?

Alan.

--- autotools-utils.eclass	2012-02-04 09:31:14.000000000 +0000
+++ /tmp/0	2012-04-11 20:45:06.439709678 +0100
@@ -411,8 +411,17 @@

 	# Handle static-libs found in IUSE, disable them by default
 	if in_iuse static-libs; then
+		if tc-is-static-only; then
+			econfargs+=(
+				--disable-shared
+			)
+		else
+			econfargs+=(
+				--enable-shared
+			)
+        fi
+
 		econfargs+=(
-			--enable-shared
 			$(use_enable static-libs static)
 		)
 	fi

take arm-linux

Dear all,

I am going to maintain arm-linux. Just made an update to 

  http://www.gentoo.org/proj/en/gentoo-alt/prefix

One thing I want to try is just to use arm to represent arm-linux.

GLEP22 defines that ${arch} defaults ${arch}-linux. We are treating x86
and x86-linux differently just for maintaining a separate prefix
tree. Now that gx86 are merged into prefix, and soon they will be one,
it is reasonable to expect arch-linux and arch finally to be merged,
too.

arm and arm-linux would be a first trial. Let's hope it can prove the
concept.

Yours,
Benda
--

-- 
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

eprefixify_patch

Current prefix SOP is to epatch a bunch of files with @GENTOO_PORTAGE_EPREFIX@ and then eprefixify the
affected files.  Although this adds a bit of precision and flexibility, it leads to laundry lists in the
ebuild, especially if/when we start getting more rigorous about prefixification.  The attached eclass
provides eprefixify_patch, which simply prefixifies the patch itself before applying.

It also includes some quick & dirty tools to prefixify /bin/{ba,}sh shebangs.  I'm using both in my overlay. 
So far, so good.  What I'm using it /for/ is a more interesting question that I'd like to bring up in a
separate, presumably more controversial thread.  Anyhow, for the moment I thought these might come in
handy or at least precipitate an interesting flamewar :)

-gmt

[PREFIX] Prefix rsync now includes full gentoo-x86 repo

All,

This is a headsup mostly for developers.  The (good) news for users is
that all packages from regular Gentoo are now also available for Prefix
albeit being masked by missing keywords.

Because of a growing whitelist.txt, and the tiresome process of adding
to whitelist.txt what is necessary, then waiting around an hour to sync
and find the next missing package, I decided to include all packages
from gx86 in the Prefix rsync tree.

Of course "each advantage has its disadvantage", to quote Cruyff.  In
the attached figure, the most prominent disadvantage is made visual:
generation time has increased from ~12 to ~17 minutes.  For the 30
minutes rotation this obviously makes no difference.

Notice the bump of time necessary by egencache around 20:00, that is the
time Zac committed "cache-formats = md5-dict pms" to
metadata/layout.conf.  In the Prefix tree, there now is a
metadata/md5-cache directory that should ultimately fix the bug we
observed in the past [1], but gentoo-x86 people have been affected by
now too [2].  That sort of is a  proof that I was correctly not
convinced in comment #17 of said Prefix bug [1].

In the near future, we (Prefix) might jump ahead and stop distributing
the old metadata/cache, but for now we have both, like gx86.

Because the Prefix overlay now "overshadows" the gx86 tree, I've removed
whitelist.txt, since it's obviously no longer used.  Nothing is
necessary any more to "include" something in Prefix, as everything there
is, should be there now.

[1] https://bugs.gentoo.org/show_bug.cgi?id=388345
[2] https://bugs.gentoo.org/show_bug.cgi?id=409445

--

-- 
Fabian Groffen
Gentoo on a different level

sys-apps/net-tools-1.60_p20120127084908 build fail on prefix

WIP: resuscitating the nascent cygwin prefix portage effort

I have about 20,000 questions and non-implemented bug-reports regarding this, but I don't want to flood
the list or write a novel, so let's start with a kind of announcement/heads-up:

at

  git://github.com/gmt/gmt-cygwin-overlay.git

I have a WIP cygwin-gentoo-prefix overlay.  It's very, very rough; indeed, I still am using out-of-tree
scripts to handle the more gruesome rebase issues.  However, I do have some ameliorants for rebase
problems in the overlay and several ideas for how to fundamentally fix the problem going forward.

Where I am now is just after emerge --sync in the standard prefix bootstrap process.  Most of the overlay is
based against the bootstrap tree, not the rsync tree, so, going forward, I will be trying to forward-port,
playing catch-up with the rsync tree, as my top-ish priority.

In the meanwhile, please be advised that I've taken an uber-agressive posture regarding what I'm willing
to put in there -- any kludge, no matter how vomit-inducingly awful it may be from an elegance/portability
perspective, has gone in, if I so much as suspected it might fix a problem.  That's resulted in a good number
of silly changes with low or negative intrinsic value.  So, there is some noise and there is some signal in
there.  Much of it will eventually go into the bit-bucket.  Please try not to think I'm a total freak, if you
see some really horrible stuff in there.

Please, tinker with it if you like, but I'd advise folks don't drive themselves crazy trying to actually use
this thing.  I do seem to have all of @system working reasonably well (pre-rsync) while bootstrapping this
tree, but that doesn't mean there's any sane path leading to where I managed to get with it.  I do eventually
want to produce a reasonable bootstrap recipe, but I clearly have my work cut out for me.

-gmt

Lion and vers_string

Hi,

I'm trying to get prefix working on my shiney new spotify laptop which
came with Lion and I am running into problems with binutils-apple
I have the gcc-4.2.1 version header but the compilation for
binutils-apple fails due to missing vers_string.

Any idea where I should get that ?

I installed Xcode and the commandline utilities but for some reason it
isn't included ?

Any help would be appreciated....

Sadly I don't have easy access to the installation CD's so I need to
download any commandline tools somewhere off the web.

Regards,

Ramon