Work on a enterprise modified version of SLES11.4 (64-bit with enough 32-bit 'stuff' to allow 32-bit applications to run). Am trying to upgrade the Oracle client from 11c to 12g. The application is a 32-bit application. I have the 32-bit Oracle client software installed. When I run the makefile provided by the vendor to build the custom RTE, the process dies with an error stating that 'fstat' is a hidden object. The system has the proper libc.so file to make 'fstat' (and a bunch of other stuff) visable.
After using strace, I have noticed that 'make' is trying to use the 64-bit linker. I don't know if this is the source of the problem, or a result of the real problem. All efforts to force 'make' to use the 32-bit linker result in 'cob' blowing up with an 'invalid option' error (the invalid option is -m from -m32).
If Blair McDonald (@Blair) is available, he would know what I am talking about (and probably wish he wasn't).
You pass options to the linker using the -Q cob option, e.g. "cob -x -Q-m32 foo.cbl".
But that won't help you, because "-m32" is not an ld option. It's a gcc (platform-specific) option. The ld equivalent, more or less, on Linux is -melf_i386; but that won't help you either, because the COBOL compiler will have told ld to use the 64-bit COBOL libraries, and they aren't compatible with linking a 32-bit binary, of course.
Is COBMODE=32 set in the environment? That's the correct way to tell MF COBOL to compile for 32-bit, if it's supported on your platform.
You pass options to the linker using the -Q cob option, e.g. "cob -x -Q-m32 foo.cbl".
But that won't help you, because "-m32" is not an ld option. It's a gcc (platform-specific) option. The ld equivalent, more or less, on Linux is -melf_i386; but that won't help you either, because the COBOL compiler will have told ld to use the 64-bit COBOL libraries, and they aren't compatible with linking a 32-bit binary, of course.
Is COBMODE=32 set in the environment? That's the correct way to tell MF COBOL to compile for 32-bit, if it's supported on your platform.
Currently off-site (trying to get ahead of the game). Will try setting
COBMODE=32 in my environment when I get back tomorrow (probably about 7AM
Easten Daylight time). and let you know if it worked.
Did you recompile with COBMODE=32 set, or just try to run? You have to have it set when building the executable as well. COBMODE tells both the compiler and the runtime what bitness to use.
ERR, "Yes". I'm running a makefile written by a 3rd party vendor which
does nothing more than execute a 'cob' command. My guess is that it calls
cob to generate the right kind of Micro Focus .so file and then link it in
with .so file they provide. And with them, we are outside of free support.
But, I have set COBMODE in the environment, and with most flags in the
makefile.
Currently off-site (trying to get ahead of the game). Will try setting
COBMODE=32 in my environment when I get back tomorrow (probably about 7AM
Easten Daylight time). and let you know if it worked.
I've had a chance to try this suggestion (note that I did not know about COBMODE). Setting COBMODE=32 in the environment, and then executing
cobmode -v
I Find:
Determining EFFECTIVE working mode
Determining SHELL default: Contents indicate 32-bit
Effective Default Working Mode: 32 bit
So COBMODE appears to be supported on my platform.
Unfortunately, my result is the same:
ld: $DESTINATIONlibrary: hidden symbol `fstat'
in /usr/lib/libc_nonshared.a(fstat.oS) is referenced by DSO
ld: final link failed: Bad value
make: *** [runnew] Error 1
(where the meaningless (to all but myself) library name has been changed to something more meaningful)
Further research (and reading the man page for ld.so (I had no idea that ld.so had a man page distinct from the man page for ld)) suggests that ld may be overriding cob, and I've spent a little time trying figure out where that may be.
I had hoped to do more research over the weekend; unfortunately, I lost power Friday and it still is not back (do have power at work).
Any additional hints would be appreciated.
I've had a chance to try this suggestion (note that I did not know about COBMODE). Setting COBMODE=32 in the environment, and then executing
cobmode -v
I Find:
Determining EFFECTIVE working mode
Determining SHELL default: Contents indicate 32-bit
Effective Default Working Mode: 32 bit
So COBMODE appears to be supported on my platform.
Unfortunately, my result is the same:
ld: $DESTINATIONlibrary: hidden symbol `fstat'
in /usr/lib/libc_nonshared.a(fstat.oS) is referenced by DSO
ld: final link failed: Bad value
make: *** [runnew] Error 1
(where the meaningless (to all but myself) library name has been changed to something more meaningful)
Further research (and reading the man page for ld.so (I had no idea that ld.so had a man page distinct from the man page for ld)) suggests that ld may be overriding cob, and I've spent a little time trying figure out where that may be.
I had hoped to do more research over the weekend; unfortunately, I lost power Friday and it still is not back (do have power at work).
Any additional hints would be appreciated.
Did you recompile with COBMODE=32 set, or just try to run? You have to have it set when building the executable as well. COBMODE tells both the compiler and the runtime what bitness to use.
I've had a chance to try this suggestion (note that I did not know about COBMODE). Setting COBMODE=32 in the environment, and then executing
cobmode -v
I Find:
Determining EFFECTIVE working mode
Determining SHELL default: Contents indicate 32-bit
Effective Default Working Mode: 32 bit
So COBMODE appears to be supported on my platform.
Unfortunately, my result is the same:
ld: $DESTINATIONlibrary: hidden symbol `fstat'
in /usr/lib/libc_nonshared.a(fstat.oS) is referenced by DSO
ld: final link failed: Bad value
make: *** [runnew] Error 1
(where the meaningless (to all but myself) library name has been changed to something more meaningful)
Further research (and reading the man page for ld.so (I had no idea that ld.so had a man page distinct from the man page for ld)) suggests that ld may be overriding cob, and I've spent a little time trying figure out where that may be.
I had hoped to do more research over the weekend; unfortunately, I lost power Friday and it still is not back (do have power at work).
Any additional hints would be appreciated.
My sympathies on your power situation, by the way. I'm currently in New Mexico, but the neighborhood where I live most of the year, in Michigan, has been without power for a few days.
My sympathies on your power situation, by the way. I'm currently in New Mexico, but the neighborhood where I live most of the year, in Michigan, has been without power for a few days.
Hi Phil, this is Blair. Long time no see!
Are you still using Server Express 5.1? If so, what Wrap Pack are you using?
It sounds like you have COBMODE set correctly. Can you isolate the exact cob command that is being executed by the makefile?
This type of issue may be better investigated in a Support Incident. Please feel free to create one, and ask that it be assigned to me. Let me know if you have any issues creating a Support Incident.
Hi Phil, this is Blair. Long time no see!
Are you still using Server Express 5.1? If so, what Wrap Pack are you using?
It sounds like you have COBMODE set correctly. Can you isolate the exact cob command that is being executed by the makefile?
This type of issue may be better investigated in a Support Incident. Please feel free to create one, and ask that it be assigned to me. Let me know if you have any issues creating a Support Incident.
I was hoping you would jump in.
I am responding from home; I've been without power for 3.7 days; I can
respond to your other questions tomorrow. Can you give me detailed clue as
to how to create a support incident?
I was hoping you would jump in.
I am responding from home; I've been without power for 3.7 days; I can
respond to your other questions tomorrow. Can you give me detailed clue as
to how to create a support incident?
, I can now give some more info:
1) Yes, we are still on WrapPack5.1
2) /etc/alternatives/java points to /usr/lib64/jvm/jre-1.6.0-ibm/bin/java. The java version in the mfcobol directory is unchanged (uncovered this bit trying to be complete here)
3) In fact, the only changes to our environment have been
- Migration from Ford's version of SLES11.1 to SLES11.4
- Attempting to move to the 32-bit Oracle 12c client.
So, today when I run that makefile we know and love I get:
cob -xage "" -X ANIM -X COBCOMMS -X RTSCALL /usr/oraclnt/product/11.2.0/precomp/lib/cobsqlintf.o \\
-lcrypt -L../../t2c/lib -L/ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport/lib -lt2c -ltfos -ltemu -lxport -L/usr/oraclnt/product/11.2.0/lib /usr/oraclnt/product/11.2.0/lib/libpls11.a -lclntsh \\
-o /ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport/bin/runnew \\
-m sqfile=mpeio -m rlfile=mpeio -m lsfile=mpeio
--- runnew created in /ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport bin directory -
(so now you know what the options to 'cob' are. They don't all make good sense to me)
All we want to do is to rebuild 'run' with the Oracle 12c client libraries. So, I change ORACLE_HOME and get::
cob -xage "" -X ANIM -X COBCOMMS -X RTSCALL /usr/oraclnt/product/12.2.0.1/precomp/lib/cobsqlintf.o
\\
-lcrypt -L../../t2c/lib -L/ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport/lib -lt2c -ltfos -ltemu -lxport -L/usr/oraclnt/product/12.2.0.1/lib /usr/oraclnt/product/12.2.0.1/lib/libpls12.a -lclntsh \\
-o /ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport/bin/runnew \\
-m sqfile=mpeio -m rlfile=mpeio -m lsfile=mpeio
ld: /ford/proj/twos/scm/psinger1/workspace/sourcet/transport/xport/bin/runnew: hidden symbol `fstat'
in /usr/lib/libc_nonshared.a(fstat.oS) is referenced by DSO
ld: final link failed: Bad value
make: *** [runnew] Error 1
Looking thru various outputs from strace, the only problem I can find is that the 64-bit version of ld is being used. I can wipe out any and all references to 64 bit libraries in my path (point the jre to the 32-bit guy provided by Oracle) and find no reference to any 64-bit file and still get this error.
