I'm working on an Arduino project which was being developed on a Windows machine with the Arduino Builder. After having a release candidate, I started developing a Linux docker container that would automatically compile this project once it was pushed to my git remote. However, I noticed that the compiled binary from the Linux container is different from that of the Windows machine, in-spite of the same Arduino version and compilation flags. Is this supposed to happen? Shouldn't AVR-GCC make an equal cross-compilation result?
Thanks in advance.
Ok, so after having dug deeper into this issue and confirmed that the toolchains had the same versions (despite the different host OSs), I found out that on Linux I was not giving the linker the -flto flag for enabling the link-time optimizer, while doing it on Windows.
So all in all, there was indeed a configuration error on my part, and the code now runs smoothly when compiled on both host OSs.
Related
I'm trying to cross-compile a C/C++ program for Windows on Linux.
I've gotten to the point where everything compiles properly, except that x86_64-w64-mingw32/bin/ld is called with the option -lpthread, which doesn't work.
I'm not sure why it's called with that option, because I'm 100% certain that there are no references in the code to threads except through CreateThread, which is part of the Windows API. There's no good reason for mingw to try to link in pthreads if I'm not using them, right?
(Fedora 32 but 64-bit, if it helps.)
There is no way to teach the GCC compiler driver to drop "-lpthread" if the compiler was configured to include pthread support.
I guess you are trying to do a static build (?) and the libpthread.a is not installed by your toolchain.
See a related bug report # https://bugzilla.redhat.com/show_bug.cgi?id=2070571
My question is about whether if it would be possible to run a compiled perl 5.28.0 from source (with GCC 4.8.5 on CentOS 7) to be able to be used on RHEL 5.5 (Tikanga) where GCC version is lower and so would be the other libs like libc, glibc, etc.
Our production environment is running very old perl version (5.8.8) and due to security concerns, it is under heavy lock down, i.e. most of our servers lack make, gcc and related tools and there is no root access available to anyone
I was wondering if it would be possible to compile perl from source i.e. latest 5.28.0 with GCC 4.8.5 AND try to use this compiled version on our production servers (with GCC 4.8.2).
This will save me tonnes of headaches with slow bureaucracy and I can get going with my project with the new tools.
Have not been able to find any discussion or hint about this subject. Can anyone shed some light?
Thank you in advance.
Update after 2 days:
As it seems Perl 5.28 compiled on RHEL7 does not work on RHEL5.5. You will have to compile it on RHEL5.5 and make it relocatable for further usage on any server.
So I Downloaded the RHEL 5.5 and CentOS5.5 ISOs and ran into bootable iso related issues.
Couldn't make a suitable bootable disk for both rhel 5.5 and centos5.5.
rhel5.5 iso was a single dvd image and upon doing file rhel5.5.iso on command prompt, it showed bootable. tried unebootin, rufous iso creator, dd command and created ISOs and tried all of them one by one, but couldn't get it to show boot menu. tried FAT, NTFS FS while making boot disk. Stuck here now.
Centos5.5 iso came in 8 pieces of 600mb files. Had to create a single iso image out of it and found some online procedure to do it and made one ISO file. Got boot menu and looked like it worked. But then it got hung up on doing some sort of source media check test and couldn't proceed further. Found a fix related article that you imprint md5sum on iso and it should work but it didn't.
Just now found something on grokbase and it mentions a new technique, that could take me forward from the point of failure mentioned in point no.3 above.
Edit: static compilation bypasses the problems you are cautious about. You need to figure out whether the result is suitable for your intended purposes.
Otherwise you contend with traditional compilation like you had planned. If the libc is too different, it won't work. You could certainly just go ahead and try, then you'll know for certain.
The real solution is to set up a copy of your production environment (can be in a virtual machine) and compile stuff there.
You could try PerlApp + ActivePerl from ActiveState.com (maybe a part of PDK, Perl Development Kit). I've used it for many years. It compiles perl source and include modules (compiled modules also) into a .exe-program file on Windows and a binary executable file on Linux. There is a payed version and a free/demo version. The payed version allows for cross-compilation and more versions of Perl if I remember correctly.
You might run into trouble with differing versions of glibc/libc on dev vs prod computer, so try to use PerlApp on a CentOS 5.5 Linux (free) for compilation. CentOS5.5 resembles RHEL5.5 enough for most projects. Good luck.
Try perlbrew (is an admin-free perl installation management tool)
I was following instructions here and here to build a toolchain which would work on Windows and compile applications for Linux and different hardware platforms. At first I tried to create cross-compiler for i686-linux to test it on a generic Debian 8 system.
Binutils and GCC compiled fine, but I got stuck at Glibc. It told me:
*** The GNU C library is currently not available for this platform.
I see that Sysprogs toolchains are using Newlib instead of Glibc but I haven't found any explanations except that Newlib is a good choice for embedded devices.
Does it mean that Newlib is actually the only choice for Windows -> Linux and that there is no way to compile software which depends on Glibc? Maybe there are "cheats", like copying pre-built Glibc from the target platform or some other workaround?
In theory, I don't even need Glibc built on Windows, I need just some "Glibc compatible stub" built for the target architecture to link (only dynamically, of course) against while compiling for the target platform and OS. Or am I totally wrong here and GCC cannot link to a different C library than GCC itself was linked to?
Or should I forget it and accept the fact that it is impossible (and, most probably, never will be possible) to achieve full Glibc and Linux kernel compatible C/C++ cross-compiling from Windows to GNU/Linux?
I will accept the answer which explains how GCC and Glibc are related and whether it is possible or not to link against Glibc different from C library used when GCC itself was built, and provide some insight about why it is / is not possible.
my guess is you're using --target when building glibc when you really need to use --host (which is different from how newlib is configured -- best to not ask why).
that said, the glibc build system requires a case-sensitive file system as it creates files like foo.oS and foo.os which are very different things. on a system like Windows, that means the build will be corrupted and fail since foo.oS and foo.os refer to the same file. there are patches out there to hack around this, but really you'd be better off booting a VM and doing the toolchain build inside of that.
NB: i'm not saying you need the VM to do all your development. you just need the VM to build the cross-compiler which you'd then run under Windows. this would be a canadian cross build.
rather than do all this yourself by hand, please check out crosstool-ng. it handles/patches/fixes a lot of common errors people make when trying to create cross-compilers.
The binaries for Linux, OSX, and Windows are all embedded in the sqlite-jdbc.jar...
org/sqlite/native/Linux/amd64/libsqlitejdbc.so
org/sqlite/native/Linux/i386/libsqlitejdbc.so
org/sqlite/native/Mac/i386/libsqlitejdbc.jnilib
org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib
org/sqlite/native/Windows/amd64/sqlitejdbc.dll
org/sqlite/native/Windows/x86/sqlitejdbc.dll
My problem is, that while I'm running Linux, I am not on amd64 or i386. The Raspberry Pi is ARM. Where can I get a sqlite-jdbc.jar with the ARM binaries embedded?
A lib provided by someone who claims to have build it: https://bitbucket.org/xerial/sqlite-jdbc/issue/79/compile-for-arm
Instructions for build https://pidome.wordpress.com/2013/10/01/java-goes-hard-on-the-raspberry-pi-so-does-pidome/
and
Error opening connection SQLite on Raspberry pi
#dacracot
I'm not sure if i'm prohibited by offering help this way but:
I have the library available when you would download the whole PiDome server package.
For convenience, and multiple requests i have added it as a separate download. The library has been compiled against the hard float abi and is currently using sqlite-jdbc-3.7.15.
The jar file contains the default supported platform libraries and has the arm support added.
It is available at: https://bitbucket.org/pidome/pidome-server/downloads
I've written a program which uses a lot of the new features in C++11. I wrote it on MacOS X, it compiles and runs fine with Apple Clang, Boost 1.5* and libc++ (assumption, as opposed to libstdc++). The program is for personal use and it won't need to be deployed on more than a few servers.
I shipped the production server to its overseas location with CentOS 6.5 installed. So I built a dev server with CentOS 6.5 installed. Pushed my code up to the dev server, used the package manager to get everything I thought I needed and then tried to compile - only to be bitterly disappointed.
Problem: I think the Clang version from EPEL is fine. However it wasn't playing nice with libstdc++ provided by the base repo - CentOS 6.5 is only up to GCC ~4.4. For example, I couldn't get GTest to compile. So I searched around and found a repo called the devtoolset-2 which had GCC ~4.8. It was made clear that this repo should only be used for testing purposes. Using the libstdc++ from this worked much better. However, now I was having a few boost problems - as the base CentOS 6.5 repo is only up to ~1.44. I've been trying to get 1.55 installed but failing... tried from repos and building myself but I'm guessing other dependencies are still out of date - e.g. Binutils. Either way it had all been a big mess.
I think moving the dev server to CentOS 7 would make things much easier. However, it is not going to be easy to move my production server over.
Basically I'm looking for advice. Can I build on CentOS 7 and copy the required libraries over to the production server? And what are the potential pitfalls of this? Should I statically link everything - including libstdc++? Or are there any other suggestions - apart from moving the production server to CentOS 7 (which I'll try do if I absolutely need to).
If you think this is not a 'stackoverflow' question please let me know.
Thanks.
John.