I want to know how to cross compile nginx-1.0.11.
I have already tried : --with-cc option
but it is giving me an error : checking for C compiler ... found but is not working
./configure: error: C compiler arm-linux-gcc is not found
--with-cc-opt is also not working.
I tried to change compiler manually too(by changing a Makefile).
I have already install arm-linux-gcc and its working fine with openssl(It successfully cross compiled openssl. so problem is not with arm-linux compiler).
Any help will be highly appreciated ..
Thanks in advance. :)
There is no easy answer. nginx has it's own non-autoconf configuration system which currently doesn't support cross compilation.
Either hack or avoid the configuration system, or wait until nginx adds support for cross compilation.
See http://forum.nginx.org/read.php?29,220607 where the issue has been recently discussed.
I ran ./configure for my ia32 Linux host, and built it (to make sure it worked), then
1) deleted all object files,
2) edited objs/Makefile to change the value of CC, add include paths for my compiler and library paths for my linker
3) copied some header files from /usr/include to a local directory
There is a problem in that if /usr/include is in the search path, it is searched before the header files for my compiler. This became a problem when x86 assembler instructions were pulled into the definition of htonl().
An alternative is to hack conf/cc/gcc to add an option and do configurations there, includeing supporting a shell variable of CROSS. I haven't done that yet.
Have you considered settng up QEMU - http://wiki.qemu.org/Main_Page and a lightweight image from linaro - http://www.linaro.org/. I have not tested this approach, but i can tell you that I have successfully compiled and running nginx on my Pandaboard ARM v7a.
I successfully cross-compiled nginx by first creating a config on my desktop machine (./configure --without-pcre --without-http_rewrite_module), then just editing the 'cc' command in /objs/Makefile to point to the correct gcc. The Makefile the configure produces is incredibly simple. Just make sure you have all your environment variables set properly as well (CC, LD, LIBS, etc)
I just build v 1.4.7 this way
./configure --with-ld-opt=-L/path/to/libfolder \
--with-cc-opt=-I/path/to/include --prefix=./nginx
make CC=arm-linux-gnueabi-gcc
make install
--prefix nginx installs everithing in ./nginx and one just need to move created nginx folder on device but has to start server from relative path.
./nginx/sbin/nginx
Related
I followed this guide and installed emscripten using emsdk and activated it.Then I configured my $PATH as instructed by the emsdk itself and also sourced emsdk-master/emsdk_env.sh.Now I can access both emcc and em++ in the terminal.The file ~/.emscripten is also present(this is the file that QtCreator will fetch to find the path of compilers for WASM).
The WebAssembly kit for Qt also has been installed by the Qt Maintenance Tool.
Now in the Kit configuration in the QtCreator I get this(QtCreator is opened via terminal after sourcing emsdk_env.sh):
It cannot determine the path of compilers by itself.
In the Compilers tab I manually added a compiler as follows:
But I get this error in the Kits tab after that:
What does that mean? What did I skip? Does anybody ever have the experience of doing this?
Also changing the compiler from em++ to wasm-32-wasi-clang++ or clang++ doesn't change anything.
By the way if I use that kit I get:
Error while parsing file whatever.pro. Giving up.
Project ERROR: Cannot run target compiler 'em++'. Output:
===================
===================
Maybe you forgot to setup the environment?
And please don't tell me that this question is the duplicate of this because it isn't(mine has more details) and there's no useful answer for that after 9 months at this time.
Any help is much appreciated.
Make sure you run:
emsdk install
and
emsdk activate
within emsdk folder, not from a relative path.
You have to setup the emsdk inside QtCreator => Preferences => Devices => WebAssembly. Afterwards the compiler should be auto-detected by Qt Creator.
I had the same problem and the solution was, that python was not correctly recognized.
In my case the symbolic link /usr/bin/python was not set
ln -sf /usr/bin/python3 /usr/bin/python
Afterwards the emsripten Toolchain is recognized automatically in QtCreator.
I'm trying to compile geany-plugins-1.28. The debugger plugin (the only one I need) gives the error:
debug.c:53:21: fatal error: vte/vte.h: No such file or directory
#include <vte/vte.h>
Clearly it needs to know where this file is located to compile. I found the vte.h file in the src directory of the main program geany-1.28. When running
sudo ./configure cflags=-I/home/pi/Desktop/geany-1.28/src
I get the same error about the missing header later trying to compile the debugger plugin.
I ran
./configure --help
to get all the flag options. The output is here
How do I get this to configure correctly so that it compiles. I need to compile the debugger version 1.28 myself because apt only installs 1.24 which I think has a bug because it crashes when I run my code with the error:
close failed in file object destructor:
sys.execpthook is missing
lost sys.stderr
CFLAGS is case-sensitive environment variable, so you should set it before running configure, not try to pass it as a command line argument. This variant:
$ export CFLAGS=-I/home/pi/Desktop/geany-1.28/src
$ ./configure
leaves CFLAGS set for current shell until you leave it. While this:
$ CFLAGS=-I/home/pi/Desktop/geany-1.28/src ./configure
sets variable only for current command, i.e. configure.
Some other issues:
You do not need sudo to configure and make. It is also unnecessary for make install if you set PREFIX to a path you have privileges to write to.
Does plugin's build system also builds all it's dependencies? If not, you may face linker errors a bit later.
Update:
I have tried to build debugger plugin and got rid of your error. It seems that vte.h coming with Geany is it's intrinsic, while the plugin requires full-featured file from the library. So I just installed vte and vte-devel from repos. Nevertheless, I got some other unrelated errors coming from Glib. I will not continue my attempts to build all this right now. Hope my effort will be helpful at least a little.
As in this answer stated, vte.h is not the file you are looking for. Install libvte(-dev) package on your system and rerun configure.
Just for the record: vte.h on Geany is a dummy to allow Geany to kind of dynamical enable vte or disable it depending on vte is installed on the system or not.
I am trying to build NetCDF4 from source on MacOSX. When I run ./configure I get the error:
checking for library containing H5Fflush... no
configure: error: Can't find or link to the hdf5 library. Use --disable-netcdf-4, or see config.log for errors.
I installed hdf5 before, and set the environment variables as:
LDFLAGS=-L/opt/local/lib
CPPFLAGS=-I/opt/local/include
In /opt/local/lib I have these files:
libhdf5.8.dylib
libhdf5.a
libhdf5.dylib
libhdf5.settings
libhdf5_cpp.8.dylib
libhdf5_cpp.a
libhdf5_cpp.dylib
libhdf5_hl.8.dylib
libhdf5_hl.a
libhdf5_hl.dylib
libhdf5_hl_cpp.8.dylib
libhdf5_hl_cpp.a
libhdf5_hl_cpp.dylib
And in /opt/local/include I have:
hdf5.h hdf5_hl.h
Why doesn't the configure script find the hdf5 library? I am happy to provide more information if needed!
EDIT:
My ultimate goal is to install netcdf4 for use as a Fortran module. I have tried installing everything through MacPorts, and it seemed to work, but when I tried to use it, the compiler told me that there was no netcdf.mod file, and sure enough there wasn't one to be found anywhere.
It turns out that just typing:
sudo port install netcdf-fortran
only installs the library files, but doesn't create a .mod file, which I guess is needed. So I found out that other people had the same problem, and the advice given was to install it with gcc44, which did create a .mod file, but then my compiler told me that the .mod file was built with a different version of gfortran and it couldn't be used, so that's why I am trying to build it from scratch, but if someone has a faster option, I would be more than happy to try it!
Ok, I finally figured it out.
I reinstalled netcdf-fortran with macports, then the .mod file suddenly appeared, I then had the problem, however, that when running gfortran, it would tell me that netcdf.mod was compiled with a different version of fortran than the one I am using. (Macports uses 4.8), so got gcc48 from macports and am using gfortran-mp-4.8 to compile now and it works.
Still don't know how to build all these things from scratch, but it works now at least!!!
Typically, I see this when there is a downstream dependency that cannot be fulfilled. The test program created by configure is finding libhdf5, but compilation is still failing because it cannot find something like libz or libszip, depending on how your libhdf5 was compiled.
If you check your config.log file and look for the error, it will probably tell you something along the lines of 'unresolved symbol'. This will give a clue as to which library is missing. If it is linking against the statically-built libhdf5, you may need to add the appropriate library usingLDFLAGS.
If you post the relevant portion of your config.log file, we may be able to help sort out what exactly is going wrong.
Sometimes it doesn't work in the configure parameters like
./configure --enable-shared --enable-fortran --enable-netcdf-4
CPPFLAGS=-I$home/apps2/include LDFALGS=-L$home/apps2/lib --prefix=$home/apps2
or doesn't work when export CPPFLAGS=-I$home/apps2/include in the open SHELL.
Maybe you can set the env vars CPPFLAGS and LDFLAGS in the .bashrc file (prior to the first two ways).
I'm trying to cross-compile libSDL version 1.2 for a custom made, debian based Linux system. The toolchain I'm using is already configured properly so that I just run gcc/g++ on my the desired code and the resulting output is compatible with the target machine.
When I run ./configure --help in the libSDL source directory, I see that I can basically just set some environment variables to point to my cross-compiler.
However, I also see the following options:
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
I looked into the configure.in, build-scripts/config.sub, and build-scripts/config.guess files but couldn't really figure out how it works.
Are these options required? If not, is it a good idea to use them? If it's a good idea to use them, how do I get a list of the possible values?
You should indeed set both of these.
Assuming your cross-compiler lives in /usr/x86_64-w64-mingw32 and that your system host is called x86_64-unknown-linux-gnu, you should configure it like so:
configure \
--prefix=/usr/x86_64-w64-mingw32 \
--build=x86_64-unknown-linux-gnu \
--host=x86_64-w64-mingw32
It's actually quite easy! :)
All,
My host supports Perl CGI scripts, how do I use a compiled CGI script on the host?
I tried setting execute permissions via chmod, but when I try and run it via the browser, I get a server error.
Thanks in advance for all help.
It's possible with a few restrictions:
You're compiling statically or don't have any external dependencies
You're using a glibc that's no newer than theirs
If you're compiling under gcc, you might also need to provide libgcc_s.so which might mean you need a LD_LIBRARY_PATH in which case you'd probably run your binary through a shell script.
You can check the dependencies on your binary with ldd. My recommendation is to compile statically with no dependencies on a system with a glibc at least as old as theirs.
NOTE: (1) above isn't strictly a requirement if you can set LD_LIBRARY_PATH and can run everything through a wrapper script, but things get much more complicated if you need such functionality.
perhaps i'm missing something, but the fact that your host supports "perl cgi" doesn't mean that they support "compiled cgi" (which i would presume is a C CGI program).
Some details about what the server error was would be helpful.