Re: [gentoo-user] Swap is manually 'swapon-able' but not via fstab...?
Gregory Shearman [13-08-11 07:48]: > In linux.gentoo.user, you wrote: > > Hi, > > > > When I do a > > > > beagleboneblack:/root>swapon /dev/sda2 > > beagleboneblack:/root>free > > total used free sharedbuffers cached > > Mem:507476 50812 456664 0 13108 > > 17244 > > -/+ buffers/cache: 20460 487016 > > Swap: 5242876 05242876 > > > > > > swap is added to the system. > > > > If I add > > > > /dev/sda2 none swap sw > > 0 0 > > > > swapspace will not be used after a reboot. > > > > dmesg has nothing specific... > > > > What did I wrong here? Why get swap not used via fstab? > > Do you have swap added to the boot runlevel? > > # rc-update add swap boot > > -- > Regards, > Gregory. > Gentoo Linux - Penguin Power > > -- > Regards, > Gregory. > Gentoo Linux - Penguin Power > Hi Samuli, hi Gregory, ...the rc-update of swap was missing! Thanks a lot! Best regards, mcc
Re: [gentoo-user] Moving from old udev to eudev
On Sun, 11 Aug 2013 01:36:59 -0400, Walter Dnes wrote: > > I expect it to happen around every new udev release that causes > > slight incompability; the default of the virtual/udev, sys-fs/udev, > > doesn't have to wait for the alternative providers. > > The elegant solution is outlined in my post... > http://www.gossamer-threads.com/lists/gentoo/user/275977#275977 > > I.e. *UNTIL SUCH TIME AS EUDEV HITS STABLE* (on whatever arch you're > using), add the entry > > signature.asc Description: PGP signature
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-11 6:04 AM, Neil Bothwick wrote: I'm afraid that doesn't solve the problem I had at all, because I'm running ~arch. It's as Samuli said, the eudev release lagged behind udev, causing the virtual to look elsewhere for its satisfaction. So, looks like the best strategy is not to blindly update eudev, and always check these things, before attempting an upgrade, and waiting for it to catch up if/when it happens. No biggie, except maybe for those used to just blindly updating everything without looking.
Re: [gentoo-user] Moving from old udev to eudev
On Sun, 11 Aug 2013 10:25:33 -0400, Tanstaafl wrote: > On 2013-08-11 6:04 AM, Neil Bothwick wrote: > > I'm afraid that doesn't solve the problem I had at all, because I'm > > running ~arch. It's as Samuli said, the eudev release lagged behind > > udev, causing the virtual to look elsewhere for its satisfaction. > > So, looks like the best strategy is not to blindly update eudev, and > always check these things, before attempting an upgrade, and waiting > for it to catch up if/when it happens. Well, you shouldn't blindly update anything, but the issue here was eudev *not* being updated when the virtual was, and both cause and result were quite clear. > No biggie, except maybe for those used to just blindly updating > everything without looking. Those people are used to dealing with breakage, or soon will be :) -- Neil Bothwick Save the whales. Collect the whole set. signature.asc Description: PGP signature
Re: [gentoo-user] Moving from old udev to eudev
On 2013-08-11 11:15 AM, Neil Bothwick wrote: On Sun, 11 Aug 2013 10:25:33 -0400, Tanstaafl wrote: So, looks like the best strategy is not to blindly update eudev, and always check these things, before attempting an upgrade, and waiting for it to catch up if/when it happens. Well, you shouldn't blindly update anything, True... and I never do. I sync daily, then do an emerge -pvuDN world, and note which packages want to be updated. I then track them, and after a few days, if nothing has changed, update them. For critical apps (boot/system related or server app related (ie, postfix, dovecot, etc), I also always google for any problems with them (gentoo+appver) right before updating. I was always fairly careful in the past, but I started being anal about it after I got bit by the minor mailman version bump a while (few years?) ago that changed the locations of critical stuff (like, where the lists were stored), thereby violating one of gentoo's cardinal rules that minor version bumps don't make changes that break things, at least not without lots of warning in the form of a detailed news item explaining what needs to be done to avoid the breakage. but the issue here was eudev *not* being updated when the virtual was, and both cause and result were quite clear. Right, but I was talking about not updating *anything* related to any mission critical apps, and that would include the virtual/udev as well. That said - shouldn't this be taken care of by the the virtual/udev package itself? Shoudln't it keep track of what versions of udev *and* eudev it supports, and warn you (via a [B]blocker)?
[gentoo-user] Question re: make.conf/profile location change
Hello, Was reviewing older news items and was wondering about this one: "# eselect news read 12 2012-09-09-make.conf-and-make.profile-move Titlemake.conf and make.profile move Author Jorge Manuel B. S. Vicetto Posted 2012-09-09 Revision 1 Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the preferred location, you may want to take the chance to move the files in your system(s) to the new location." My question is, what if they are in both locations? Which ones are used? I would assume that portage now looks first in /etc/portage and uses those if it finds them, and if not, looks in /etc - but the news item is incomplete on this question.
Re: [gentoo-user] Question re: make.conf/profile location change
Am Sun, 11 Aug 2013 11:58:48 -0400 schrieb Tanstaafl : > Hello, > > Was reviewing older news items and was wondering about this one: > > "# eselect news read 12 > 2012-09-09-make.conf-and-make.profile-move >Titlemake.conf and make.profile move >Author Jorge Manuel B. S. Vicetto >Posted 2012-09-09 >Revision 1 > > Starting next week, new stages will have make.conf and make.profile > moved from /etc to /etc/portage. This is a change in the installation > defaults, that will only affect new installs so it doesn't affect > current systems. > > Current users don't need to do anything. But if you want to follow the > preferred location, you may want to take the chance to move the files > in your system(s) to the new location." > > My question is, what if they are in both locations? Which ones are used? > I would assume that portage now looks first in /etc/portage and uses > those if it finds them, and if not, looks in /etc - but the news item is > incomplete on this question. When in doubt, read the man page (make.conf(5)): "[...] DESCRIPTION This file contains various variables that are used by Portage. Portage will check the currently-defined environment variables first for any settings. If no environ‐ ment settings are found, Portage then checks the make.conf files. Both /etc/make.conf and /etc/portage/make.conf are checked (if present), and settings from /etc/portage/make.conf will override settings from /etc/make.conf. [...]" HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Question re: make.conf/profile location change
On 11/08/2013 17:58, Tanstaafl wrote: > Hello, > > Was reviewing older news items and was wondering about this one: > > "# eselect news read 12 > 2012-09-09-make.conf-and-make.profile-move > Titlemake.conf and make.profile move > Author Jorge Manuel B. S. Vicetto > Posted 2012-09-09 > Revision 1 > > Starting next week, new stages will have make.conf and make.profile > moved from /etc to /etc/portage. This is a change in the installation > defaults, that will only affect new installs so it doesn't affect > current systems. > > Current users don't need to do anything. But if you want to follow the > preferred location, you may want to take the chance to move the files > in your system(s) to the new location." > > My question is, what if they are in both locations? Which ones are used? > I would assume that portage now looks first in /etc/portage and uses > those if it finds them, and if not, looks in /etc - but the news item is > incomplete on this question. > My question is why do you have files in both locations? /etc is the old location, /etc/portage is the new location, so simply delete the one you do not want. It's easy enough to determine for yourself which one has higher priority. Make the files differ in some way that causes an easy to detect change in emerge output. Move the file out of the way one by one and run energe world. Then you will have the answer to your question. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Question re: make.conf/profile location change
On 2013-08-11 12:03 PM, Marc Joliet wrote: When in doubt, read the man page (make.conf(5)): "[...] DESCRIPTION This file contains various variables that are used by Portage. Portage will check the currently-defined environment variables first for any settings. If no environ‐ ment settings are found, Portage then checks the make.conf files. Both /etc/make.conf and /etc/portage/make.conf are checked (if present), and settings from /etc/portage/make.conf will override settings from /etc/make.conf. [...]" Thanks... my point was more that the news item didn't explain this - also, this answers as to make.conf, but what about make.profile? I just don't like being forced to assume, or 'test for myself', when it could be made crystal clear in the news item/docs. Also, would ~ cd /etc/portage ~ ln -s make.profile ../usr/portage/profiles/default/linux/amd64/13.0 Be the right way to create the make.profile symlink in the new location? Not sure why the two preceeding dots are there in the current one in /etc, but they are... On 2013-08-11 12:16 PM, Alan McKinnon wrote: > My question is why do you have files in both locations? I don't... I was getting ready to change these, and was just asking the question... ;)
Re: [gentoo-user] Question re: make.conf/profile location change
Am Sun, 11 Aug 2013 12:48:44 -0400 schrieb Tanstaafl : > On 2013-08-11 12:03 PM, Marc Joliet wrote: > > When in doubt, read the man page (make.conf(5)): > > > > "[...] > > DESCRIPTION > > This file contains various variables that are used by Portage. > > Portage will check > > the currently-defined environment variables first for any settings. > > If no environ‐ > > ment settings are found, Portage then checks the > > make.conf files. Both > > /etc/make.conf and /etc/portage/make.conf are checked (if > > present), and settings > > from /etc/portage/make.conf will override settings from > > /etc/make.conf. [...]" > > Thanks... my point was more that the news item didn't explain this - > also, this answers as to make.conf, but what about make.profile? portage(5) says: "If both /etc/portage/make.profile/ and /etc/make.profile/ exist, then /etc/portage/make.profile/ will be preferred." > I just don't like being forced to assume, or 'test for myself', when it > could be made crystal clear in the news item/docs. Yes, I agree that that might perhaps have been nice to mention it in the news item (although IMHO that's the sort of information the man pages are there for), but it *is* crystal clear in the docs, or do you not count the man pages to the docs? > Also, would > > ~ cd /etc/portage > ~ ln -s make.profile ../usr/portage/profiles/default/linux/amd64/13.0 > > Be the right way to create the make.profile symlink in the new location? AFAIK eselect profile uses the new location, but I don't remember how precisely I moved it (not that it matters). > Not sure why the two preceeding dots are there in the current one in > /etc, but they are... The current location is /etc/make.conf, right? Then ../usr/[...] will resolve to /usr/[...], whereas your ln command above will resolve to /etc/usr/[...], which is, erm, wrong :) . [...] HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: PGP signature
[gentoo-user] sys-auth/consolekit-0.4.6 just sits there.
I notice this starts but never does anything. I end up doing a ctrl c
to stop it. I tried with two different versions of portage so I don't
think it is portage itself.
Also, it's downloaded and genlop -c shows nothing being done. I'm not
sure what it is waiting on. This is one attempt:
root@fireball / # emerge -uvaDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-auth/consolekit-0.4.6 [0.4.5_p20120320-r1] USE="pam
(policykit) -acl -debug -doc (-selinux) {-test}" 0 kB
Total: 1 package (1 upgrade), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-auth/consolekit-0.4.6
>>> Jobs: 0 of 1 complete, 1 runningLoad avg: 0.28,
0.22, 0.31
^CTraceback (most recent call last):
Exiting on signal 2
File "/usr/lib64/portage/pym/portage/locks.py", line 147, in lockfile
locking_method(myfd, fcntl.LOCK_EX|fcntl.LOCK_NB)
IOError: [Errno 11] Resource temporarily unavailable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib64/portage/bin/lock-helper.py", line 29, in
rval = main(sys.argv[1:])
File "/usr/lib64/portage/bin/lock-helper.py", line 21, in main
lock_obj = portage.locks.lockfile(args[0], wantnewlockfile=True)
File "/usr/lib64/portage/pym/portage/locks.py", line 173, in lockfile
locking_method(myfd, fcntl.LOCK_EX)
KeyboardInterrupt
_LockProcess: failed to acquire lock on
'/var/tmp/portage/sys-auth/consolekit-0.4.6'
Traceback (most recent call last):
File "/usr/bin/emerge", line 50, in
retval = emerge_main()
File "/usr/lib64/portage/pym/_emerge/main.py", line 1052, in emerge_main
gc_locals=locals().clear)
File "/usr/lib64/portage/pym/_emerge/actions.py", line 3950, in run_action
myopts, myaction, myfiles, spinner)
File "/usr/lib64/portage/pym/_emerge/actions.py", line 477, in
action_build
retval = mergetask.merge()
File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1010, in merge
rval = self._merge()
File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1395, in _merge
self._main_loop()
File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1362, in
_main_loop
self._schedule()
File "/usr/lib64/portage/pym/_emerge/PollScheduler.py", line 127, in
_schedule
self._schedule_tasks()
File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1563, in
_schedule_tasks
if self._schedule_tasks_imp():
File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1663, in
_schedule_tasks_imp
self._task_queues.jobs.add(task)
File "/usr/lib64/portage/pym/_emerge/SequentialTaskQueue.py", line 23,
in add
self.schedule()
File "/usr/lib64/portage/pym/_emerge/SequentialTaskQueue.py", line 45,
in schedule
task.start()
File "/usr/lib64/portage/pym/_emerge/AsynchronousTask.py", line 30, in
start
self._start()
File "/usr/lib64/portage/pym/_emerge/MergeListItem.py", line 93, in _start
self._start_task(build, self._default_final_exit)
File "/usr/lib64/portage/pym/_emerge/CompositeTask.py", line 151, in
_start_task
task.start()
File "/usr/lib64/portage/pym/_emerge/AsynchronousTask.py", line 30, in
start
self._start()
File "/usr/lib64/portage/pym/_emerge/EbuildBuild.py", line 89, in _start
self._prefetch_exit(prefetcher)
File "/usr/lib64/portage/pym/_emerge/EbuildBuild.py", line 145, in
_prefetch_exit
self._build_dir.lock()
File "/usr/lib64/portage/pym/_emerge/EbuildBuildDir.py", line 60, in lock
self._assert_lock(builddir_lock)
File "/usr/lib64/portage/pym/_emerge/EbuildBuildDir.py", line 71, in
_assert_lock
% (async_lock.returncode,))
AssertionError: AsynchronousLock failed with returncode 1
root@fireball / #
This is another attempt with -j1 hoping to see what stops it since that
makes it show the process:
root@fireball / # emerge -uvaDN world -j1
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-auth/consolekit-0.4.6 [0.4.5_p20120320-r1] USE="pam
(policykit) -acl -debug -doc (-selinux) {-test}" 0 kB
Total: 1 package (1 upgrade), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-auth/consolekit-0.4.6
And it sits there. No attempt to configure or anything, just sits there.
What the heck is going on? It did all the other updates just fine.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] Question re: make.conf/profile location change
On 2013-08-11 1:06 PM, Marc Joliet wrote: Yes, I agree that that might perhaps have been nice to mention it in the news item (although IMHO that's the sort of information the man pages are there for), but it *is* crystal clear in the docs, or do you not count the man pages to the docs? Ok, you're right... :) AFAIK eselect profile uses the new location, but I don't remember how precisely I moved it (not that it matters). I just tried changing it eselect profile set 3 eselect profile set 1 and it didn't create the link in /etc/portage, it is still in /etc... Not sure why the two preceeding dots are there in the current one in /etc, but they are... The current location is /etc/make.conf, right? Then ../usr/[...] will resolve to /usr/[...], whereas your ln command above will resolve to /etc/usr/[...], which is, erm, wrong :) . So, to do this manually just: ~ ln -s make.profile /usr/portage/profiles/default/linux/amd64/13.0 ~ rm /etc/make.profile ?
Re: [gentoo-user] sys-auth/consolekit-0.4.6 just sits there.
On 11/08/13 20:12, Dale wrote: I notice this starts but never does anything. I end up doing a ctrl c to stop it. I tried with two different versions of portage so I don't think it is portage itself. But it is. It's either Portage, or Python it's using itself. But it's not about sys-auth/consolekit for sure. I would grab that output and show it to people at #gentoo-portage in Freenode IRC for clue.
Re: [gentoo-user] Question re: make.conf/profile location change
Am Sun, 11 Aug 2013 13:30:57 -0400 schrieb Tanstaafl : > On 2013-08-11 1:06 PM, Marc Joliet wrote: > > Yes, I agree that that might perhaps have been nice to mention it in the > > news > > item (although IMHO that's the sort of information the man pages are there > > for), but it *is* crystal clear in the docs, or do you not count the man > > pages > > to the docs? > > Ok, you're right... :) > > > AFAIK eselect profile uses the new location, but I don't remember how > > precisely > > I moved it (not that it matters). > > I just tried changing it > > eselect profile set 3 > eselect profile set 1 > > and it didn't create the link in /etc/portage, it is still in /etc... Ah, then it *preserves* the current location. I have it in /etc/portage and eselect profile kept it there, too. However, I just checked and if you delete make.profile and then re-create it with eselect profile it is created in /etc/portage. > >> Not sure why the two preceeding dots are there in the current one in > >> /etc, but they are... > > > > The current location is /etc/make.conf, right? Then ../usr/[...] will > > resolve > > to /usr/[...], whereas your ln command above will resolve to /etc/usr/[...], > > which is, erm, wrong :) . > > So, to do this manually just: > > ~ ln -s make.profile /usr/portage/profiles/default/linux/amd64/13.0 > > ~ rm /etc/make.profile > > ? I guess so. Or "rm /etc/make.profile && eselect profile set " as described above. HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Moving from old udev to eudev
On Sun, 11 Aug 2013 11:52:26 -0400, Tanstaafl wrote: > > but the issue here was eudev *not* being updated when the virtual > > was, and both cause and result were quite clear. > > Right, but I was talking about not updating *anything* related to any > mission critical apps, and that would include the virtual/udev as well. > > That said - shouldn't this be taken care of by the the virtual/udev > package itself? Shoudln't it keep track of what versions of udev *and* > eudev it supports, and warn you (via a [B]blocker)? There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. -- Neil Bothwick The present never ages. Each moment is like a snowflake, unique, unspoiled, unrepeatable, and can be appreciated in its surprisingness. signature.asc Description: PGP signature
Re: [gentoo-user] Moving from old udev to eudev
On 11/08/13 21:13, Neil Bothwick wrote: On Sun, 11 Aug 2013 11:52:26 -0400, Tanstaafl wrote: but the issue here was eudev *not* being updated when the virtual was, and both cause and result were quite clear. Right, but I was talking about not updating *anything* related to any mission critical apps, and that would include the virtual/udev as well. That said - shouldn't this be taken care of by the the virtual/udev package itself? Shoudln't it keep track of what versions of udev *and* eudev it supports, and warn you (via a [B]blocker)? There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. I believe it's 'b' if user doesn't have sys-fs/eudev in /var/lib/portage/world, but 'B' if he does As in, difference is soft and hard blocker depending if the wanted implementation is recorded in the world file or not
Re: [gentoo-user] Question re: make.conf/profile location change
On 11/08/2013 18:48, Tanstaafl wrote: > On 2013-08-11 12:03 PM, Marc Joliet wrote: >> When in doubt, read the man page (make.conf(5)): >> >> "[...] >> DESCRIPTION >> This file contains various variables that are used by >> Portage. Portage will check >> the currently-defined environment variables first for any >> settings. If no environ‐ >> ment settings are found, Portage then checks the >> make.conf files. Both >> /etc/make.conf and /etc/portage/make.conf are checked (if >> present), and settings >> from /etc/portage/make.conf will override settings from >> /etc/make.conf. [...]" > > Thanks... my point was more that the news item didn't explain this - > also, this answers as to make.conf, but what about make.profile? > > I just don't like being forced to assume, or 'test for myself', when it > could be made crystal clear in the news item/docs. > > Also, would > > ~ cd /etc/portage > ~ ln -s make.profile ../usr/portage/profiles/default/linux/amd64/13.0 No. That links a file in /etc/portage to something that doesn't exist (arguments wrong way round), and the .. parent directory doesn't belong there at all: cd /etc/portage ln -s $POSTDIR/profiles/path/to/profile/you/want profile.conf > > Be the right way to create the make.profile symlink in the new location? > > Not sure why the two preceeding dots are there in the current one in > /etc, but they are... > > On 2013-08-11 12:16 PM, Alan McKinnon wrote: >> My question is why do you have files in both locations? > > I don't... I was getting ready to change these, and was just asking the > question... ;) new overrides old in this case -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] about LIBRARY_PATH
It seems that this variable is hard-code by gcc.I cannot change it any more.When I use gcc -m32 to compile a 32bit program,gcc is looking for /usr/lib rather than /usr/lib32.But in my system,/usr/lib is a symlink to /usr/lib64.The real 32bit librarys is in /usr/lib32.The linker is always complaining about "i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-pc-linux-gnux32/4.7.3/../../../../lib/crt1.o' is incompatible with i386 output.".Why does it not search /usr/lib32?
Re: [gentoo-user] about LIBRARY_PATH
I thought LD_LIBRARY_PATH was old skool and now ppl use ldconfig, so man ldconfig.
Re: [gentoo-user] about LIBRARY_PATH
LIBRARY_PATH is not LD_LIBRARY_PATH. 2013/8/12 Adam Carter > I thought LD_LIBRARY_PATH was old skool and now ppl use ldconfig, so man > ldconfig. >
Re: [gentoo-user] about LIBRARY_PATH
2013/8/12 东方巽雷 : > It seems that this variable is hard-code by gcc.I cannot change it any > more.When I use gcc -m32 to compile a 32bit program,gcc is looking for > /usr/lib rather than /usr/lib32.But in my system,/usr/lib is a symlink to > /usr/lib64.The real 32bit librarys is in /usr/lib32.The linker is always > complaining about "i386:x86-64 architecture of input file > `/usr/lib/gcc/x86_64-pc-linux-gnux32/4.7.3/../../../../lib/crt1.o' is > incompatible with i386 output.".Why does it not search /usr/lib32? Well, you can always emerge crossdev and crossdev i686-pc-linux-gnu then... (-: PS: A quick check on my system shows this: # [08/12 13:27:52] xenon@ribosome ~ $ gcc -m32 -v --version 2>&1 | grep LIBRARY_PATH LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../:/lib/:/usr/lib/ # [08/12 13:28:00] xenon@ribosome ~ $ gcc -v --version 2>&1 | grep LIBRARY_PATH LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../:/lib/:/usr/lib/ So the lib32 paths are actually included in the library search path, and correctly placed *before* the lib counterparts. I'm not sure how your toolchain ends up in the state you described, but it's certainly weird... Can you please provide the output of "emerge --info" and "gcc -v --version"? This way people will have more clue to help you...
