Find the answer to your Linux question:
Results 1 to 4 of 4
Hi, I am trying to port some "C" code from Solaris to Linux. I have a Dell PowerEdge R610 with an Intel Xeon E5504 quad core processor running Red Hat ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2010
    Posts
    2

    C library core dumps


    Hi,
    I am trying to port some "C" code from Solaris to Linux. I have a Dell PowerEdge R610 with an Intel Xeon E5504 quad core processor running Red Hat Linux Enterprise 5.3. I am compiling in 64 bit mode.

    I have managed to get the code compiled and linked, but when I attempt to execute it, I get a core dump in one of the C library calls (like strcpy or printf.)

    I have a static library that contains our own code that makes the call to the C library. If I move the library method into the source file with the main method and rename it to be certain that I am executing my method instead of the method in our library, the call succeeds. Eventually another static library call is made that results in a core dump in the shared object.

    I compile my library code into a static library with gcc as:
    gcc -c -m64 -w -g `epi` mi_aplst.c
    along with other source files producing an library
    ar rv libmi.a mi_aplst.o mi_atime.o ...
    and the library (libmi.a) is installed into $LIBDIR

    The source containing the main method is compiled similarly
    gcc -c -m64 -w -g `epi` adbspl01.c
    The pro c code is precompiled as
    proc include=/c3/users/autotst/C3C/V9_9_9_9/include include=/c3
    /users/autotst/sde/include ireclen=132 oreclen=132 SQLCHECK=FULL
    USERID=C3C_V9_9_9_9_DEV/C3C_V9_9_9_9_DEV RELEASE_CURSOR=yes
    get_adbspl.pc
    and the object is created with
    gcc -c -m64 -w -g `epi` `epi` get_adbspl.c

    Finally the objects and libraries are linked with
    g++ -m64 -w `epi` adbspl01.o get_adbspl.o version.o -o adbspl01 `epl`
    -lcomm -lsglog -lc3c -lc -lrd -lc3 -lmi -lclntsh -lcommon10 -lcore10
    `cat /oracle/OraHome1/lib/sysliblist`

    LPATH=/oracle/client64/lib:/oracle10g/OraHome1/lib:/usr/lib:/c3/users/autotst/C3C/V9_9_9_9/lib
    LD_LIBRARY_PATH=/oracle/client64/lib:/usr/lib64:/usr/openwin/lib:/usr/local/lib64:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib

    running "ldd" against the executable produces:
    libclntsh.so.10.1 => /oracle/client64/lib/libclntsh.so.10.1 (0x00002b990db8e000)
    libdl.so.2 => /lib64/libdl.so.2 (0x000000306e200000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x000000306e600000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003070e00000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003080000000)
    libm.so.6 => /lib64/libm.so.6 (0x000000306de00000)
    libc.so.6 => /lib64/libc.so.6 (0x000000306da00000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000307e400000)
    libnnz10.so => /oracle/client64/lib/libnnz10.so (0x00002b990f018000)
    /lib64/ld-linux-x86-64.so.2 (0x000000306d600000)

    I would not be surprised if I had a compiler or linker flag wrong or missing, but don't know where to look. I have searched the internet trying to find similar issue, but haven't seen anything.

    Hopefully somebody can give me some kind of idea (any idea) about what it is that I may have wrong to cause this.

    Thanks for your help,
    Bruce

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Please post your code here. A common problem porting Solaris C code to Linux is not checking for null values in arguments to strcpy() and similar C library functions. Solaris functions check for null arguments and do nothing if found. Linux functions don't and will happily dump core on you if you don't check them first. Caveate programmer!
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Sep 2010
    Posts
    2
    Hi Rubberman!

    Thanks for replying.

    I have managed to get a little further which may tell you something about what I am doing (wrong.)

    I have found that if I declare my library method as extern inside the source that calls the library method, I can get a little further. In this case the string that is returned from the library gets assigned correctly to the local variable and I can print it out. However the next call to a library method fails. I subsequently declare that method as extern in my local source and get a little further again.

    Surely I don't have to declare every library method as extern in order to make the code succeed. Is there linker flag that I should be including or excluding?

    I have included the main source file (adbspl01.c) and the first library source file called (mi_basenm.c.) You can see the first failure which has been averted by the extern at "mi_base_name()." The next failure occured at SGloginit() which I managed to work around with an extern also.
    Attached Files Attached Files
    Last edited by reporrBoy; 09-28-2010 at 10:19 PM. Reason: add attachments

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    To get started: in mi_base_name() you don't check for null, or 0 length strings (str1) after removing trailing spaces.

    Next: all external functions should be declared "extern" in your code. That is what headers are for. Declare your included library functions there.

    Finally: you don't say what library function you are having problems with, or where it is in your source. Please clarify.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •