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
Related
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.
The Windows binary distribution of the Linaro gnu AARCH64 ARM cross compiler (based on mingw) has a dependency on a library libwinpthread-1.dll. When I run .\aarch64-elf-gcc.exe --version I get a pop-up that says
The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
For the life of me I can't seem to find anything about this library, where to find it, build it, etc. Based on the name it seems obvious that it is some pthread library for windows, but maybe not. The cross compiler is a 32-bit Windows binary for a 64 bit ARM target. The host is 64-bit Windows 10.
Any idea where I can find a 32-bit version of libwinpthread-1.dll?
The latest version of the tool chain at
https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/aarch64-elf/
seems to not have this problem of a missing dll
It can be found in
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf\libexec\gcc\aarch64-elf\6.1.1\libwinpthread-1.dll
Ed
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 need to compile an old (1992) fortran code. This code run in some SGI IRIX workstation and it was originally compiled with f77. I get errors if I try to compile it with gcc (g77) on my macbook pro or in a ubuntu virtual machine. I wonder if there is some way to get the old f77 compiler (virtual machine, whatever). f2c does not work at all.
Unless it is the case of some vendor extensions which modern compilers do not support (extremelly rare), I don't see why F77 code compilation & build should present any problem at all. Fortran IV or older, maybe, but F77 (within reasonable bounds) should work without much problems.
However, it is hard to suggest anything but a mere list of compilers available without knowing anything about it. The details of the code, the errors that you got, the compile options ... (?)
Please, post some more details.
I sucessfully compiled some fortran77 source code from ~1992 with the Openwatcom Fortran compiler:
http://www.openwatcom.org/
more fortran compilers:
http://www.fortran.com/compilers.html
I'm trying to compile Redis for Windows x64 with no luck.
I tried different things
Cygwin works perfectly but GCC produces only 32 bit executables
Compling with Mingw-w64 will not work without a lot of code changes (My understanding is that MinGw does not provide POSIX compatibility for Windows)
Microsoft Services for Unix has an outdated GCC version and requires the Unix subsystem to be installed as a dependency
Any idea?
Ruling out MSU, there is no POSIX compatibility layer for Win64. Your best bet is probably on working with mingw-w64 and provide yourself fallback Win32/Win64 code for the POSIX calls you need. That's painful, of course.