We are porting an application from HPUX to Linux using Microfocus COBOL and GNU C on both platforms.One of our shared libraries is failing at runtime with the following error:
AB123: symbol lookup error. libRTS.so: undefined symbol: _mFldhandle
My understanding is that _mFldhandle is internal to Microfocus.
Can anyone point me to why we might be having an issue / what we should be including to make sure _mFldhandle is available at runtime?
Thanks!
Contrary to the comments from above the usual reason for this symbol being missing is not using "cob" to link your exe or shared object.
The other reason is not using the same 'C' compiler that the product was created with.
Related
I'm trying to call the STM32 Cube Programmer C libraries from Rust.
The entire code, and branches showing various attempts, are available here:
https://github.com/becky112358/rust_c_linking_stm32_cube_programmer
Attempt 1 (in my GitHub repository, branch main)
Following the Rust Bindgen tutorial: https://rust-lang.github.io/rust-bindgen/
This is my preferred method. A Rust crate wraps the C library. Other Rust crates can then include the Rust wrapper crate, and not have to worry about any C libraries.
... in theory.
The Rust crate wrapping the C library (libstm32_cube_programmer_sys) builds ok. Its tests run ok.
The Rust crate calling the Rust crate which wraps the C library (caller) does not build, but reports:
= note: LINK : fatal error LNK1181: cannot open input file '.\drivers\CubeProgrammer_API.lib'
Why is caller even trying to look for the C library? I expected libstm32_cube_programmer_sys to handle all C library to Rust conversion, and that any Rust crates then calling libstm32_cube_programmer_sys could be purely Rusty (with maybe some unsafeness).
In build.rs I initially mis-wrote the C library name, and libstm32_cube_programmer_sys did not build. Correcting the library name allowed libstm32_cube_programmer_sys to build successfully. So it seems like libstm32_cube_programmer_sys does open the C library.
I tried adding the path to the drivers folder to my PATH.
I tried listing the absolute path to the C library:
println!("cargo:rustc-link-lib=C:/[blah blah]/drivers/CubeProgrammer_API");
I could not find how to feed in the path correctly, without Rust reporting:
error: renaming of the library `C` was specified, however this crate contains no `#[link(...)]` attributes referencing this library.
Attempt 2 (branch all_in_one)
In the main branch it seemed like maybe the problem was that libstm32_cube_programmer_sys could find the C library but caller could not. So I tried discarding the separate Rust crate, and having a single Rust crate which both wraps the C library and calls the C functions.
This time I get the following error, plus a bonus warning:
= note: caller.59pofysds2mkvvjr.rcgu.o : error LNK2019: unresolved external symbol disconnect referenced in function _ZN6caller4main17ha79648c0a9e86ed0E
.\drivers\CubeProgrammer_API.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
Attempt 3 (branch link_search)
I searched a lot on the internet and found lots of different ways to call a C library from Rust. One way is to use link-search rather than link-lib. This surely only makes things harder for the compiler because you make it do more work. But I am stuck and need to try different things!
This time I get the following error, plus the bonus warning:
= note: caller.59pofysds2mkvvjr.rcgu.o : error LNK2019: unresolved external symbol __imp_disconnect referenced in function _ZN6caller4main17ha79648c0a9e86ed0E
.\drivers\CubeProgrammer_API.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
Question
How do I make this work? Ideally from Attempt 1, but I'll take anything!
When we have:
C library <- Rust library <- Rust code
It seems that
when compiling, the Rust code needs to be able to see the C library, even though it is also calling the Rust library
when running, there may be C dlls which you need to store alongside the Rust exe
That was my main misunderstanding when I posted my original question.
Some other tips / reminders:
Make sure to use the correct lib file! (x64, x86 etc)
Resolve warnings too!
I am trying to re-use BlueZ code in my own C program to manage Bluetooth connection and running into compilation issues.
When I analyzed the problem further here is what I think is happening:
It all comes down to my program structure:
1.myadv.c includes myadv.h includes gio.h
2. myadv.c includes "gdbus.h" (Helper lib)
Now the problem is gdbus.h has certain symbol definitions (typedef, methods etc...) that conflict with internal defs in gio.h
Because of that I get compiler errors like this:
/usr/include/glib-2.0/gio/gioenums.h:1383:3: error: conflicting types for ‘GDBusSignalFlags’
} GDBusSignalFlags;
^~~~~~~~~~~~~~~~
conflicting types for ‘g_dbus_proxy_new’
void g_dbus_proxy_new
What is the best practice to avoid such symbol conflict errors during inclusion? Please note, I need to use both header files:
gio.h (The gnome lib)
gdbus.h (The dbus helper directly borrowed from BlueZ)
Don’t use the gdbus.h from BlueZ. It’s not compatible with GLib, yet erroneously uses the GLib symbol namespace (the g_ or G prefix).
Use the GDBus API from GLib itself, seeing as you’re already using GLib/GIO in your project.
I'm using JNI as an interface between a Scala software and a dynamic native library that we will call libnative.so.
Part of said native code uses openmp to perform some parallel operations. Therefore, when building this dynamic library, I specify '-fopenmp' both as a CFLAG and as a LINKFLAG.
There are no errors during the compile process. However, on run time, I get this one:
java: symbol lookup error: /tmp/jni-5458866585640472540/libnative.so:
undefined symbol: GOMP_parallel
When using objdump to explore the symbols contained by the library, the referred one is found, although it seems to be marked as undefined:
$ objdump -TC libnative.so | grep "OMP"
0000000000000000 D *UND* 0000000000000000 GOMP_parallel
After exploring this error for a while, it seems to me that references to external libraries (such as openmp) have to be, in fact, undefined and loaded on run time. I am also thinking that the JRE is not being able to find such library at execution time on the system.
Would these assumptions be true? How could this problem be fixed?
Thank you all in advance.
Fix:
When building the dynamic library from several static libraries, we need to add -fopenmp to this process, even if we have already done so for each of said modules.
I am trying to compile some source code and I am having issues. The code is written in C and FORTRAN and I am running into an issue with my compilers going from one to the other. This is the error message being returned;
mod_par.o: In function `__mod_par_MOD_domdec':
mod_par.f90:(.text+0x35a47): undefined reference to `partition_'
collect2: error: ld returned 1 exit status
make: *** [fvcom] Error 1
This is what I believe to be the offending bit of code from the file mod_par.F;
# if !defined (PARTITION_SPECIAL)
So I have been advised that this is a common problem encountered due to different naming conventions in C and FORTRAN. I have been give some advice on how to go about solving the problem, however, I don't understand the advice. It is as follows;
1) Work out which library hosts this partition function
2) Read through the docs for that library to find out how to generate a fortran wrapper library
3) Make sure you link through to the wrapper library as well as the original library
Anyone able to put this into laymans terms for me/advise on how to proceed/point me on to info to help me proceed? Let me know if you need anymore info.
I actually resolved this the issue was that I was building the application using mpi compilers and the METIS library that was required for a parallel build was not linked. I linked this and the application is now built. – deiniol
I have an annoying CMake issue. I have a project with more than one directories, such as (theoretically):
compiler -> generates compiler.exe and compiler.dll
This is pure C++
However the compiler.dll needs to link to machine.dll (see below) due to use of some fancy things ...
and the compiler.dll is a SHARED library
machine -> generates machine.exe and machine.dll -
this is half C and half C++. The C++ part needs to link to compiler.dll
So here a circular dependency arose, which is very elegantly solved on Linux, however on MSVS2012, the linker complains with LNK2019 ... unresolved external symbol. Which is understandable, since when I see the compilation, the order is the following:
it compiles the machine's C files
it tries to compile the machine's C++ files ... and here it fails at the linking, since the compilers' C++ files were not compiled yet...
How can I resolve this issue?
Problem was solved by converting the shared libraries into static ones and extracting the necessary parts into a shared library, without keeping the circularity.