[gentoo-osx] [PREFIX] SUCCESS!!! system installed

[gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

During a freak reversal of magnetic poles, the latest prefix code was
able to emerge the base system!

It involved doing everything previously mentioned in this week's spam thread.
To get around the gcc issue, gcc3.3.6 was installed.

The next issue was complaints about "-fno-stack-protector" available
on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.

I hit the missing libpython2.4.so issue again, so I added
${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.

That along with a few ebuild foo.ebuild digest, and manually
downloading a few tarballs and putting them in distfiles allowed me to
finish emerge -av system.

Next task, get apache working.  Stay tuned....

-matt

ps - thanks a lot for your help grobian and kito!

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Nathan]

Sweet.  Progress is good.  Can't wait until I can install this on OS X
and start hammering on my esoteric ebuild needs knowing that the
system packages will work with beta-ish stability.

Maybe it'll be there by the time I get my MacBook Pro...in, like, 2007
or something... :-P

~ Nathan

On 3/22/06, m h <sesquile@gmail.com> wrote:
> During a freak reversal of magnetic poles, the latest prefix code was
> able to emerge the base system!
>
> It involved doing everything previously mentioned in this week's spam thread.
> To get around the gcc issue, gcc3.3.6 was installed.
>
> The next issue was complaints about "-fno-stack-protector" available
> on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
> adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.
>
> I hit the missing libpython2.4.so issue again, so I added
> ${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.
>
> That along with a few ebuild foo.ebuild digest, and manually
> downloading a few tarballs and putting them in distfiles allowed me to
> finish emerge -av system.
>
> Next task, get apache working.  Stay tuned....
>
> -matt
>
> ps - thanks a lot for your help grobian and kito!
>
> --
> gentoo-osx@gentoo.org mailing list
>
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Kito]

On Mar 22, 2006, at 6:32 PM, m h wrote:

> During a freak reversal of magnetic poles, the latest prefix code was
> able to emerge the base system!
>
> It involved doing everything previously mentioned in this week's  
> spam thread.
> To get around the gcc issue, gcc3.3.6 was installed.

Ok, so we'll bump the gcc versions in the prefix tree. I'd like to  
4.x in there anyway as well.

>
> The next issue was complaints about "-fno-stack-protector" available
> on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
> adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.

This should be solved by using gcc-config, which sets the appropriate  
symlinks. Its probably broken in prefix though, haven't tested it yet.

>
> I hit the missing libpython2.4.so issue again, so I added
> ${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.

Hmm, so Diego was right...this obviously needs to be fixed. did  
running env-update work as expected?

>
> That along with a few ebuild foo.ebuild digest, and manually
> downloading a few tarballs and putting them in distfiles allowed me to
> finish emerge -av system.

Why the manual downloads?

>
> Next task, get apache working.  Stay tuned....
>
> -matt
>
> ps - thanks a lot for your help grobian and kito!
>

No problem at all, thanks for testing ;). Glad you finally got it  
working, hopefully we can get the bootstrap script working well  
enough to make this not as tedious/trial-and-error.

--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

On 3/23/06, Kito <kito@gentoo.org> wrote:
>
> On Mar 22, 2006, at 6:32 PM, m h wrote:
>
> > During a freak reversal of magnetic poles, the latest prefix code was
> > able to emerge the base system!
> >
> > It involved doing everything previously mentioned in this week's
> > spam thread.
> > To get around the gcc issue, gcc3.3.6 was installed.
>
> Ok, so we'll bump the gcc versions in the prefix tree. I'd like to
> 4.x in there anyway as well.

This was NOT a version bump.  The version in  the tree was 3.4.4...

>
> >
> > The next issue was complaints about "-fno-stack-protector" available
> > on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
> > adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.
>
> This should be solved by using gcc-config, which sets the appropriate
> symlinks. Its probably broken in prefix though, haven't tested it yet.
>

Yeah, I didn't even try this....

> >
> > I hit the missing libpython2.4.so issue again, so I added
> > ${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.
>
> Hmm, so Diego was right...this obviously needs to be fixed. did
> running env-update work as expected?


Didn't try this either.  Maybe tomorrow. (I'm not at the machine right now)

>
> >
> > That along with a few ebuild foo.ebuild digest, and manually
> > downloading a few tarballs and putting them in distfiles allowed me to
> > finish emerge -av system.
>
> Why the manual downloads?

Don't know but some of the tarballs weren't found in the default
places.  (I don't think it was an exhaustive search, but after I see 5
or so failed attempts I just google for "Index of" and the tarball
name, and download it and put it in distfiles.

>
> >
> > Next task, get apache working.  Stay tuned....
> >
> > -matt
> >
> > ps - thanks a lot for your help grobian and kito!
> >
>
> No problem at all, thanks for testing ;). Glad you finally got it
> working, hopefully we can get the bootstrap script working well
> enough to make this not as tedious/trial-and-error.
>

I'm still interested in seeing this bootstrap script when it makes
it's appearance.

-matt

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Grobian]

On 23-03-2006 04:14:17 +0000, m h wrote:
> On 3/23/06, Kito <kito@gentoo.org> wrote:
> > > To get around the gcc issue, gcc3.3.6 was installed.
> >
> > Ok, so we'll bump the gcc versions in the prefix tree. I'd like to
> > 4.x in there anyway as well.
> 
> This was NOT a version bump.  The version in  the tree was 3.4.4...

... which works fine on amd64 here...

(Ok, I screwed it up, but that's my own fault.)

I do have a question though.

Did you install binutils, gcc, linux-headers and glibc from portage now?
The current stuff appears to work, but I think it has some paths set
wrong, therefore using still headers from / instead of ${PREFIX}.

I'm on a fix here, if I can get my gcc recompiled (I screwed up the
linker: ${PREFIX}/usr/bin/ld: crt1.o: No such file: No such file or directory)

> > > The next issue was complaints about "-fno-stack-protector" available
> > > on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
> > > adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.
> >
> > This should be solved by using gcc-config, which sets the appropriate
> > symlinks. Its probably broken in prefix though, haven't tested it yet.

Yeah, but this tool doesn't work (yet).  We need it, because maintaining
the symlinks yourself is a tedious job.

> > > I hit the missing libpython2.4.so issue again, so I added
> > > ${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.
> >
> > Hmm, so Diego was right...this obviously needs to be fixed. did
> > running env-update work as expected?

It probably runs fine, but as long as you don't use bash, tcsh or zsh
from the prefix, it won't source it.  You need to emerge one of those
shells (at least for tcsh I am 100% sure ;) ) and execute it, because
they are properly patched/configured to use the prefix to look for
system-wide init files.  Only with such shell you get the contents of
"env-update", a.k.a. env.d/*

> > > That along with a few ebuild foo.ebuild digest, and manually
> > > downloading a few tarballs and putting them in distfiles allowed me to
> > > finish emerge -av system.
> >
> > Why the manual downloads?
> 
> Don't know but some of the tarballs weren't found in the default
> places.  (I don't think it was an exhaustive search, but after I see 5
> or so failed attempts I just google for "Index of" and the tarball
> name, and download it and put it in distfiles.

Hmmm, ok, maybe the mirror select thinghy would come in handy here.  I
noticed this myself too, that it quite often hangs on slow servers or
just can't find the file on many mirrors it tries.

> > > Next task, get apache working.  Stay tuned....

wow!  That's freaky!  (I'm just working on openssh -> but that triggered
a bug in the current gcc/binutils combination)

Anyway, I'm interested in how easy you can make it work!


-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

On 3/23/06, Grobian <grobian@gentoo.org> wrote:
> On 23-03-2006 04:14:17 +0000, m h wrote:
> > On 3/23/06, Kito <kito@gentoo.org> wrote:
> > > > To get around the gcc issue, gcc3.3.6 was installed.
> > >
> > > Ok, so we'll bump the gcc versions in the prefix tree. I'd like to
> > > 4.x in there anyway as well.
> >
> > This was NOT a version bump.  The version in  the tree was 3.4.4...
>
> ... which works fine on amd64 here...
>
> (Ok, I screwed it up, but that's my own fault.)
>
> I do have a question though.
>
> Did you install binutils, gcc, linux-headers and glibc from portage now?
> The current stuff appears to work, but I think it has some paths set
> wrong, therefore using still headers from / instead of ${PREFIX}.

I've installed everything but glibc.

>
> I'm on a fix here, if I can get my gcc recompiled (I screwed up the
> linker: ${PREFIX}/usr/bin/ld: crt1.o: No such file: No such file or directory)
>

I'm actually having linker issues with apache.  For some reason it is
trying to look for libz in /lib instead of ${PREFIX}/usr/lib  (even
though I've told apache that's the location of zlib).  Even when I
compile a simple c program that includes zlib.h

 /* end confdefs.h.  */
#include <zlib.h>
int
main ()
{
int i = Z_OK;
  ;
  return 0;
}

Compile it:
gcc -o foo -O2 -mcpu=i686 -pipe -pthread -I.
-L/data1/tmp/Mar21/usr/lib foo.c -lz

I get:
/usr/bin/ld: cannot find /lib/libz.so
collect2: ld returned 1 exit status

Very weird.....

> > > > The next issue was complaints about "-fno-stack-protector" available
> > > > on gcc.  The was no gcc binary in $PREFIX, so I resolved this by
> > > > adding a gcc symlink in $PREFIX to ${PREFIX}/usr/bin/gcc-3.3.6.
> > >
> > > This should be solved by using gcc-config, which sets the appropriate
> > > symlinks. Its probably broken in prefix though, haven't tested it yet.
>
> Yeah, but this tool doesn't work (yet).  We need it, because maintaining
> the symlinks yourself is a tedious job.
>

gcc is the only symlink (for binaries) I have right now.  Maybe that's
indicative of the linker problem...

> > > > I hit the missing libpython2.4.so issue again, so I added
> > > > ${PREFIX}/usr/lib/ to  LD_LIBRARY_PATH.
> > >
> > > Hmm, so Diego was right...this obviously needs to be fixed. did
> > > running env-update work as expected?
>
> It probably runs fine, but as long as you don't use bash, tcsh or zsh
> from the prefix, it won't source it.  You need to emerge one of those
> shells (at least for tcsh I am 100% sure ;) ) and execute it, because
> they are properly patched/configured to use the prefix to look for
> system-wide init files.  Only with such shell you get the contents of
> "env-update", a.k.a. env.d/*

I've installed prefix bash.
>
> > > > That along with a few ebuild foo.ebuild digest, and manually
> > > > downloading a few tarballs and putting them in distfiles allowed me to
> > > > finish emerge -av system.
> > >
> > > Why the manual downloads?
> >
> > Don't know but some of the tarballs weren't found in the default
> > places.  (I don't think it was an exhaustive search, but after I see 5
> > or so failed attempts I just google for "Index of" and the tarball
> > name, and download it and put it in distfiles.
>
> Hmmm, ok, maybe the mirror select thinghy would come in handy here.  I
> noticed this myself too, that it quite often hangs on slow servers or
> just can't find the file on many mirrors it tries.
>
> > > > Next task, get apache working.  Stay tuned....
>
> wow!  That's freaky!  (I'm just working on openssh -> but that triggered
> a bug in the current gcc/binutils combination)
>
> Anyway, I'm interested in how easy you can make it work!
>
>
Stuck on the linker issue right now....

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

>
> I'm actually having linker issues with apache.  For some reason it is
> trying to look for libz in /lib instead of ${PREFIX}/usr/lib  (even
> though I've told apache that's the location of zlib).  Even when I
> compile a simple c program that includes zlib.h
>
>  /* end confdefs.h.  */
> #include <zlib.h>
> int
> main ()
> {
> int i = Z_OK;
>   ;
>   return 0;
> }
>
> Compile it:
> gcc -o foo -O2 -mcpu=i686 -pipe -pthread -I.
> -L/data1/tmp/Mar21/usr/lib foo.c -lz
>
> I get:
> /usr/bin/ld: cannot find /lib/libz.so
> collect2: ld returned 1 exit status
>
> Very weird.....
>

More data.  If I compile with:
-L/data1/tmp/Mar21/usr/lib/JUNK
or
-L/data1/tmp/Mar21
or
*no -L*
It compiles.... ldd states that it is linking with the system zlib
(/usr/lib/lib.so.1)

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Kito]

On Mar 23, 2006, at 7:52 PM, m h wrote:

>>
>> I'm actually having linker issues with apache.  For some reason it is
>> trying to look for libz in /lib instead of ${PREFIX}/usr/lib  (even
>> though I've told apache that's the location of zlib).  Even when I
>> compile a simple c program that includes zlib.h
>>
>>  /* end confdefs.h.  */
>> #include <zlib.h>
>> int
>> main ()
>> {
>> int i = Z_OK;
>>   ;
>>   return 0;
>> }
>>
>> Compile it:
>> gcc -o foo -O2 -mcpu=i686 -pipe -pthread -I.
>> -L/data1/tmp/Mar21/usr/lib foo.c -lz
>>
>> I get:
>> /usr/bin/ld: cannot find /lib/libz.so
>> collect2: ld returned 1 exit status
>>
>> Very weird.....
>>

Hrmm, your gcc is using the system ld.... we need to fix that first I  
think.

>
> More data.  If I compile with:
> -L/data1/tmp/Mar21/usr/lib/JUNK
> or
> -L/data1/tmp/Mar21
> or
> *no -L*
> It compiles.... ldd states that it is linking with the system zlib
> (/usr/lib/lib.so.1)

Yeah, lets go back to the first problem of getting gcc using the  
portage binutils....I don't like this one ;)


--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Grobian]

On 23-03-2006 21:07:21 -0600, Kito wrote:
> On Mar 23, 2006, at 7:52 PM, m h wrote:
> >>I get:
> >>/usr/bin/ld: cannot find /lib/libz.so
> >>collect2: ld returned 1 exit status
> >>
> >>Very weird.....
> >>
> 
> Hrmm, your gcc is using the system ld.... we need to fix that first I think.

Probably forgot to update the symlink to ld?

> Yeah, lets go back to the first problem of getting gcc using the portage 
> binutils....I don't like this one ;)

Please try.

-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

On 3/24/06, Grobian <grobian@gentoo.org> wrote:
> On 23-03-2006 21:07:21 -0600, Kito wrote:
> > On Mar 23, 2006, at 7:52 PM, m h wrote:
> > >>I get:
> > >>/usr/bin/ld: cannot find /lib/libz.so
> > >>collect2: ld returned 1 exit status
> > >>
> > >>Very weird.....
> > >>
> >
> > Hrmm, your gcc is using the system ld.... we need to fix that first I think.
>
> Probably forgot to update the symlink to ld?
>
> > Yeah, lets go back to the first problem of getting gcc using the portage
> > binutils....I don't like this one ;)
>
> Please try.
>

So I tried re-emerging binutils.  I guess it fails at the end, but
gets far enough that it thinks it's installed... Here's the tail end:
--- !empty dir /data1/tmp/Mar21
--- !empty dir /data1/tmp
--- !empty dir /data1
!!!   EBUILD_PHASE=postrm
!!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/data1/tmp/Mar21
!!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
!!!   PREFIX=/data1/tmp/Mar21
!!!   ROOT=/data1/tmp/Mar21
/data1/tmp/Mar21/usr/bin/binutils-config: line 14:
/etc/init.d/functions.sh: No such file or directory
/data1/tmp/Mar21/usr/bin/binutils-config: line 14:
/etc/init.d/functions.sh: No such file or directory
!!!   EBUILD_PHASE=clean
!!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/data1/tmp/Mar21
!!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
!!!   PREFIX=/data1/tmp/Mar21
!!!   ROOT=/data1/tmp/Mar21
>>> Original instance of package unmerged safely.
!!!   EBUILD_PHASE=postinst
!!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/data1/tmp/Mar21
!!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
!!!   PREFIX=/data1/tmp/Mar21
!!!   ROOT=/data1/tmp/Mar21
/data1/tmp/Mar21/usr/bin/binutils-config: line 14:
/etc/init.d/functions.sh: No such file or directory
/data1/tmp/Mar21/usr/bin/binutils-config: Could not source
/etc/init.d/functions.sh!
>>> Regenerating /etc/ld.so.cache...
>>> sys-devel/binutils-2.16.1-r1 merged.
!!!   EBUILD_PHASE=clean
!!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/data1/tmp/Mar21
!!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
!!!   PREFIX=/data1/tmp/Mar21
!!!   ROOT=/data1/tmp/Mar21

>>> No packages selected for removal by clean.

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.


 * error scanning /etc

-------------------------------
Then it dies....

Also looking over the directories when it's trying to install, it
seems like there are some places where it's trying to install/remove
from ${PREFIX}/${PREFIX}!

Here's an example of what I mean...
--- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1/ldscripts
--- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1/include
--- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1
--- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu

My PREFIX is /data1/tmp/Mar21 so there are a lot of ${PREFIX}/${PREFIX}

Ideas about dealing with the double PREFIX?  I guess Mac people are
running binutils issues since they use the host linker?

-matt

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[m h]

On 3/24/06, m h <sesquile@gmail.com> wrote:
> On 3/24/06, Grobian <grobian@gentoo.org> wrote:
> > On 23-03-2006 21:07:21 -0600, Kito wrote:
> > > On Mar 23, 2006, at 7:52 PM, m h wrote:
> > > >>I get:
> > > >>/usr/bin/ld: cannot find /lib/libz.so
> > > >>collect2: ld returned 1 exit status
> > > >>
> > > >>Very weird.....
> > > >>
> > >
> > > Hrmm, your gcc is using the system ld.... we need to fix that first I think.
> >
> > Probably forgot to update the symlink to ld?
> >
> > > Yeah, lets go back to the first problem of getting gcc using the portage
> > > binutils....I don't like this one ;)
> >
> > Please try.
> >
>
> So I tried re-emerging binutils.  I guess it fails at the end, but
> gets far enough that it thinks it's installed... Here's the tail end:
> --- !empty dir /data1/tmp/Mar21
> --- !empty dir /data1/tmp
> --- !empty dir /data1
> !!!   EBUILD_PHASE=postrm
> !!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/data1/tmp/Mar21
> !!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
> !!!   PREFIX=/data1/tmp/Mar21
> !!!   ROOT=/data1/tmp/Mar21
> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
> /etc/init.d/functions.sh: No such file or directory
> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
> /etc/init.d/functions.sh: No such file or directory
> !!!   EBUILD_PHASE=clean
> !!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/data1/tmp/Mar21
> !!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
> !!!   PREFIX=/data1/tmp/Mar21
> !!!   ROOT=/data1/tmp/Mar21
> >>> Original instance of package unmerged safely.
> !!!   EBUILD_PHASE=postinst
> !!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/data1/tmp/Mar21
> !!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
> !!!   PREFIX=/data1/tmp/Mar21
> !!!   ROOT=/data1/tmp/Mar21
> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
> /etc/init.d/functions.sh: No such file or directory
> /data1/tmp/Mar21/usr/bin/binutils-config: Could not source
> /etc/init.d/functions.sh!
> >>> Regenerating /etc/ld.so.cache...
> >>> sys-devel/binutils-2.16.1-r1 merged.
> !!!   EBUILD_PHASE=clean
> !!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/data1/tmp/Mar21
> !!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
> !!!   PREFIX=/data1/tmp/Mar21
> !!!   ROOT=/data1/tmp/Mar21
>
> >>> No packages selected for removal by clean.
>
> >>> Auto-cleaning packages...
>
> >>> No outdated packages were found on your system.
>
>
>  * error scanning /etc
>
> -------------------------------
> Then it dies....
>
> Also looking over the directories when it's trying to install, it
> seems like there are some places where it's trying to install/remove
> from ${PREFIX}/${PREFIX}!
>
> Here's an example of what I mean...
> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1/ldscripts
> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1/include
> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu/2.16.1
> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/i686-pc-linux-gnu
>
> My PREFIX is /data1/tmp/Mar21 so there are a lot of ${PREFIX}/${PREFIX}
>
> Ideas about dealing with the double PREFIX?  I guess Mac people are
> running binutils issues since they use the host linker?
>
> -matt
>

Some detective work.

It appears that the Makefile for binutils is combining together 2
variables.  $(DESTDIR)$(prefix) and storing it in a variable called
$(MAKEDIRS).  DESTDIR is equal to ${D} (this is set in
toolchain-binutils.eclass).  And ${prefix} is ... ${PREFIX} (which
also comes from the eclass where --prefix=${PREFIX}/usr).  Since ${D}
ends with ${PREFIX} there ends up being a double prefix.....

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Kito]

On Mar 24, 2006, at 6:56 PM, m h wrote:

> On 3/24/06, m h <sesquile@gmail.com> wrote:
>> On 3/24/06, Grobian <grobian@gentoo.org> wrote:
>>> On 23-03-2006 21:07:21 -0600, Kito wrote:
>>>> On Mar 23, 2006, at 7:52 PM, m h wrote:
>>>>>> I get:
>>>>>> /usr/bin/ld: cannot find /lib/libz.so
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> Very weird.....
>>>>>>
>>>>
>>>> Hrmm, your gcc is using the system ld.... we need to fix that  
>>>> first I think.
>>>
>>> Probably forgot to update the symlink to ld?
>>>
>>>> Yeah, lets go back to the first problem of getting gcc using the  
>>>> portage
>>>> binutils....I don't like this one ;)
>>>
>>> Please try.
>>>
>>
>> So I tried re-emerging binutils.  I guess it fails at the end, but
>> gets far enough that it thinks it's installed... Here's the tail end:
>> --- !empty dir /data1/tmp/Mar21
>> --- !empty dir /data1/tmp
>> --- !empty dir /data1
>> !!!   EBUILD_PHASE=postrm
>> !!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/ 
>> data1/tmp/Mar21
>> !!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
>> !!!   PREFIX=/data1/tmp/Mar21
>> !!!   ROOT=/data1/tmp/Mar21
>> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
>> /etc/init.d/functions.sh: No such file or directory
>> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
>> /etc/init.d/functions.sh: No such file or directory
>> !!!   EBUILD_PHASE=clean
>> !!!   D=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/ 
>> data1/tmp/Mar21
>> !!!   DEST=/data1/tmp/Mar21/var/tmp/binpkgs/binutils-2.16.1-r1/image/
>> !!!   PREFIX=/data1/tmp/Mar21
>> !!!   ROOT=/data1/tmp/Mar21
>>>>> Original instance of package unmerged safely.
>> !!!   EBUILD_PHASE=postinst
>> !!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/ 
>> data1/tmp/Mar21
>> !!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
>> !!!   PREFIX=/data1/tmp/Mar21
>> !!!   ROOT=/data1/tmp/Mar21
>> /data1/tmp/Mar21/usr/bin/binutils-config: line 14:
>> /etc/init.d/functions.sh: No such file or directory
>> /data1/tmp/Mar21/usr/bin/binutils-config: Could not source
>> /etc/init.d/functions.sh!
>>>>> Regenerating /etc/ld.so.cache...
>>>>> sys-devel/binutils-2.16.1-r1 merged.
>> !!!   EBUILD_PHASE=clean
>> !!!   D=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/ 
>> data1/tmp/Mar21
>> !!!   DEST=/data1/tmp/Mar21/var/tmp/portage/binutils-2.16.1-r1/image/
>> !!!   PREFIX=/data1/tmp/Mar21
>> !!!   ROOT=/data1/tmp/Mar21
>>
>>>>> No packages selected for removal by clean.
>>
>>>>> Auto-cleaning packages...
>>
>>>>> No outdated packages were found on your system.
>>
>>
>>  * error scanning /etc
>>
>> -------------------------------
>> Then it dies....
>>
>> Also looking over the directories when it's trying to install, it
>> seems like there are some places where it's trying to install/remove
>> from ${PREFIX}/${PREFIX}!
>>
>> Here's an example of what I mean...
>> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/ 
>> i686-pc-linux-gnu/2.16.1/ldscripts
>> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/ 
>> i686-pc-linux-gnu/2.16.1/include
>> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/ 
>> i686-pc-linux-gnu/2.16.1
>> --- !empty dir /data1/tmp/Mar21/data1/tmp/Mar21/usr/lib/binutils/ 
>> i686-pc-linux-gnu
>>
>> My PREFIX is /data1/tmp/Mar21 so there are a lot of ${PREFIX}/$ 
>> {PREFIX}
>>
>> Ideas about dealing with the double PREFIX?  I guess Mac people are
>> running binutils issues since they use the host linker?
>>
>> -matt
>>
>
> Some detective work.
>
> It appears that the Makefile for binutils is combining together 2
> variables.  $(DESTDIR)$(prefix) and storing it in a variable called
> $(MAKEDIRS).  DESTDIR is equal to ${D} (this is set in
> toolchain-binutils.eclass).  And ${prefix} is ... ${PREFIX} (which
> also comes from the eclass where --prefix=${PREFIX}/usr).  Since ${D}
> ends with ${PREFIX} there ends up being a double prefix.....

Nice work. I'll fix this in the next big commit. In the meantime you  
can try changing that ${D} to ${DEST}.

FYI, in the ebuild environment from now on we will be using the $ 
{EDEST} variable, which equates to ${D} without the appended PREFIX.

--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] SUCCESS!!! system installed

[Grobian]

On 23-03-2006 17:41:40 -0800, m h wrote:
> > I'm on a fix here, if I can get my gcc recompiled (I screwed up the
> > linker: ${PREFIX}/usr/bin/ld: crt1.o: No such file: No such file or directory)
> >
> 
> I'm actually having linker issues with apache.  For some reason it is
> trying to look for libz in /lib instead of ${PREFIX}/usr/lib  (even
> though I've told apache that's the location of zlib).  Even when I
> compile a simple c program that includes zlib.h

This is EXACTLY the problem I have and trying to tackle right now.

> gcc is the only symlink (for binaries) I have right now.  Maybe that's
> indicative of the linker problem...

I believe not.  GCC or the linker is the problem.  If you look at the
SEARCH_DIR things for the linker (`ld --verbose | head -n20`) you will
see that it doesn't even looks in ${PREFIX}/lib.

> Stuck on the linker issue right now....

Ok... so it becomes even more important that I find a fix for this
issue...


-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list