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!
Related
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.
For some reason the menuconfig menu does not come up when I try launching it from my Yocto installation. I am using the Toradex Yocto 1.6 system as is described here http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/openembedded-%28core%29, with my board set to "apalis-t30". When I run either bitbake virtual/kernal -c menuconfig or bitbake linux-toradex -c menuconfig, it executes fine but finishes (without erros) before actually showing anything. Running devshell also gives the same results.
If I just use the kernel sources on their own as is described here http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/build-u-boot-and-linux-kernel-from-source-code, I can get menuconfig open using make nconfig. From the Yocto scripts it appears as if though the exact same kernel sources are being used. If I try adding adding make nconfig to the do_configure_prepend script in the linux-toradex_git.bb file then the commands get stuck stating that the process (I assume menuconfig) is running and then provides a PID for it, but no window or menu is displayed anywhere and the task does not seem to finish.
PS. I am on Fedora 21 64-bit.
EDIT:
I have now checked the default Yocto image and menuconfig comes up fine there. I am assuming that the Toradex BSP is not entirely compatible enough with Yocto for this to work out of the box. I have spoken to Toradex and they have told me that I should instead fork their kernel, modify it the normal way in my own repo and then tell the script to pull from my modified repo. I guess this could work but its a bit of a hassle and I would like to fix their Yocto system. I am assuming that this cannot be to hard as running make nconfig is usually enough, I just can't figure out how to get that command working with bitbake.
This should work fine with the meta-toradex layer. In the local.conf file, comment out the INHERIT += "rm_work" line:
#INHERIT += "rm_work"
Then do a full build of the kernel:
MACHINE=apalis-t30 bitbake virtual/kernel
Then try menuconfig now that all the sources are in place:
MACHINE=apalis-t30 bitbake -c menuconfig virtual/kernel
If you are using Ubuntu, try to reconfigure system shell to bash instead of dash(that is default for Ubuntu):
$ sudo dpkg-reconfigure dash
press "No" when prompted.
Actually I got the same problem few times. In one case shell reconfigure helped me.
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! :)
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'm trying to modify GTK2 on Ubuntu Oneiric.
I download the source:
apt-get source libgtk2.0-0
cd gtk+2.0-2.24.6/
I try to compile and overwrite the current GTK2:
./configure --prefix=/usr
sudo make
Soemhow I get an error (I have all the necessary libraries and the build-essential package etc):
In file included from gtkquery.c:26:0:
gtkquery.h:31:2: error: #error "gtkfilechooserprivate.h is not supported API for general use"
By the way, I am able to modify and recompile GTK3 with no problems with the same steps.
If use debuild, I get thousands of
dpkg-source: error: cannot represent change to gtk+2.3.0-2.24.6/gtk+2.0-2.24.6/something: binary file contents changed
You won't get anything near the Ubuntu-provided build if you try building it by hand that way -- you'll miss all the ./configure options and other settings. (Look into debian/rules for the full details of what they're setting.)
Instead, try debian/rules build.
For reasons I haven't investigated yet (possibly including me not understanding how it should work), that didn't work on the first package I tried, but setting up pbuilder let me build the package I wanted.
It might feel like overkill to get a clean chroot as a build environment, but it is way too easy to build yourself problems that no one else in the world can replicate because you've got something funny on your local system.