Compiling/Linking COBOL code on a RHEL 8.6, which compiles fine but then when it tries to link I get an error with one of the variables:
cob2 -F//etc/cob2.cfg -v <cobolprog.cbl> -L/lib64 -ldb2 -I/include/cobol_a/ -q"size(16384K) -o cobolprog
The output is /usr/bin/ld: skipping incompatible lib64/libdb2.so when searching for -ldb2
/usr/bin/ld: cannot find -ldb2
If I remove the -ldb2 I get 'undefined reference to 'SQLGSTRT', 'SQLGALOC etc
When I try this with lib32 and -ldb2 I dont see issues?
I did try using the -q64 on the cmd line but apparently this is not supported on linux.
db2level
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", and Fix Pack "0".
Product is installed at "/opt/IBM/db2/V11.5"
cob2 -V
Program cob2
Version 1.1.0
Built Mon Sep 27 10:39:30 2021
Tried 32 bit which compiles the cobol fine, but it now seems to have an issue with linking a static library I need:
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib/Scrtl.0(.text+0x1c): unresolvable R_386_GOTOFF relocation against symbol '__libc_csu_fini'
It appears that you are using IBM COBOL for Linux on x86 version 1.1.
According to IBM's documentation at this link
the ADDR compiler option specifies whether to create a 32-bit or 64-bit object file.
Additionally, as you are on version 1.1 (the currently available version as of February-2023), the documentation also has this specific relevant note:
Note: The ADDR(64) and -q64 options are not currently supported. The
compiler accepts and ignores these options and defaults to ADDR(32).
This means that your object file is 32-bit, but you are trying to link (ld) with the 64-bit Db2 libraries, and consequently ld skips the incomptabile library with the message that you see. You should Link with the 32-bit Db2 libraries instead, they are in the lib32 directory of the Db2 client, so arrange for this in your command line options.
Related
I followed the directions in the following URL to build a gcc compiler for Linux:
https://solarianprogrammer.com/2016/10/07/building-gcc-ubuntu-linux/
The resulting compiler builds 64-bit code with no problems.
However, when I try to build 32-bit code (by specifying the -m32 compiler option), I get errors.
Here are the errors that I get:
cannot find -lstdc++
cannot find -lgcc_s
skipping incompatible libgcc.a when searching foor -lgcc
cannot find -lgcc
Obviously, when I built the compiler, I did something wrong - can anyone tell me what I did wrong and how I can rebuild the compiler to build both 32-bit and 64-bit code.
You at least need to configure with --with-multilib-list=m32,m64 on the configure command line.1 You definitely need to not configure with --disable-multilib. You may also need to build&install additional versions of other libraries.
In general, searching the documentation for 'multilib' will show you all the places where it talks about building or using gcc with multiple target ABIs.
1This is the default on at least some versions of gcc. You could also add mx32 if you want to experiment with that.
I am porting a large C++ library (libcoro.so) and example application (coro-example.cpp) from Windows to RedHat Linux 7.4. I have very little development experience on Linux, so this is probably a 'newbie' question. I have libcoro and the example app compiling, linking, and running on my RHEL 7.4 VM. However, the gcc linker fails to link the app on the customer's RHEL 7.4 machine when he tries to link coro-example.o to libcoro.so. The error message is:
/usr/bin/ld: warning: libusb-0.1.so.4, needed by ./bin/libcoro.so not
found (try using -rpath or -rpath-link) libcoro.so: undefined
reference to 'usb_open' libcoro.so: undefined reference to
'usb_release_interface' ...etc...
Running 'ldd coro.so' on my machine displays:
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f71115db000)
...etc...
And on the customer's machine:
libusb-0.1.so.4 => not found [many other libs] => not found ...etc...
Indeed, these libraries are in my /lib64 folder, but are not in the customer's. I'm not sure how they got installed on my machine. I have access to the missing libraries and can deliver them with my libcoro.so library. I really want my app to be self-contained and run on any RHEL 7.x machine. My question is:
What is the best way to identify which libraries are not part of the RHEL 7.x installation and have the linker fail on my machine if I'm not delivering a local copy? I tried linking with -nodefaultlibs, but the link fails on functions like printf() and I haven't found a way to locate these standard libraries. They don't appear to be in /lib64.
Is there a way to exclude /lib64 from the default library search?
There is a linker switch -Wl,--no-undefined which seems to do what I want. It fails to link and generates an error is the library is isn't explicitly named. Also, the command ldd libcoro.so lists all dependencies and where they are being resolved. I also found this this article very helpful.
Ok, so I want to link against a lower version of libc / glibc, for compatibility. I noticed this answer about how to do this, on a case-by-case basis:
How can I link to a specific glibc version?
https://stackoverflow.com/a/2858996/920545
However, when I tried to apply this myself, I ran into problems, because I can't figure out what lower-version-number I should use to link against. Using the example in the answer, if I use "nm" to inspect the symbols provided by my /lib/libc.so.6 (which, in my case, is a link to libc-2.17.so), I see that it seems to provide versions 2.0 and 2.3 of realpath:
> nm /lib/libc.so.6 | grep realpath#
4878d610 T realpath##GLIBC_2.3
48885c20 T realpath#GLIBC_2.0
However, if I try to link against realpath#GLIBC_2.0:
__asm__(".symver realpath,realpath#GLIBC_2.0");
...i get an error:
> gcc -o test_glibc test_glibc.c
/tmp/ccMfnLmS.o: In function `main':
test_glibc.c:(.text+0x25): undefined reference to `realpath#GLIBC_2.0'
collect2: error: ld returned 1 exit status
However, using realpath#GLIBC_2.3 works... and the code from the example, realpath#GLIBC_2.2.5 works - even though, according to nm, no such symbol exists. (FYI, if I compile without any __asm__ instruction, then inspect with nm, I see that it linked against realpath#GLIBC_2.3, which makes sense; and I confirmed that linking to realpath#GLIBC_2.2.5 works.)
So, my question is, how the heck to I know which version of the various functions I can link against? Or even which are available? Are there some other kwargs I should be feeding to nm? Am I inspecting the wrong library?
Thanks!
It seems to me that you have mixed up your libraries and binaries a bit...
/lib/libc.so.6 on most Linux distributions is a 32-bit shared object and should contain the *#GLIBC_2.0 symbols. If you are on an x86_64 platform, though, I would expect GCC to produce an 64-bit binary by default. 64-bit binaries are generally linked against /lib64/libc.so.6, which would not contain compatibility symbols for an old glibc version like 2.0 - the x86_64 architecture did not even exist back then...
Try compiling your *#GLIBC_2.0 program with the -m32 GCC flag to force linking against the 32-bit C library.
I compiled the MongoDB C Drivers successfully and run the test scripts also but I am not able to compile the scripts which I am writing myself.
Following is the command and its error output.
$ gcc -Isrc --std=c99 ./src/*.c -I ./src/ tutorial.c -o tutorial -D_POSIX_C_SOURCE=200112L
./src/env_win32.c:27:53: fatal error: ws2tcpip.h: No such file or directory
compilation terminated.
I found that there is no file name ws2tcpip.h in /usr/include directory
Take out the ./src/*.c, that tells gcc to compile all of the c programs in the /src directory which includes some windows only programs.
What worked for me was to tell gcc to include the libmongoc.so that was built when the drivers were built.
The following command worked for me. My drivers are in directory "mongo-c-driver".
gcc --std=c99 -I mongo-c-driver/src -o tutorial tutorial.c mongo-c-driver/libmongoc.so
In my opinion the mongodb C API documentation is a little buggy in this area. Also, the latest header files don't match the source code shown in the tutorial. For example mongo-insert requires 4 parameters in the v0.6 headers, but the tutorial shows only 2 parameters.
In researching this problem and trying to recreate it by installing mongoDB and the C driver myself I have discovered that v0.6 of the driver broke compatibility with previous version of the API by adding support for write_concern which adds a 4th parameter to the mongo_insert function (which can be set to null). The example.c program provided in the docs/examples directory does not compile in v0.6. This bug is documented in patch CDRIVER-157 in github for the c-driver.
I am trying to compile the Boost 1.48 in CentOS 5.6. I need the files to be in this format:
boost_program_options-gcc41-mt-1_48
I am compiling with this bjam flags:
./b2 -q --toolset=gcc --layout=tagged --without-mpi install
but it still don't add the gcc prefix to the name.
How can I fix this?
For me (although I use darwin toolset instead of plain gcc) Bjam creates files with names, like:
libboost_program_options-xgcc42-mt-1_49.a
Create the site-config.jam or user-config.jam file, which defines your custom version of GCC toolset, as described in 'Configuration' section of the Boost.Build documentation.
Additionally, there is an example, which suggests, that standard GCC toolset has version names defined as numbers only, without the gcc prefix.
Boost output filenames are generated, by the tag rule in boostcpp.jam. You can check there, if the above solution would be insufficient