I'm working on a Linux machine (debian) 64bit and created a simple project involving JNI. The program is running fine on Linux with the created Java project and the compiled .so file. The goal now is to compile the C++ part of the project into a .dll instead of a .so to get it to run on Windows machines.
I read some forums and some articles like this one Article, but all of those articles were about compiling from console and also didn't involve the necessary JNI includes.
I also downloaded the cross-compiler from the given article and tried to get it to run in Netbeans. Therefore I set up another C/C++ Tool Collection in Netbeans and told it to use the x86_64-w64-mingw32-gcc compiler for both C and C++. But Netbeans is giving me some errors compiling the file, telling me the x86_64-w64-mingw32-gcc compiler could not be found which is quite random I think because I selected it from the file chooser. Did any of you do something like this already, building a .ddl from Netbeans running on Linux? If yes, how did you get it to work?
x86_64-w64-mingw32-gcc: not found
bproject/Makefile-Debug.mk:66: recipe for target 'build/Debug/GNU_1-Linux-x86/WrapperCpp.o' failed
make[2]: *** [build/Debug/GNU_1-Linux-x86/WrapperCpp.o] Error 127
make[2]: Leaving directory
nbproject/Makefile-Debug.mk:59: recipe for target '.build-conf' failed
make[1]: *** [.build-conf] Error 2
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make: *** [.build-impl] Error 2
#Edit: I'm a step further now: I installed the correct mingw32 tools: sudo apt-get install mingw32. The programm does now compile without errors using the i586-mingw32msvc-g++ compiler but it still results in a .so instead of a .dll. I guess it has something to do with the make command but I haven't found anything about that yet.
Related
I'm working with a Linux driver that is building on v5.7.x kernels but not on the latest v5.8.x releases.
To summarise, most of the driver is pre-built and the kernel interface is built on the target. This involves a make -f Kbuild command.
Having checked all of the relevant kernel interface files for any changes that would affect us, normally the driver would just build as usual on a new kernel. However, this time we get the following error:
make[2]: *** [scripts/Makefile.modpost:111: /path/to/source/Module.symvers] Error 1
make[1]: *** [Makefile:1669: modules] Error 2
make[1]: Leaving directory '/usr/src/kernels/5.8.0-1.el8.elrepo.x86_64'
make: *** [Kbuild:26: default] Error 2
This is from CentOS 8.1, but the same error has been seen on Ubuntu 20.04.
I am no expert on this so interpreting these errors is a bit difficult. I have tried building with the KBUILD_VERBOSE flag and it doesn't really provide any useful information, other than the build succeeding until this point.
On previous kernels the Module.symvers file would be created but empty. On 5.8 this file is not created at all presumably due to this error. As a result, the .ko file is not created.
Finally, if we drop in the source files rather than the pre-built .o files the build does succeed. These .o files are built with a very old version of GCC (4.4.7) but we have also tried building with a much newer version (8.3.1), the same version as the target machine.
I would appreciate suggestions for things to check. Let me know if any other details would help.
Edit:
I ran make on Makefile.modpost manually and got the following output:
sudo make -f ./scripts/Makefile.modpost
WARNING: Symbol version dump "vmlinux.symvers" is missing.
Modules may not have dependencies or modversions.
make -f /scripts/Makefile.modfinal
make[1]: Entering directory '/usr/src/linux-headers-5.8.0-050800-generic'
make[1]: /scripts/Makefile.modfinal: No such file or directory
make[1]: *** No rule to make target '/scripts/Makefile.modfinal'. Stop.
make[1]: Leaving directory '/usr/src/linux-headers-5.8.0-050800-generic'
make: *** [scripts/Makefile.modpost:117: __modpost] Error 2
I am answering my own question in case it helps anyone else with this problem. Although it has never been an issue in the past, we've always had a warning that the corresponding .o.cmd file was not present for our .o_shipped files. This appears to be important in kernel 5.8 onwards and my fix was to add a touch command to the Kbuild file (i.e. "touch .driver.o.cmd"). This does not remove the warning but it allows the driver to build as normal.
I successfully built standalone llvm on windows with clang-cl (clang 8.0 downloadable binary) against back-end msvc build tool 2017 with windows 10 sdk using cmake/ninja
After that when I was building standalone clang, it reported "version.lib" in linking phase of clang-rename.exe is missing.
LINK Pass 1: command "....
" failed (exit code 1104) with the following output:
LINK : fatal error LNK1104: cannot open file 'version.lib'
The weird thing is that word version.lib was slabbed in place amoung various lib\clang?????.libs and the leading -LIBPATH:llvm\\.\lib
I tried looking for version.lib in both build folders of llvm and clang, and found none.
Am I supposed to have verson.lib in llvm\lib?
What am I missing here?
I have a problem trying to compile a library. I am using curve25519-donna to generate key pairs. I have already downloaded the library and unzipped the file, but my problem is with the compilation.
I have changed my directory to curve25519-donna-1.3 and this is the code I tried to use the compile the library:
env CC='gcc -02' make
And this was the outcome.
Makefile:23 recipe for target 'curve25519-donna-c64.o' failed
make: *** [curve25519-donna-c64.o] Error 1
I am running on a Raspberry pi OS, am I missing some gcc's that I need to install in this operating system?
I've upgraded and updated but I am still having problems with this. Any help will be much appreciated, thanks!!
I am trying to create a custom kernel rpm. So I made use of "make rpm-pkg".
Everything was going fine until it hit this error.
..
..
INSTALL sound/usb/line6/snd-usb-toneport.ko
INSTALL sound/usb/line6/snd-usb-variax.ko
INSTALL sound/usb/misc/snd-ua101.ko
INSTALL sound/usb/snd-usb-audio.ko
INSTALL sound/usb/snd-usbmidi-lib.ko
scripts/Makefile.fwinst:43: *** mixed implicit and static pattern rules. Stop.
make[2]: *** [_modinst_post] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.jJi4sq (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.p88MqU (%install)
make[1]: *** [rpm-pkg] Error 1
make: *** [rpm-pkg] Error 2
I understand there is something wrong with Makefile declarations, but also wondering if anyone has hit this issue.
If you are using make version 3.81 or 3.82 then this is likely the known make "bug" discussed here.
Specifically a change to what make believes is a meaningful set of targets to specify in a single list changed in an incompatible way and the kernel had been using a set of targets that became invalid.
The fix, after some back and forth between the GNU Make maintainer and some concerned other developers, was to convert the fatal error into a warning (at least temporarily).
I was able to fix this. Apparently its an issue with the UTS_MACHINE not being right for arm64. It should be aarch64 so that the packaging scripts use it right. there's also small tweak in the script that generates the rpm spec file.
So 'make' is not an issue in this case.
I have searched this but the questions I found are about getting the toolchain to work, my problem is that it works on all but a few directories. Also I am not building Linux.
I am trying to move a project from a Linux machine to Windows to make people happy. The same project builds fine under Linux (Ubuntu 12.04) using the Linux Binary for the same toolchain (I recently reloaded both toolchains from the same directory at Mentor to be sure, see details below).
I installed Cygwin, got the packages, set up paths, etc. In general the build works for 90% of the project BUT as make traverses the directory, it finds everything except two files (to clarify, these two are the first files in their respective directories, so I assume the problem will apply to the whole directory). The log below shows the first fail:
if I take lwip out of the build then it blows up on the next one
if I take the next one out of the build then everything else (quite a bit) compiles; then the linker fails on the two missing items as expected.
More precisely, e.g.
it finds /home/Nadi/project/version-2.9/external/freertos/Source/portable/GCC/ARM_CM3_MPU/port.c
but not /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c
from the directory that I am running make, "ls" finds the file that the compiler cannot.
log:
$ make
external/freertos
external/lwip
[cc] Debug/api_lib.o
arm-none-eabi-gcc.exe: error: /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c: No such file or directory
arm-none-eabi-gcc.exe: fatal error: no input files compilation terminated.
Makefile:189: recipe for target `Debug/api_lib.o' failed
make[2]: *** [Debug/api_lib.o] Error 1
Makefile:37: recipe for target `lwip_world' failed
make[1]: *** [lwip_world] Error 2
Makefile:160: recipe for target `extern' failed
make: *** [extern] Error 2
Details:
GCC Chain : arm-none-eabi-gcc ; gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-63)
Cygwin : CYGWIN_NT-6.1-WOW64
Although it might not help in this particular case, I faced similar problem with CodeSourcery's gcc not recognising Cygwin's paths like /cygdrive/d/foo.c at all - installation of cygpath package and setting environment variable export CYGPATH=c:/cygwin32/bin/cygpath (or set CYGPATH=c:/cygwin32/bin/cygpath in windows console) solved all the issues.
Be sure to define path to cygpath executable in exactly same way as above, regardless of Cygwin or Windows console used.
The details of my previous comment is that you're in for a lot of trouble using the windows/cygwin combo with Sourcery based cross-compilers. You can read more about this at SamyGo. Some of the issues using Windows, presented in all gory detail there, are:
Uses ACL to set file permissions and ownership (Not Linux compatible.)
Has it's own way of creating symbolic links (Not Linux compatible.)
Uses a non case-sensitive default for its fixed NTFS drives.
(Often and silently break archives originally compressed under Linux.)
Uses the Win32 (non POSIX) standard for file paths (Not Linux compatible.)
Uses the 2 characters Carriage-Return and New-Line ("\r" & "\n") for
End-of-Line (EOL) representation, contrary to POSIX, which uses only NL.
So in order not to waste time doing 3rd party debugging, you'd be much better off building your own cross-compiler from scratch, as shown in the XDA links in that other post. Since the advent of Android's, this is no longer difficult.