Skip to main content

Unviewable fstat error when trying to build a custom run time environment (a.k.a. 'run' command)

  • July 16, 2019
  • 9 replies
  • 0 views
D

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).

 

    9 replies

    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 16, 2019

    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.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 17, 2019
    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.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 17, 2019
    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.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 22, 2019
    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.

     

    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 22, 2019

    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.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 22, 2019

    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.
    Blair McDonald
    • Blair McDonaldModerator
    • Moderator
    • 292 replies
    • July 24, 2019
    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.

    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 25, 2019

    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?
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • July 25, 2019
    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.

     


    Terms & ConditionsAccessibility statement