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.
Related
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.
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
While performing a compilation with cross g++ in a Linux machine ( lubuntu 11.10 ) in verbose mode, I can see the list of the default include header directories:
#include <...> search starts here:
/opt/eldk-4.2/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include
/opt/eldk-4.2/ppc_4xx/usr/include/c++/4.2.2/opt/eldk-4.2/ppc_4xx/usr/include/c++/4.2.2/powerpc-linux
/opt/eldk-4.2/ppc_4xx/usr/include/c++/4.2.2/backward
/opt/eldk-4.2/usr/../ppc_4xx/usr/include
Executing the very same g++ binary in another Linux machine (lubuntu 12.10), I get another different list, with less elements:
#include <...> search starts here:
/opt/eldk-4.2/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include
and in which some of the elments seem bad constructed, like the following:
ignoring nonexistent directory "/opt/ppc_4xx/usr/lib/gcc/powerpc-linux/includ../include/c++/4.2.2"
The result is that some code compiling on the first system is not compiling on the second because some headers are not found.
Why is this happening?. Where does this list come from?. Who is responsible for constructing it?. Is it possible to easily change it?.
Any help is appreciated.
You can add directories to the default search path by setting environment variables:
C_INCLUDE_PATH (for C header files)
CPLUS_INCLUDE_PATH (for C++ header files).
Alternatively, you can create and edit specfile and place it where G++ looks for them. You can check the path with strace gcc.
Additional documentation on specfiles on GCC page.
I have the exact some problem using ELDK 4.2. This is very likely connected to something that changed in ubuntu 12.04 as I have had the compiler run fine on the same computer before the upgrade.
My problem is that is seems to have forgotten /usr
ignoring nonexistent directory "/opt/eldk-4.2/../ppc_82xx/usr/include"
It should be
/opt/eldk-4.2/usr/../ppc_82xx/usr/include
Which works perfectly on ubuntu 11.10.
I have tried both installing ELDK from the ISO and copying the installation from a working version in ubuntu 11.10
Good afternoon,
I am having difficulties with libxml2.
I tried to build the Perl module XML-LibXML which is part of our standard runtime environment. However, this time the installation on a RHEL5 box failed, because the build process complained about missing libxml2:
$> perl Makefile.PL LIB=/foo/lib/perl PREFIX=/foo INSTALLDIRS=site
enable native perl UTF8
running xml2-config...ok (2.7.6)
looking for -lxml2... no
looking for -llibxml2... no
libxml2 not found
However, the file was available. Starting the build with
perl Makefile.PL LIB=/usr/inform/target/lib/perl PREFIX=/usr/inform/target INSTALLDIRS=site
led to more evidence of the real problem:
[...]
Can't load 'blib/arch/auto/Conftest/Conftest.so' for module Conftest: /usr/inform/target/lib/libxml2.so.2: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
at test.pl line 2
[...]
After some investigations I found that the problem appears to be that libxml2.so is created with text relocation:
[tess91#INF-AW] lib$ eu-findtextrel libxml2.so.2.7.6
the file containing the function 'get_crc_table' is not compiled with -fpic/-fPIC
the file containing the function 'crc32' is not compiled with -fpic/-fPIC
the file containing the function 'gzerror' is not compiled with -fpic/-fPIC
[...]
Ans since we have SElinux active on the target machine, linking against libxml.2 failed!
Is there any possibility to create libxml2 properly, or do I have to ask the admin to twist SElinux to allow relocations?
I really can't believe I am the olny one having this problem on Linux with SElinux active. What am I missing?
Any help apprecitated!
Regards,
Stefan
The simplest way is to have your administrator yum install libxml2-devel or even yum install perl-XML-LibXML. Otherwise, see if you can add -fPIC to the CFLAGS in the Makefile.PL.
I assume you are on 32-bit x86, any other architecture wouldn't work without -fPIC.
I just found a possible explanation:
During the build of libxml2 the compiler flag -fPIC is indeed used, so the code is created position independant, BUT:
When creating the shared library, the static libz is linked against it. Is that the source of my problem? That including a static lib in a shared executable taints the library by introducing non-relocatable code?
The fact that the symbols eu-findtextrel should already have pointed me in that direction, since crc32, get_crc_table, etc. look like encryption centered code...
These are the steps I am doing to compile the linux source on my machine :
1. Copy the config file from /boot to /usr/src/kernels/2.6.29.4-167.fc11.i586/ directory
2. make oldconfig
3. make
Step 3 fails with the following error :
make[1]: *** No rule to make target `missing-syscalls'. Stop.
Compiling on a x86 box.
Any suggestions ?
Please feel free to close this question if it does not belong here.
As archaic as it may sound it appears that currently in order to get kernel source on a system you have to manually select the source you want. One supposes that people don't build kernels as often as they used to and of course you may want to develop a kernel that does not match the version that you are running..
So for example I wanted to install VBox on my CentOS 6.2 box and while most kernel modules can be compiled without complete sources this update failed.
So I found this wiki page:
http://wiki.centos.org/HowTos/I_need_the_Kernel_Source
It doesn't list 6.2 and the naming conventions have changed on the final directory name so to get the 6.2 kernel source you go to http://vault.centos.org/6.2/updates/Source/ and select the version you want. If you want source for a different version go to http://vault.centos.org/ and navigate from there.
The docs recommend against doing an rpm-build on the kernel sources.
Make a new config file. Maybe the old one isn't working?
I have not been able to answer why this error happens :
Step 3 fails with the following error : make[1]: *** No rule to make target `missing-syscalls'. Stop.
But I was able to compile the vanilla version fine, without the above error.
I asked the same question on serverfault as well, which has a more detailed explanation of the steps taken : https://serverfault.com/questions/61354/missing-syscalls-error-during-kernel-compilation
since kernel 3.x.x this message appears if trying to build external modules having only single Makefile prepared.
Instead, according to this manual,
splitting into Kbuild (where all the source files are listed, example):
obj-m := module_source.c
and simple Makefile (having only default make directive, example):
default:
$(MAKE) -C $(KDIR) M=$$PWD
will solve the problem.
just in case, external module build directive would be following:
make -C <kernel source path> -M=<module source folder>
example: make -C . -M=extra/