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! :)
Related
I am trying to cross compile GhostPDL-9.06 (this and any higher version). I intend to use pcl6 on a MOXA arm9 linux computer. The provided tool chain compiles fine. However, the binary ends up running on the build machine instead of the target. It seems I am not doing something right with the arch.h file. There are cross compiling instructions at the bottom of the page http://ghostscript.com/FAQ.html. They are a bit vague for my level of experience. I have searched far and wide and found more instructions at the top of the page by jroo at http://ghostscript.com/irclogs/2014/03/12.html but I still get stuck.
My configure command is:
./configure CC=arm-linux-gcc CCLD=arm-linux-gcc CCAUX=gcc --host=arm-linux --target=arm-linux --without-x
the libtiff configuration errors but after the make, I still end up with a pcl6 binary that functions fine only on the ubuntu i686 machine.
I am stuck on the "manually generate arch.h"
Does someone have any details on cross compiling that provides a few more instructions?
I now have a pcl6 binary that was cross-compiled and runs on a MOXA ART ARM9 32-bit RISC CPU. At least the features I need are working.
Here is the command line to create a password secured pdf file with 62 lines per page:
./pcl6 -J'#PJL SET FORMLINES=62' \
-dNOPAUSE -sDEVICE=pdfwrite \
-sOwnerPassword=yourpassword \
-dEncryptionR=3 -dPermissions=-3884 \
-sOutputFile=yourfile.pdf yourfile.pcl
I am not completely sure why I got the cross-compiling to work, but it did and here is how I cross-compiled ghostpdl-9.14:
As before, I still pass the configuration parameters:
The main problem was creating the make files because the configuration would not complete. The libtiff configuration would error. I edited the shell script file "configure" in the top directory of the ghostpdl-9.14 folder. On line 5255, I replaced the "$SUBCONFIG_OPTS" with "
CC=arm-linux-gcc CCLD=arm-linux-gcc CCAUX=gcc --host=arm-linux --target=arm-linux --without-x
I did this because for some reason, the libtiff configuration would would not receive the parameters from the main configuration.
After this edit, the libtiff configuration would finally start and run towards the end. But, there was still an error regarding the BIGENDIAN test. So I replaced the lines 5716 through 5719 with a message
$as_echo "Ignore BIGENDIAN Test";
As a result, the configuration completed and created the necessary make files.
After making the two edits to the "configure" file, run the configuration command (from the top ghostpdl-9.14 directory):
./configure CC=arm-linux-gcc CCLD=arm-linux-gcc \
CCAUX=gcc --host=arm-linux --target=arm-linux --without-x
After the configuration completes, pass the cross-complile requirements with the make command:
make CC=arm-linux-gcc CCLD=arm-linux-gcc CCAUX=gcc
Maybe this isn't necessary, but since it worked, I am posting it.
My first test was to see if the build computer ran the pcl6 binary. Once the message "cannot execute binary file", I knew that I had some partial success. After transferring it to the ARM9, and running pcl6 with no options, the terminal screen provided the help information which told me the binary was successfully compiled.
After hours upon hours of searching and experimenting, perhaps this may help someone with the same goal.
Cheers!
I am trying to install octave on my machine (Scientific Linux 6.4 based on red hat) without having root access. After running the following:
./configure CPPFLAGS="-I/some_stuff/user_name/bin/pcre-8.32/include" LDFLAGS="-L/some_stuff/user_name/bin/pcre-8.32/lib"
(I had to install pcre apriori; before I got errors re: pcre), I get a message along the lines:
configure: error: You are required to have BLAS and LAPACK libraries
Now LAPACK has just been made in $HOME/bin/lapack-3.4.2 yet the same error is still there. Also $HOME/bin is part of the path.
Any way to tell the configure tool for octave about this? (the obvious thing of adding another CPPFLAG/LDFLAG does not work). I'm assuming I'll encounter more such issues along the way, so any generic help/hint is greatly appreciated.
My level of linux is rudimentary to say the least, but I'm willing to work through it.
Thanks,
Dan
Does this site shed any light on the problem? It describes the configuration options.
http://www.gnu.org/software/octave/doc/interpreter/Installation.html
First, you should rather ./configure all your software with some common prefix, such as --prefix=$HOME/soft/
Unless you know well what you are doing, I recommend against having different prefix for each installed software. You could add $HOME/soft/bin to your $PATH
And you should configure and build all the dependencies before configuring octave (and that includes BLAS, LAPACK and their dependencies).
Then, you want to pass specific configuration options, perhaps like --with-blas=$HOME/soft
I think you should pass the prefix used when configuring BLAS; you may want to run ./configure --help first.
Read carefully each package's installation instructions. For Octave, they are here. Each package has their own.
Some software may require you to configure and build outside of their source tree!
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
I am building a Linux system with cross-compiler using ptxdist. It allows me to configure Qt4 for installation and it builds and installs qt-everywhere-opensource-src-4.6.3 Ok. However, the qmake internal settings are screwed up and I don't know how to fix them.
When I run qmake -query I get:
me#ubuntu:~$ qmake -query
QT_INSTALL_PREFIX:/
QT_INSTALL_DATA:/
QT_INSTALL_DOCS://doc
QT_INSTALL_HEADERS://include
QT_INSTALL_LIBS://lib
QT_INSTALL_BINS://bin
QT_INSTALL_PLUGINS://plugins
QT_INSTALL_TRANSLATIONS://translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES://examples
QT_INSTALL_DEMOS://demos
QMAKE_MKSPECS://mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.6.3
Through some research, it looks like this can be fixed by simply rebuilding Qt, but it's not fixing this problem. I dug into the build output a bit and it looks like the ./configure command for the Qt build has "-prefix /usr" so I don't know why this isn't being fixed.
I would like to fix these internal values manually if possible because the Qt build takes hours. Does anyone know how to do this?
At configure time these paths are hardcoded in 'src/corelib/global/qconfig.cpp', and end up hardcoded into qmake when it is built. They are also hardcoded into many other files, like all the .la and .pc files, not to mention the Makefile install rules.
The only way to fix this is to figure out why configure keeps screwing up the prefix. configure is a big shell script, so it's easy to see where $QT_INSTALL_PREFIX is assigned from the '-prefix' argument, and then the different checks that are done on it (like running it through 'config.tests/unix/makeabs'). Try putting print statements before/after $QT_INSTALL_PREFIX is changed, and you should be able to find out where the path gets screwed up.
Also, you don't have to wait for the full build to complete to tell if the prefix was set
correctly. After configure runs, take a look in 'src/corelib/global/qconfig.cpp' and see what 'qt_configure_prefix_path_str' is set to.
You can manually set these properties using
qmake -set VARIABLE VALUE
They are stored using QSettings, the Qt built-in persistent applications settings.
see Configuring qmake's Environment
Configure scripts can be fuzzy about slashes. Are you sure that the build prefix is /usr and not /usr/ .
I have found a simulator called ntpdsim for NTP: http://www.eecis.udel.edu/~mills/ntp/html/ntpdsim_new.html
I canot figure out on what OS I can use it. On the page there is no download content. So I thought it is integrated in the NTP package.
I have tried Ubuntu and Opensuse. On both I have installed NTP, but there is no program called ntpdsim.
How can I use this tool?
ntpdsim is indeed part of the ntp source tarball, however apparently not included in the distribution packages you cite.
When compiling from source, you need to run ./configure with --enable-simulator to build/install it. That's at least what ./configure --help says.
Check ./configure --help to see if there's a build option you need to enable.
I think this is what you're looking for : http://doc.ntp.org/4.2.2p1/ntpdsim.html