On 10/09/2014 06:01, Kerin Millar wrote:
On 10/09/2014 05:16, Joseph wrote:
On 09/10/14 04:57, Kerin Millar wrote:
On 10/09/2014 04:50, Joseph wrote:
On 09/10/14 04:27, Kerin Millar wrote:
On 10/09/2014 04:21, Joseph wrote:
On 09/10/14 03:59, Kerin Millar wrote:
On 09/09/2014 19:36, Joseph wrote:
[snip]


Running on my other system I get:
equery b libstdc++.so.6
* Searching for libstdc++.so.6 ... sys-devel/gcc-4.5.4
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/libstdc++.so.6 ->
libstdc++.so.6.0.14)

env-update - doesn't work either


Check beneath /etc/env.d/ld.so.conf.d and ensure that there is a
file
defining the appropriate paths for your current version of gcc.
Here's
how it looks on my system:

  # cd /etc/ld.so.conf.d
  # ls
  05binutils.conf  05gcc-x86_64-pc-linux-gnu.conf
  # cat 05gcc-x86_64-pc-linux-gnu.conf
  /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/32
  /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3

Once you have made any necessary changes, run ldconfig.

--Kerin

Thanks Kerin, for the pointer.
I think I have a bigger problem, and don't know how to fix it.

Yes, I have the same file /etc/ld.so.conf.d
# ls # 05gcc-x86_64-pc-linux-gnu.conf
# cat /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/32
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3

However, those directories are empty (only one file):
# ls -al /usr/lib/
libbrcomplpr2.so

Is /usr/lib an actual directory or a symlink? Assuming that you use a
stock amd64 (multilib) profile, it should be a symlink to lib64. If
you
find that it is a directory and that you also have a lib64 directory,
try the commands below. You can skip the busybox and exit commands if
you are doing this in a chroot rather than on a live system.

  # busybox sh
  # cd /usr/
  # mv lib lib.old
  # ln -s lib64 lib
  # exit

On my other working system this directory "/usr/lib/" contain about
2020
files.
What had happened?
After emerging some files and system I was running command: fstrim
-v /
(as the disk is SSD).
Could it have something to do with the fact that these directories
are
empty?

No. Using fstrim does not delete files.

--Kerin

Kerin you are a magician! THANK YOU!!!
Yes, it worked.  Everything is back to normal.

I can still not comprehend what had happened :-/ why all of a sudden in
the middle of compilation it all vanished.

Were you doing anything outside of portage that may have had a hand in
it?

Incidentally, you should move libbrcomplpr2.so to /usr/lib32. Some
googling suggests to me that it is a library included in a proprietary
Brother printer driver package. You can use the file command to confirm
that it is a 32-bit library.

--Kerin

I was logged in over ssh in one terminal, compiling "xsane"
and logged in, in another terminal and was installing brother printer
driver (without emerge) manual installation.
I followed my own instructions from:
http://forums.gentoo.org/viewtopic-t-909052-highlight-brother.html?sid=1ba0b92db499262c6a74919d86c6af43



I run: tar zxvf ./hl5370dwlpr-2.0.3-1.i386.tar.gz -C / tar zxvf
./cupswrapperHL5370DW-2.0.4-1.i386.tar.gz -C /
Could be that one of this script messed up the links.
If so I don't know how could it happen. Looking though "history" these
are the commands I run:

305  tar zxvf ./brhl5250dnlpr-2.0.1-1.i386.tar.gz -C /
  306  tar zxvf ./cupswrapperHL5250DN-2.0.1-1.i386.tar.gz -C /
  307  cd /usr/local/Brother/cupswrapper
  308  mv cupswrapperHL5250DN-2.0.1 cupswrapperHL5250DN-2.0.1.bak
  309  /bin/sed 's/\/etc\/init.d\/cups\ restart/\/etc\/init.d\/cupsd\
restart/g' ./cupswrapperHL5250DN-2.0.1.bak > ./cupswrapperHL5250DN-2.0.1
  310  ls -al
  311  pwd
  312  ll
  313  ls -al
  314  chmod 755 cupswrapperHL5250DN-2.0.1

I just extracted the files with "tar..."

I read your forum post and can see that you're (dangerously) extracting
directly into the root directory and that this is among the contents of
the archive:

   ./usr/lib/
   ./usr/lib/libbrcomplpr2.so

I posit that tar clobbers the /usr/lib symlink, converting it into a
directory because that is what is stored in the archive.

Ergo, use the --keep-directory-symlink parameter.

Excuse the fact that I am replying to myself, but I must also stress that the library does not belong in lib64. On a 64-bit system, you should adapt your process so that the library ends up residing in lib32, not lib64 (by way of the lib symlink). The software will not be able to function correctly otherwise.

--Kerin

Reply via email to