File not executable

[Howard West]

I am working on a box installed with SCO OpenServer 5.0.2 and gcc
2.95.2 from the Skunkware CDs.

I was previously having trouble getting my files built because of a
missing assembler, but that problem has been corrected due to
information helpfully provided by this group.

I am now able to build my projects, but I cannot run them. The system
returns the message "cannot execute" when I attempt to run it from the
command line.

When I attempt to load it into gdb (GDB 4.16
(i586-unknown-sco3.2v5.0.2)), I get the message:

"/u/bmc/users/hwest/agent_code/PROJECTS/Unix/exe/SCO-3/p_ctscs": not
in executab
le format: File format not recognized

It occurs to me that this might have something to do with file format
differences (COFF vs ELF) but I have no hard evidence, only suspicion.
I've tried passing the switch "-mcoff" to gcc to force COFF output,
but from when I can see by dumping the output files, they are still
being generated in ELF format.

Can anyone suggest a possible approach to resolving this or even a
possibly fruitful line of inquiry I might pursue in figuring this out?

[Jean-Pierre Radley]

Howard West typed (on Wed, Jun 23, 2004 at 01:42:07PM -0700):
| I am working on a box installed with SCO OpenServer 5.0.2 and gcc
| 2.95.2 from the Skunkware CDs.
|
| I was previously having trouble getting my files built because of a
| missing assembler, but that problem has been corrected due to
| information helpfully provided by this group.
|
| I am now able to build my projects, but I cannot run them. The system
| returns the message "cannot execute" when I attempt to run it from the
| command line.
|
| When I attempt to load it into gdb (GDB 4.16
| (i586-unknown-sco3.2v5.0.2)), I get the message:
|
| "/u/bmc/users/hwest/agent_code/PROJECTS/Unix/exe/SCO-3/p_ctscs": not
| in executab
| le format: File format not recognized
|
| It occurs to me that this might have something to do with file format
| differences (COFF vs ELF) but I have no hard evidence, only suspicion.
| I've tried passing the switch "-mcoff" to gcc to force COFF output,
| but from when I can see by dumping the output files, they are still
| being generated in ELF format.
|
| Can anyone suggest a possible approach to resolving this or even a
| possibly fruitful line of inquiry I might pursue in figuring this out?

What does the 'file' command disclose?

[Howard West]

Post by Jean-Pierre Radley
| I am working on a box installed with SCO OpenServer 5.0.2 and gcc
| 2.95.2 from the Skunkware CDs.
|
| I was previously having trouble getting my files built because of a
| missing assembler, but that problem has been corrected due to
| information helpfully provided by this group.
|
| I am now able to build my projects, but I cannot run them. The system
| returns the message "cannot execute" when I attempt to run it from the
| command line.
|
| When I attempt to load it into gdb (GDB 4.16
|
| "/u/bmc/users/hwest/agent_code/PROJECTS/Unix/exe/SCO-3/p_ctscs": not
| in executab
| le format: File format not recognized
|
| It occurs to me that this might have something to do with file format
| differences (COFF vs ELF) but I have no hard evidence, only suspicion.
| I've tried passing the switch "-mcoff" to gcc to force COFF output,
| but from when I can see by dumping the output files, they are still
| being generated in ELF format.
|
| Can anyone suggest a possible approach to resolving this or even a
| possibly fruitful line of inquiry I might pursue in figuring this out?
What does the 'file' command disclose?

p_ctscs: ELF 32-bit LSB dynamic lib 80386

[J. L. Schilling]

Post by Howard West

Post by Jean-Pierre Radley
| I am working on a box installed with SCO OpenServer 5.0.2 and gcc
| 2.95.2 from the Skunkware CDs. [...]
|
| I am now able to build my projects, but I cannot run them. The system
| returns the message "cannot execute" when I attempt to run it from the
| command line.

p_ctscs: ELF 32-bit LSB dynamic lib 80386

Try a simple sanity check, like this:

232$ cat hello.c
#include <stdio.h>

int main()
{
printf("Hello, I must be going\n");
}
233$ /usr/local/bin/gcc -v
Reading specs from /usr/local/lib/gcc-lib/i386-pc-sco3.2v5.0.5/2.95.2/specs
gcc version 2.95.2 19991024 (release)
234$ /usr/local/bin/gcc hello.c
235$ file a.out
a.out: ELF 32-bit LSB executable 80386
236$ ./a.out
Hello, I must be going

If you try this, what do you get?

Jonathan Schilling

[Howard West]

Post by Howard West

Post by Jean-Pierre Radley
| I am working on a box installed with SCO OpenServer 5.0.2 and gcc
| 2.95.2 from the Skunkware CDs.
|
| I was previously having trouble getting my files built because of a
| missing assembler, but that problem has been corrected due to
| information helpfully provided by this group.
|
| I am now able to build my projects, but I cannot run them. The system
| returns the message "cannot execute" when I attempt to run it from the
| command line.
|
| When I attempt to load it into gdb (GDB 4.16
|
| "/u/bmc/users/hwest/agent_code/PROJECTS/Unix/exe/SCO-3/p_ctscs": not
| in executab
| le format: File format not recognized
|
| It occurs to me that this might have something to do with file format
| differences (COFF vs ELF) but I have no hard evidence, only suspicion.
| I've tried passing the switch "-mcoff" to gcc to force COFF output,
| but from when I can see by dumping the output files, they are still
| being generated in ELF format.
|
| Can anyone suggest a possible approach to resolving this or even a
| possibly fruitful line of inquiry I might pursue in figuring this out?
What does the 'file' command disclose?

p_ctscs: ELF 32-bit LSB dynamic lib 80386

It actually looks like the ELF/COFF thing is a red herring. I am able
to run several other programs that are built at the same time. They
all report the same file format (ELF 32-bit LSB dynamic lib 80386), so
there must be something else wrong with the way I'm building them.

This brings me back to the debugger issue though. Yesterday I
downloaded the source code to gdb 4.16 and GNU binutils-2.8.1 from the
OSR5 section of the skunkware directories on the SCO ftp site and
built them with the GCC 2.95.2 compiler that had been installed on
this machine by our client.

I can build a trivial "hello, world" program that reports itself to be
ELF and runs without a problem, but when I try to load it into gdb
(I've compiled it with -g to include debug information), I get the
same errors about "not in executable format" and "file format not
recognized". Is this an ELF vs. COFF issue?

Why can't it understand the executables generated by gcc?

[J. L. Schilling]

Post by Howard West
It actually looks like the ELF/COFF thing is a red herring. I am able
to run several other programs that are built at the same time. They
all report the same file format (ELF 32-bit LSB dynamic lib 80386), so
there must be something else wrong with the way I'm building them.

Try the command "/bin/dump -Lv" on the executable that's giving the
trouble. Are there any NEEDED entries to .so libraries in your
application? If so, run the "file" command on them and see what
that shows.

Post by Howard West
This brings me back to the debugger issue though. Yesterday I
downloaded the source code to gdb 4.16 and GNU binutils-2.8.1 from the
OSR5 section of the skunkware directories on the SCO ftp site and
built them with the GCC 2.95.2 compiler that had been installed on
this machine by our client.
I can build a trivial "hello, world" program that reports itself to be
ELF and runs without a problem, but when I try to load it into gdb
(I've compiled it with -g to include debug information), I get the
same errors about "not in executable format" and "file format not
recognized". Is this an ELF vs. COFF issue?
Why can't it understand the executables generated by gcc?

Don't know ... on an OSR 5.0.6 system here, gcc 2.95.2 works fine
with gdb 5.3. Your OS and gdb versions are much older, however ...

Jonathan Schilling

[Jean-Pierre Radley]

J. L. Schilling typed (on Thu, Jun 24, 2004 at 12:03:04PM -0700):
| ***@notwires.com (Howard West) wrote in message news:<***@posting.google.com>...
|
| > It actually looks like the ELF/COFF thing is a red herring. I am able
| > to run several other programs that are built at the same time. They
| > all report the same file format (ELF 32-bit LSB dynamic lib 80386), so
| > there must be something else wrong with the way I'm building them.
|
| Try the command "/bin/dump -Lv" on the executable that's giving the
| trouble. Are there any NEEDED entries to .so libraries in your
| application? If so, run the "file" command on them and see what
| that shows.

I think 'ldd' is more focussed for that purpose than 'dump -Lv' ...

[J. L. Schilling]

Post by Jean-Pierre Radley
|
| Try the command "/bin/dump -Lv" on the executable that's giving the
| trouble. Are there any NEEDED entries to .so libraries in your
| application? If so, run the "file" command on them and see what
| that shows.
I think 'ldd' is more focussed for that purpose than 'dump -Lv' ...

It is, assuming that all the .so libraries can be found by the
runtime linker (because they are in LD_LIBRARY_PATH or in the
default path (such as /usr/lib/).

dump -Lv will show the .so dependencies even if you don't know
where those libraries are....

Jonathan Schilling

[Howard West]

Post by Jean-Pierre Radley
|
| > It actually looks like the ELF/COFF thing is a red herring. I am able
| > to run several other programs that are built at the same time. They
| > all report the same file format (ELF 32-bit LSB dynamic lib 80386), so
| > there must be something else wrong with the way I'm building them.
|
| Try the command "/bin/dump -Lv" on the executable that's giving the
| trouble. Are there any NEEDED entries to .so libraries in your
| application? If so, run the "file" command on them and see what
| that shows.
I think 'ldd' is more focussed for that purpose than 'dump -Lv' ...

I think I see what is going on here. I hadn't noticed before that
file was showing "dynamic lib" on those files. The ones that run say
"executable" instead.

So it looks like this is a linking issue. I'll have to go through the
make files in this project. I suppose I've erroneously set some
switch to generate a shared object rather than a runnable program.