I'm developing and building applications for a various amount of platforms (linux x86, x86_64, arm, aarch64, sparc64, mips, powerpc, macos x86_64, freebsd x86_64, solaris x86_64 and of course Windows) and I was using a very old linux box (2014 Ubuntu) for all this cross-compilation.
I've recently decided that it was more than time to move to a more updated build environment as many tools were obsolete and could not be updated, so I've moved everything to a Ubuntu 22.04. All worked fine but then I hit the "glibc version hell" when I tried to run that on other boxes as glibc on that buildbox is 2.35.
So I've tried to get older glibc to compile and link against these as I'd really like to avoid linking everything static. But now, all the gcc that are build with Ubuntu have been with a "--with-sysroot=/" which, AFAII means I can't do anything. The --sysroot option is ignored by gcc which uses / for sysroot, no matter what.
I've seen a few answers saying "use old box to build" and that seems really insane to me. On my Mac or Windows, I can chose minimum (old) target platform, even if I build on W11 or Monterey. And obviously, the reason WHY I move to a new buildbox is to NOT use an old one and be stuck with obsolete tools :-).
I can probably use again ct-ng and rebuild all compilers, including native ones, but that seems really an overkill. Anybody with a better solution?
Thanks!
Seems that there is really no solution for what I'm looking for. I ended up almost re-inventing the wheel while trying to manually installing glibc. It was a faster option to use ct-ng and install cross-compilers from there, not using the stock ones provides with my distro.
Related
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.
I'm trying to install/update my clang from Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn) to clang version 3.3. I've downloaded the pre-compiled binaries into usr/bin/, as suggested by other posts (How can I update clang to 3.3 on Mac OS X 10.6).
The point of this installation/update is to be able to use C++ code (not written by me, and written for a newer machine OS 10.8.x) on my mac. I would preferentially use Xcode to update this, but unfortunately, Apple has not made the necessary version of Xcode available for free without a developer's subscription.
I've edited my PATH and LD_LIBRARY_PATH to include clang3.3/bin/ and clang3.3/lib, but I get an "Illegal Instruction" error and it's not clear to me why this is.
What I'd really like is to try the whole process again from the beginning with a step-by-step outline of the process, like is seen here (How to install clang pre-built binaries ubuntu 12.04), except for Mac OSX system, not Ubuntu.
I realize there are some previous threads that ask almost the same question, but I am asking specifically for these versions (and from a standpoint that includes very little experience installing via terminal/understanding pathways/etc.).
Thanks for any help.
I've been using clang successfully on Windows XP and Windows Vista using the 'experimental' builds for MinGW, but now that I try on my new Windows 7 64-bit laptop it simply crashes. Even if I just run "clang++" or "clang" it crashes, and I can't figure out how to get windows to give me more detailed crash info (I will edit that in if I can). I've redownloaded clang and reinstalled MinGW, and I've tried running clang.exe in compatibility mode, but it still doesn't work. This is the first time I am using it on 64-bit, I hope that's not the issue (if it is, I still have another computer I can use).
I've looked around and can't find anyone else having this same problem with clang crashing before even giving any output or processing any input, I really feel lost.
This has now happened multiple times on various system and I have found the solution. Reinstall MinGW using the prepackaged files, the 'latest' ones have a tendency to be unstable in relation to clang. Make sure you haven't also installed a newer version of gcc on top of the MinGW installation, as that will cause issues too.
I am trying to compile lanshark for mac, but do not know how to compile on mac. I am guessing that it is possible to compile linux source code on mac. if not how can i get this program to run?
A mac is, under the hood, a BSD 'darwin' box.
Go and take a look at the MacPorts webpage. You'll find lots of interesting information (like where to get a compiler etc ) there.
Another place to go for an apple development environment is apple (xcode) ...
It should be possible to get that to run, but it will be a bit of work. The source may need a small amount of modification, depending on exactly how the protocol works (if they're using raw ethernet, that is done quite differently). Also, the OS X linker (ld) works completely differently to the Linux linker, and so the build system will need a bit of tinkering.
However, the compilers and build utilities are in the XCode bundle on your install disk, or at the download link in the other answer, so install that and give it a go. If you're lucky, just following the Linux instructions will build it.