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
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.
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
I'm running Arch Linux. I ran a couple of OpenMP programs on this machine, both C and Fortran, never noticing anything strange or unexpected. The correct number of threads were always used.
Now I noticed that there is a package openmp available, which is not installed:
extra/openmp 3.9.1-1
LLVM OpenMP Runtime Library
What is the OpenMP Runtime needed for if OpenMP works without it?
This runtime library is meant for the LLVM compiler, I know that in Black Arch (a penetration testing version of the Arch Linux) have gcc installed by default so your programs must be using it instead of LLVM (or clang).And default gcc installations also install OpenMP.
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 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.