LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   How to use 32 bit C libraries on 64 bit Arch Linux (https://www.linuxquestions.org/questions/programming-9/how-to-use-32-bit-c-libraries-on-64-bit-arch-linux-801349/)

MTK358 04-11-2010 09:15 AM

How to use 32 bit C libraries on 64 bit Arch Linux
 
Just what it says in the title.

I can work in a 32-bit VirtualBox VM, but it's very inconvenient and I would rather work in my 64-bit desktop if that's not too difficult.

These are all the lib32 packages I have installed:

Code:

$ pacman -Qs lib32
local/lib32-gcc-libs 4.4.3-2 (lib32)
    The GNU Compiler Collection
local/lib32-glibc 2.11.1-1.3 (lib32)
    GNU C Library (32 Bit)


kbp 04-11-2010 09:24 AM

There's no reason your your 32bit code shouldn't run on a 64bit platform, as long as all your library dependencies are present. Also, depending on what you're doing, you may not actually need the std c libs at all ...

cheers

MTK358 04-11-2010 09:25 AM

I am using some standard C functions.

Anyway, this is what happens:

Code:

$ nasm -f elf32 main.asm
$ gcc -m32 main.o
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a when searching for -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status


johnsfine 04-11-2010 09:47 AM

Poor choice of thread title. Should have been
How to use 32 bit C libraries on 64 bit Arch Linux

You don't want to attract experts who know about asm. That doesn't matter. You want experts who know about multi lib in Arch. I know about multi lib in Mepis, Ubuntu and Centos.

So far you have determined that gcc can't find the right copy of libgcc.a

The obvious next question is whether the right copy of libgcc.a is installed on your computer.

If it is, you move on to the question of why gcc can't find it. If it isn't, you move on to the question of what package includes it.

For whether it is installed at all, you might try a find command to see all copies of libgcc.a on your hard drive.

If you knew the multi lib rules of Arch better, you could look for it exactly where it is supposed to be. In the gcc multi lib rules of Centos, once we know that the 64 bit version is
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a
that tells us the 32 bit version would be
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/32/libgcc.a

Does that file happen to exist?

MTK358 04-11-2010 09:53 AM

Looks like I don't have the file.

Code:

$ sudo find / -name 'libgcc.a'
Password:
/usr/lib/gcc/avr/4.4.3/avr25/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr51/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr5/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr31/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr4/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr6/libgcc.a
/usr/lib/gcc/avr/4.4.3/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr35/libgcc.a
/usr/lib/gcc/avr/4.4.3/avr3/libgcc.a
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/libgcc.a

And should I really just rename this thread (I just really don't understand this 32/64-bit stuff and don't even know where to start)?

johnsfine 04-11-2010 10:05 AM

Quote:

Originally Posted by MTK358 (Post 3931726)
Looks like I don't have the file.

And should I really just rename this thread

I think so. Do you know how to? (Advanced button while in Edit on your first post of the thread).

Quote:

(I just really don't understand this 32/64-bit stuff and don't even know where to start)?
I don't know Arch and I don't know pacman.

For similar problems in Centos, I would use the command
yum provides "*gcclib.a*"
That lists every available package that contains any file with gcclib.a as part of its name as well as listing the full path and name of the file.

Then I would look through those many choices and apply some common sense to figure out which was right.

But this time in Centos it was too easy, because in each case the 32 bit libgcc.a is included in the same package with the 64 bit one. So I couldn't have gotten into this problem with libgcc.a in Centos.

Apparently Arch packages or installs gcc differently, or did you build your own gcc4.4.3 from source and make a decision during config to leave out the 32 libraries?

MTK358 04-11-2010 10:18 AM

Code:

$ pacman -hS
usage:  pacman {-S --sync} [options] [package(s)]
options:
      --asdeps        install packages as non-explicitly installed
      --asexplicit    install packages as explicitly installed
  -c, --clean          remove old packages from cache directory (-cc for all)
  -d, --nodeps        skip dependency checks
  -f, --force          force install, overwrite conflicting files
  -g, --groups        view all members of a package group
  -i, --info          view package information
  -l, --list <repo>    view a list of packages in a repo
  -p, --print-uris    print out URIs for given packages and their dependencies
  -s, --search <regex> search remote repositories for matching strings
  -u, --sysupgrade    upgrade installed packages (-uu allows downgrade)
  -w, --downloadonly  download packages but do not install/upgrade anything
  -y, --refresh        download fresh package databases from the server
      --needed        don't reinstall up to date packages
      --ignore <pkg>  ignore a package upgrade (can be used more than once)
      --ignoregroup <grp>
                      ignore a group upgrade (can be used more than once)
  -q, --quiet          show less information for query and search
      --config <path>  set an alternate configuration file
      --logfile <path> set an alternate log file
      --noconfirm      do not ask for any confirmation
      --noprogressbar  do not show a progress bar when downloading files
      --noscriptlet    do not execute the install scriptlet if one exists
  -v, --verbose        be verbose
      --debug          display debug messages
  -r, --root <path>    set an alternate installation root
  -b, --dbpath <path>  set an alternate database location
      --cachedir <dir> set an alternate package cache location

Doesn't look like it lets me find a package containing a certain file, but maybe it's possible.

johnsfine 04-11-2010 11:00 AM

I did a quick google of Arch Linux gcc multilib and found this thread:
http://aur.archlinux.org/packages.php?ID=28545

But I don't know enough about Arch to know if your answer is there.

MTK358 04-11-2010 11:03 AM

I really don't understand that.

johnsfine 04-11-2010 11:33 AM

I poked around a bit more online info on Arch and I realize that while you don't have a 32 bit libgcc.a installed, you do have a 32 bit libgcc_s.so installed.

Instead of
gcc -m32 main.o
try
gcc -m32 -shared-libgcc main.o

I think that tells gcc to use libgcc_s.so instead of libgcc.a

(I'm starting to hate Arch without ever having used it. But that isn't enough to prevent solving the problem.)

Edit: alternately a whole different approach leaps to mind: You already have this stuff working in a VM right? That's just inconvenient to continue using. What version of what OS and what version of gcc did you install in your 32 bit VM? If you happened to choose a similar version of Arch and same version of gcc (but 32 bit builds of each). I think you can copy files such as the 32 bit libgcc.a out of the VM and into appropriate '32' or 'lib32' subdirectories in the main system.

damgar 04-11-2010 11:50 AM

Adjusting the flags got me past a very similar issue in multilib slackware yesterday.

http://www.linuxquestions.org/questi...ltilib-801222/

MTK358 04-11-2010 01:11 PM

The VM runs 32-bit Arch Linux.

Code:

$ gcc -m32 -shared-libgcc main.o
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status


Sergei Steshenko 04-11-2010 01:40 PM

Quote:

Originally Posted by MTK358 (Post 3931908)
The VM runs 32-bit Arch Linux.

Code:

$ gcc -m32 -shared-libgcc main.o
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status



Possibly not - "x86_64" might well indicate 64 bits OS.

Try something like this:

Code:

file install/gtk+-2.16.6/lib/libgailutil.so.18.0.1
install/gtk+-2.16.6/lib/libgailutil.so.18.0.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

.


I.e. make explicitly sure you are not running 64 bits stuff.

johnsfine 04-11-2010 01:51 PM

Quote:

Originally Posted by Sergei Steshenko (Post 3931937)
Possibly not - "x86_64" might well indicate 64 bits OS.

Yes, MTK358 knows the main system he is asking about is X86_64. What he said about the VM was in response to a side suggestion I made for a weird work around for the problem that I don't know the normal solution for in Arch (this stuff is so easy in Centos, Mepis and Ubuntu).

Quote:

Originally Posted by MTK358 (Post 3931908)
Code:

$ gcc -m32 -shared-libgcc main.o
...
/usr/bin/ld: cannot find -lgcc_s


My not knowing my way around Arch is continuing to get in the way.

Pursuing that path a little, first make sure I'm right that you really have a 32 bit libgcc_s.so somewhere. You know how to find all the libgcc_s.so files on your system. If unsure about one, you can use the file command to see if it is elf32.

On my Mepis system I just did this (note the backtick character is different from a single quote character)
Code:

file `find / -name "libgcc_s.so*"`
/emul/ia32-linux/usr/lib/libgcc_s.so.1:          ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib/gcc/x86_64-linux-gnu/4.3/32/libgcc_s.so: symbolic link to `/emul/ia32-linux/usr/lib/libgcc_s.so.1'
/usr/lib/gcc/x86_64-linux-gnu/4.3/libgcc_s.so:    symbolic link to `/lib/libgcc_s.so.1'
/usr/lib/gcc/x86_64-linux-gnu/4.1/libgcc_s.so:    symbolic link to `/lib/libgcc_s.so.1'
/lib/libgcc_s.so.1:                              ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

From the output, I can see that the libgcc_s.so in
/usr/lib/gcc/x86_64-linux-gnu/4.3/32/
is a symbolic link to a libgcc_s.so.1 which is elf32. So the directory I want gcc to look in is
/usr/lib/gcc/x86_64-linux-gnu/4.3/32

GCC knows to look there on its own when I do gcc -m32 on this system. But if gcc didn't know that I could force it
Code:

gcc -m32 -L/usr/lib/gcc/x86_64-linux-gnu/4.3/32/ -shared-libgcc main.o

damgar 04-11-2010 01:59 PM

While this is not specific to your problem or Arch for that matter, it might be a good read. It has some scripts for changing your shell environment to prefer 32 compilers over 64 bit compilers in a multilib system that might be helpful. There are also some links to further reading that might be helpful.

http://alien.slackbook.org/dokuwiki/...kware:multilib


All times are GMT -5. The time now is 08:36 PM.