Dear all;

I just installed snow leopard on my MacBook Pro and wanted to give the whole 64-bit thing a spin. Oddly enough I could only access 32-bit macos profiles. Also, the mask on ">=sys-apps/portage-2.2_pre" (defined in profiles/package.mask, but overridden in profiles/prefix/package.mask?) is in effect, so I've got the sneaky suspicion I've missed something obvious to everyone but me. Question is what?

// Cheers; Johan

On 11-01-2010 23:20:57 -0600, Johan Hattne wrote:
> Dear all;
>
> I just installed snow leopard on my MacBook Pro and wanted to give the whole 64-bit thing a spin. Oddly enough I could only access 32-bit macos profiles. Also, the mask on ">=sys-apps/portage-2.2_pre" (defined in profiles/package.mask, but overridden in profiles/prefix/package.mask?) is in effect, so I've got the sneaky suspicion I've missed something obvious to everyone but me. Question is what?

You'll have to explain a bit what you did. Did you try to switch, did
you rebootstrap? Do you use multiple trees?


--
Fabian Groffen
Gentoo on a different level

On 12 Jan 2010, at 04:20, Fabian Groffen wrote:

> On 11-01-2010 23:20:57 -0600, Johan Hattne wrote:
>> I just installed snow leopard on my MacBook Pro and wanted to give the whole 64-bit thing a spin. Oddly enough I could only access 32-bit macos profiles. Also, the mask on ">=sys-apps/portage-2.2_pre" (defined in profiles/package.mask, but overridden in profiles/prefix/package.mask?) is in effect, so I've got the sneaky suspicion I've missed something obvious to everyone but me. Question is what?
>
> You'll have to explain a bit what you did. Did you try to switch, did
> you rebootstrap? Do you use multiple trees?

I upgraded from Leopard to Snow Leopard, set CHOST to x86_64-apple-darwin10 in etc/make.conf, upgraded Xcode and used that to emerge new gcc-apple and binutils-apple into place, and then did an "emerge --emptytree system". So, no, I did not rebootstrap.

I'm also using the svn prefix overlay. That one still had the full licenses and profiles directories in it. Removing the profiles directory took care of the portage package mask from above.

The problem with "invisible" 64 bit profiles went away after reemerging all the eselect stuff (but I still don't understand why "arch=$(arch)" gives x64-macos in the profile.eselect module, while "arch" on the command line gives i386)?

I'll now find some lint to stuff the still-smoking bullet holes in my feet.

// Cheers; Johan

On Thu, 14 Jan 2010 19:50:03 -0600, Johan Hattne
<johan.hattne@utsouthwestern.edu> wrote:
> On 12 Jan 2010, at 04:20, Fabian Groffen wrote:
>
>> On 11-01-2010 23:20:57 -0600, Johan Hattne wrote:
>>> I just installed snow leopard on my MacBook Pro and wanted to give the
>>> whole 64-bit thing a spin. Oddly enough I could only access 32-bit
>>> macos profiles. Also, the mask on ">=sys-apps/portage-2.2_pre"
(defined
>>> in profiles/package.mask, but overridden in
>>> profiles/prefix/package.mask?) is in effect, so I've got the sneaky
>>> suspicion I've missed something obvious to everyone but me. Question
is
>>> what?
>>
>> You'll have to explain a bit what you did. Did you try to switch, did
>> you rebootstrap? Do you use multiple trees?
>
> I upgraded from Leopard to Snow Leopard, set CHOST to
> x86_64-apple-darwin10 in etc/make.conf, upgraded Xcode and used that to
> emerge new gcc-apple and binutils-apple into place, and then did an
"emerge
> --emptytree system". So, no, I did not rebootstrap.

Well, you can't just change the CHOST and expect everything to work.
Actually, it is quite a process to change your CHOST.
http://www.gentoo.org/doc/en/change-chost.xml
>
> I'm also using the svn prefix overlay. That one still had the full
> licenses and profiles directories in it. Removing the profiles
directory
> took care of the portage package mask from above.

You should be using rsync only.

>
> The problem with "invisible" 64 bit profiles went away after reemerging
> all the eselect stuff (but I still don't understand why "arch=$(arch)"
> gives x64-macos in the profile.eselect module, while "arch" on the
command
> line gives i386)?

Your toolchain is in a weird state.

>
> I'll now find some lint to stuff the still-smoking bullet holes in my
feet.

Your best best is to save your configuration files and world file and
rebootstrap. Although, technically you can probably work through this. It
is just not that fun.

Good luck.

>
> // Cheers; Johan

On Jan 15, 2010, at 2:50 AM, Johan Hattne wrote:

> The problem with "invisible" 64 bit profiles went away after reemerging all the eselect stuff (but I still don't understand why "arch=$(arch)" gives x64-macos in the profile.eselect module, while "arch" on the command line gives i386)?

That's normal for MacOS. Because 'arch - print machine hardware name (same as uname -m)' prints the architecture the machine is running on, which is in your case a 32bit kernel and thus i386. If you'd run the 64bit-kernel you would have something like x86_64 as result. That's the disadvantage(?) of being able to run 64bit applications with a 32bit kernel

-- Heiko

On 15 Jan 2010, at 03:25, Heiko Przybyl wrote:

> On Jan 15, 2010, at 2:50 AM, Johan Hattne wrote:
>
>> The problem with "invisible" 64 bit profiles went away after reemerging all the eselect stuff (but I still don't understand why "arch=$(arch)" gives x64-macos in the profile.eselect module, while "arch" on the command line gives i386)?
>
> That's normal for MacOS. Because 'arch - print machine hardware name (same as uname -m)' prints the architecture the machine is running on, which is in your case a 32bit kernel and thus i386. If you'd run the 64bit-kernel you would have something like x86_64 as result. That's the disadvantage(?) of being able to run 64bit applications with a 32bit kernel

That's a different issue. What I failed to understand is why this

arch=$(arch)
echo "-->${arch}<--" > /dev/stderr

i.e. just inserting an echo into the find_targets() function of usr/share/eselect/modules/profile.eselect prints

-->x64-macos<--

to stderr (which is not what I would have expected usr/bin/arch to output under any circumstances). In the meantime, I've found out.

// Cheers; Johan

On Jan 15, 2010, at 5:14 PM, Johan Hattne wrote:

>
> On 15 Jan 2010, at 03:25, Heiko Przybyl wrote:
>
>> On Jan 15, 2010, at 2:50 AM, Johan Hattne wrote:
>>
>>> The problem with "invisible" 64 bit profiles went away after reemerging all the eselect stuff (but I still don't understand why "arch=$(arch)" gives x64-macos in the profile.eselect module, while "arch" on the command line gives i386)?
>>
>> That's normal for MacOS. Because 'arch - print machine hardware name (same as uname -m)' prints the architecture the machine is running on, which is in your case a 32bit kernel and thus i386. If you'd run the 64bit-kernel you would have something like x86_64 as result. That's the disadvantage(?) of being able to run 64bit applications with a 32bit kernel
>
> That's a different issue. What I failed to understand is why this
>
> arch=$(arch)
> echo "-->${arch}<--" > /dev/stderr
>
> i.e. just inserting an echo into the find_targets() function of usr/share/eselect/modules/profile.eselect prints
>
> -->x64-macos<--
>
> to stderr (which is not what I would have expected usr/bin/arch to output under any circumstances). In the meantime, I've found out.
>
> // Cheers; Johan
>

Well it doesn't call (/usr)/bin/arch, but instead calls usr/share/eselect/libs/package-manager.bash's arch() function which it inherits with "inherit package-manager". That arch() function basically reduces to "portageq envvar sys-devel/gcc ARCH" which gives (for me as well) x64-macos.

-- Heiko

On 15 Jan 2010, at 10:28, Heiko Przybyl wrote:

> On Jan 15, 2010, at 5:14 PM, Johan Hattne wrote:
>
>> That's a different issue. What I failed to understand is why this
>>
>> arch=$(arch)
>> echo "-->${arch}<--" > /dev/stderr
>>
>> i.e. just inserting an echo into the find_targets() function of usr/share/eselect/modules/profile.eselect prints
>>
>> -->x64-macos<--
>>
>> to stderr (which is not what I would have expected usr/bin/arch to output under any circumstances). In the meantime, I've found out.
>
> Well it doesn't call (/usr)/bin/arch, but instead calls usr/share/eselect/libs/package-manager.bash's arch() function which it inherits with "inherit package-manager". That arch() function basically reduces to "portageq envvar sys-devel/gcc ARCH" which gives (for me as well) x64-macos.

I concur.

// Cheers; Johan