I downloaded and compiled the header which is used in pthread functions. But one function is missing and that is *__lll_robust_lock_wait*. Now I noticed that there is an assembly code header out there, . I downloaded this and tried to compile it using the usual the compile command "as lowlevelrobustlock.S" and I got nearly 100 compiler errors. Is there a simpler version of the function I mentioned that will actually compile and be useful?
The assembly code header can be found here
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'm new to all of this and am trying to compile a program on a virtual machine with kernel version 3.10.0-957.el7.x86_64. But I get this error:
/home/../../../isr_demux.c: In function 'demux0_isr':
/home/../../../ isr_demux.c: 782:3: error: implicit declaration of function 'rdtscl' [-Werror=implicit-function-declaration]`
I pulled up isr_demux.c and saw that the snippet of code it said was causing the error is this:
The third to last line is line 782. What's interesting is that this same file compiles fine on a virtual machine with an older kernel version 3.10.0-327.el7.x86_64.
I searched online a lot but am truly stuck. I saw another post and checked my header files, and included linux/proc_fs.h along with many other ones. Someone said I could be missing a function prototype or definition, but adding a prototype did not fix this, and defining the function led to a redefinition error.
Any ideas about whether I'm still missing a header file somewhere? Or if the problem is with the newer kernel itself and I might need to find some sort of patch? Thanks!
The website elixir.bootlin.com is pretty useful for these things. The following link is a search across the entire kernel sources tree for version 3.10.108 for the symbol rdtscl.
https://elixir.bootlin.com/linux/v3.10.108/ident/rdtscl
rdtscl is only defined as a macro, so looks like the macro is not defined where you are getting your error about implicit declaration of rdtscl.
The two places where rdtscl is defined as a macro are:
https://elixir.bootlin.com/linux/v3.10.108/source/arch/x86/include/asm/msr.h#L182
https://elixir.bootlin.com/linux/v3.10.108/source/arch/x86/include/asm/paravirt.h#L182
So the fix is to include the correct headers files if you are building for x86 (the headers defining those macros are in arch/x86), or replace the call to rdtscl with something else.
I'm attempting to write a C program incorporating OPENFILENAME and of course I need the header file. So, following the instructions provided with tcc, I downloaded the header files MinGW uses for the Win32 API (and the library files) and put them in the appropriate directories as instructed. However, when I come to compile the program, I get the following error:
In file included from sw1.c:2:
c:/prg/tcc/include/winapi/commdlg.h:503: declaration list expected
This seems rather odd, given it's a standard header. So, I look up the line and it's typedef __AW(CHOOSECOLOR) CHOOSECOLOR,*LPCHOOSECOLOR;, which doesn't look very valid to me but then I'm not really a C expert and I've mainly been writing in Linux. I have no idea why it's going wrong though and no knowledge of how to fix it? Is it a bug in tcc?
As evidence that this should be possible, here is the appropriate passage from the tcc readme:
Header Files:
The system header files (except _mingw.h) are from the MinGW
distribution:
http://www.mingw.org/
From the windows headers, only a minimal set is included. If you need
more, get MinGW's "w32api" package.
I understand that this question is similar to Error when including Windows.h with TCC but my "windows.h" file does work - it's just this that doesn't.
Does anyone know how to solve this? I'm really at a loose end!
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.
In my Turbo C++ program, I can't run any of the graphics program. When it compiles, it shows an error like:
undefined symbol _line, _closegraph,_ getmaxx etc...
Is it due to the settings of my c-program?
Is this an old program that was written for Turbo C++, and that you're trying to compile with a modern compiler? If so, it might be the case that the program uses compiler-specific extensions and libraries, that are simply not available in the compiler you're using now.
If that is the case, you must either
find an existing library for your current environment that emulates the old Turbo C++ one, or
find out exactly what each call is supposed to do, and change the code to use something that your environment supports.
It's compile error and not link error. Looks like "graphics.h" is missing.
Do
#include "graphics.h"
Those errors are typical of a missing library in your build. Try linking the appropriate libraries and rebuild the solution (most likely graphics.lib).
-John
If the problem is of compiling error then you may add the header file:
#include<graphics.h>
if the problem still persists then make sure you have added the header file:
#include<dos.h>