Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 437
  • Last Modified:

linking an application built with -m32 flag

Hi,

I'm building an application on RedHat Enterprise 3 for x86-64.  I'm running the 64 bit kernel and compilers, but right now I need to build a 32 bit app.  I added the -m32 flag to my make files and it sure looks like 32 bit code is being generated.  However, when it comes time to link in the library I'm told that it's not compatible.  I figure I'm either missing a flag for ar or for ld.  I don't really know what to pass them and the man pages are so huge I figured it would be faster just to ask someone.

Here is a brief transcript of my problem:

[bottiger@rubicant ipm]$ make
g++ -D_DEBUG -DLINUX -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DRTI_USES_STD_FSTREAM -D__linux__  -Wno-deprecated -m32 -O -Dlinux \
-I/opt/itt/ipm/src/include  \
-L/opt/itt/ipm/lib/linux  \
 \
  \
-c ipm.cpp -o linux/ipm.o
ar -rc  /opt/itt/ipm/lib/linux/libipm.a linux/ipm.o

At this point, it is my understanding that the 32 bit library has been built, and that I shoud be able to build my app with the -m32 flag and statically link it.

[bottiger@rubicant example]$ make
cd client; make
make[1]: Entering directory `/home/bottiger/development/ipm/dev4/src/example/client'
echo in the .o maker
in the .o maker
g++ -I/opt/itt/ipm/src/include -Dlinux -O -exceptions -D_DEBUG -DLINUX -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DRTI_USES_STD_FSTREAM -D__linux__  -Wno-deprecated -m32 \
-I/opt/itt/ipm/src/include  \
-c client.cpp -o linux/client.o
g++ \
linux/client.o \
 \
 -L/opt/itt/ipm/lib/linux \
 -lm -lipm \
-o /opt/itt/ipm/bin/linux/client
/usr/bin/ld: skipping incompatible /opt/itt/ipm/lib/linux/libipm.a when searching for -lipm
/usr/bin/ld: cannot find -lipm
collect2: ld returned 1 exit status
make[1]: *** [/opt/itt/ipm/bin/linux/client] Error 1
make[1]: Leaving directory `/home/bottiger/development/ipm/dev4/src/example/client'
make: *** [CLIENT] Error 2

I'm betting my problem is with ar, but I'm a total novice with it, so I'm pretty well stuck.
0
sleepylight
Asked:
sleepylight
  • 3
  • 2
1 Solution
 
ahoffmannCommented:
> I'm betting my problem is with ar,
ar is a simple program which concatenates the given files to a new one

you're building a dynamic shared object with g++, so you better give the full path to your static librrary instead of -lipm
0
 
ahoffmannCommented:
oops missed to say that you need to use 32-bit versions of all other libs also
0
 
Duncan RoeSoftware DeveloperCommented:
Can you simply load ipm.o instead of the library?
At the very least, all modules in libipm.a have to be -m32.
Also, it may be necessary to use a 32-bit ar to build libipm.a
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
ahoffmannCommented:
At the very least, all modules used in client.ohave to be -m32 too!
0
 
Duncan RoeSoftware DeveloperCommented:
This one has me curious. Since I have a 64 bit system, experiment:

08:55:45$ cat tiger.c
#include <stdio.h>
int main()
{
  printf("Hi there Tiger\n");
  return 0;
}

08:56:20$ gcc -Wall -o hi tiger.c
08:56:23$ file hi
hi: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

No surprises there

08:56:29$ gcc -m32 -Wall -o hi tiger.c
08:56:39$ file hi
hi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Fine, 32-bit programs build OK. After some editing:

09:00:49$ cat tiger.c
#include <stdio.h>
void pussy(void);
int main()
{
  printf("Hi there Tiger\n");
  pussy();
  return 0;
}

09:03:52$ cat pussy.c
#include <stdio.h>
void pussy(void);
void pussy()
{
  printf("What's new pussycat?\n");
}

09:06:59$ gcc -m32 -Wall -o hi tiger.c pussy.c
09:07:04$ file hi
hi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
09:07:08$ ./hi
Hi there Tiger
What's new pussycat?
09:07:11$

Try putting pussy.o in a library:

09:07:11$ gcc -m32 -Wall -c pussy.c
09:08:31$ file pussy.o
pussy.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
09:08:36$ ar -rc libipm.a pussy.o
09:11:00$ file libipm.a
libipm.a: current ar archive
09:11:07$ gcc -m32 -Wall -o hi tiger.c -L. -lipm
09:11:44$ file hi
hi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

No worries!

So, building a libipm.a from scratch with all 32-bit modules works fine. That is what you have to do.
0
 
sleepylightAuthor Commented:
Yeah, it looks like I didn't have the -m32 flag enabled in the linking stage.  I changed the make file and everything worked fine.  Totally not an ar problem.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now