| 1 |
On Jan 15, 2010, at 5:14 PM, Johan Hattne wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> On 15 Jan 2010, at 03:25, Heiko Przybyl wrote: |
| 5 |
> |
| 6 |
>> On Jan 15, 2010, at 2:50 AM, Johan Hattne wrote: |
| 7 |
>> |
| 8 |
>>> 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)? |
| 9 |
>> |
| 10 |
>> 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 ;) |
| 11 |
> |
| 12 |
> That's a different issue. What I failed to understand is why this |
| 13 |
> |
| 14 |
> arch=$(arch) |
| 15 |
> echo "-->${arch}<--" > /dev/stderr |
| 16 |
> |
| 17 |
> i.e. just inserting an echo into the find_targets() function of usr/share/eselect/modules/profile.eselect prints |
| 18 |
> |
| 19 |
> -->x64-macos<-- |
| 20 |
> |
| 21 |
> 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. |
| 22 |
> |
| 23 |
> // Cheers; Johan |
| 24 |
> |
| 25 |
|
| 26 |
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. |
| 27 |
|
| 28 |
-- Heiko |
Archives