Does the work program receive an "Invalid instruction" error on a "clean machine"?

Question

I have a program that works correctly on my development machine, but causes an illegal command error when testing on a "clean machine" where only the necessary files were copied.

The program consists of my shared library built from C ++ sources and an example C wrapper program that demonstrates the use of libraries. On the development machine, they are all built in Eclipse w / g ++, and both Debug and Release work fine. A number of standard libraries are linked.

To check the dependencies that I might have missed, I copied the .c file, the .so file, and the .h library file for a new Linux installation and compiled / linked them to a simple script created with the same release compilation options that Eclipse uses. Both machines have g ++ 4.3.2.

When I run the program on a clean machine, it exited immediately after printing "Illegal Instruction".

Running in gdb calls:

(gdb) run Starting program: /home/sfallows/Source/Apps/MySample/MySample [Thread debugging using libthread_db enabled] [New Thread 0xb5c4ca90 (LWP 7063)] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0xb5c4ca90 (LWP 7063)] 0xb7f0cb29 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/4.3/iostream:77 77 static ios_base::Init __ioinit; Current language: auto; currently c++ (gdb) bt #0 0xb7f0cb29 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/4.3/iostream:77 #1 0xb7f0cb48 in global constructors keyed to _ZN8NodeLockC2Ev () at ../NodeLock.cpp:194 #2 0xb7f204ad in __do_global_ctors_aux () from /home/sfallows/Source/Apps/MySample/libMyLib.so #3 0xb7ee5c80 in _init () from /home/sfallows/Source/Apps/MySample/libMyLib.so #4 0xb7fe1de4 in ?? () from /lib/ld-linux.so.2 #5 0x00000001 in ?? () #6 0xbf8e6b74 in ?? () #7 0xbf8e6b7c in ?? () #8 0x00000007 in ?? () #9 0xbf8e6b2c in ?? () #10 0x00000001 in ?? () #11 0x00000001 in ?? () #12 0xb7feeff4 in ?? () from /lib/ld-linux.so.2 #13 0x00000000 in ?? () (gdb) Quit 

I'm not sure why static constructors are running in NodeLock.cpp. I have neither static / global objects in this file, nor any static / global objects of this class anywhere.

The development machine is the Intel Core2 Quad and the clean machine is the Pentium 4 Dual. I believe that g ++ uses a common subset of x86 instructions by default and that the difference in processor is not my problem.

Any suggestions on what else to look at for an estimate. I try to avoid installing all library sources and dependencies on a clean machine.

Reply to rmn and John Bocker's comment: In the Windows world, exes and dll run on a variety of Intel and AMD processors, so a common subset of instructions is obviously widely used. I thought gcc would do the same? I suppose I'll fully explore the command set / architecture options.

Answer 1

You can try to compile explicitly for the i686 architecture (using the -march=i686 option for gcc). Just in case, you have some Core2 instructions created by your compiler ...

Answer 2

Quote: “The development machine is the Intel Core2 Quad and the clean machine is the Pentium 4 Dual. I assume that g ++ uses the general subset of x86 instructions by default and that the difference in the processor is not my problem.”

I really think this is a problem. Try either to compile specifically for this machine, or recompile it to a clean machine, or get two identical machines. - This is my $ 0.02.

Also, it looks like you are dying from loading ld-linux.so. Perhaps Linux versions are different?

Answer 3

I can think of a few things you can try:

• Do you use any kind of optimization outside of -O3? Perhaps the old system does not support it.
• You may have already tested this, but have you checked the md5 binary of your system and the target system?
• Does your library do multithreading? If so, since the # cores are different, then maybe you have a race condition somewhere

Answer 4

you die with static initialization. The order that everything is done is implementation specific and may vary depending on the version of the execution. This may be your problem. Is it the same libstdc ++ on both machines?

It has poor cross-dependencies anyway, you need to update the code if this turns out to be a problem