Hey everybody, i am deploying my code from a cluster running on ubuntu onto a cluster with identical hardware, but with red hat and as it seems older gfortran compiler. The source is actually compiled by ifort, but since it is not installed on the red had cluster, i may have to switch to gfortran.
Now the problem is that the code does not compile. There is this thing with "allocatable" inside a type that i could fix in my portion of the code, but there are also other contributions by other people not as ready to adapt their code to the older standard.
My question :
How do i deploy nonetheless onto the other system, hopefully without changing much?
What other surprised wait for me when using the compile from the same version, just different subversion?
How do i enforce that something like this does not happen again? The code should be deployable onto a variety of systems without resorting to violence.
Thanks for your advice and cheers
gfortran started with version 4.0. Versions 4.1 and 4.2 are old and missing many features and may have bugs. You may run into additional missing features that are used by your code. I suggest, if at all possible, getting the compiler upgraded to the current stable version, which is 4.5.
Supporting all versions of gfortran will lead to many restrictions on your code. It might be better to identify the earliest version that works and add that information to the documentation. For my code, that version is 4.3 since I make extensive use of the ISO C Binding.
The gfortran wiki, http://gcc.gnu.org/wiki/GFortran, has a changelog by version that might help you identify which version you need. The only sure way is to test.
If you want to enforce a version requirement, you can test from within Fortran. You could run a small test program as part of the make process and abort if the gfortran version is too early.
The following code fragment shows two ways of outputting the gfortran version number from a Fortran program. Name the program with filetype ".F90" so that gfortran will invoke the preprocessor.
#ifdef __GFORTRAN__
write (*, '( "gfortran" )' )
write (*, '( I0, ".", I0 )' ) __GNUC__, __GNUC_MINOR__
! Merged version number:
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
write (*, '( I0 )' ) GCC_VERSION
#endif
I think you have 3 choices:
Cross-compilation: ie compile on
your development machine for
execution on your deployment
machine; I don't know if this is
possible with your setup but it is
worth investigating if you haven't
already done so.
Program to the set of Fortran features implemented in all your compilers -- which would mean re-writing the code to take out whatever features 4.2.3 implements that 4.1.2 doesn't.
Upgrade the compiler on your deployment machine to match the one on your development machine.
Of these I think that (1) might be difficult; if it is then I'd go for (3). If that is not possible, then it has to be (2) -- I don't see any other options.
Now to answer your questions:
Answered above.
Not sure, but the release notes for Gfortran should tell you what Fortran language features 4.2.3 implements which 4.1.2 doesn't.
Only program with the version of Fortran for which you can compile on your target platforms.
Related
My professor is using automated scoring program for my programming assignment. It is C programming handling some file stuff.
He asks students to use Ubuntu version 18.xx and gcc 7.xx. and I asked him if I can use the later version of those, which are 20.xx, 9.xx respectively. and he's not so sure about it with saying that might not be the problem but just in case use the exact version.
I don't want to delete the current Ubuntu, gcc and re-downloaded the exact version he mentioned, because it might take some time and I have to keep using this laptop for many more assignments from other classes. I want to use the later version (seems like quite a big gap between 18.xx, 7.xx and 20.xx, 9.xx)!
Are there any potential problems for using my current version?
It would also be possible to check the default standard of the gcc version used by your teacher and use the corresponding std flag : "-std=c11" for example.
(I'm unfortunately in a rush and can't check it yet but when I have more time, I can try to look it up if you still didn't get the information)
It may also be possible that he already uses a specific standard, in that case it's better to ask him.
Bugs might arise but I think it would be pretty negligible if you use the same standard.
Otherwise if you are using a Debian based distro you can also install his gcc version alongside your actual one and use them with "update-alternatives".
If not you can use a Docker container.
Something to look for is also if you are going to use OS specific library or functions : For example Windows is not POSIX compliant so I had to use WSL but linux (and mac aswell if I remember correctly) are.
I heard that GCC actually assumes registers, and requires CPU to have them to work.
What work should be done to remove this dependency, and port GCC to some register-less non-Von Neuman arch, like Multiclet?
Did somebody tried this? Is there some project and experience one can use if wants to work on this ?
If not, is there some other FOSS compiler that can be ported to something like Multiclet. LLVM has pretty much the same requirements like GCC, and it is unsuitable for me since I don't know C++. So it needs to be plain C. I hear that GCC is also adding C++ code now. But I can use some older version as starting point.
Multiclet's C99 compiler is not closed source. Sources are available at their community suite. One may google it by name 'multiclet mcc lime'.
It seems I've got a real problem here due to my lack of any knowledge about Linux systems:
I have downloaded some open source code, which
is written in C
uses complex.h, so I assume it is ANSI C99
comes with makefiles designed for compilation under Linux systems
provides interfaces to IDL, MATLAB, Python etc.
I am indeed familiar about compiling C/MEX files under Windows-based MATLAB environments, but in this case I don't even know where to start. The project is distributed in several folders and consists of dozens of source and header files. And, to begin with, the Visual Studio 2010 compiler I've used to compile MEX files until now does not comply with the C99 standard, i.e. it does not recognize the complex.h header.
Any help towards getting this project compiled would be highly appreciated. In particular, I have the following questions:
1) Is there any possibility to automatically extract compilation information from the MEX files and transfer it to Windows reality?
2) Is there any free compiler being able to compile C99 stuff, which is also easy to embed in MATLAB?
I have done this (moved in-house legacy code inc. mex files to Win64). I can't recommend the experience.
You will have to recompile, no way around it.
Supported compilers for mex depend on your MATLAB version
This File Exchange entry for using Pelles C may be a starting point (if it works with your version of MATLAB).
I am guessing that there is a main makefile which then works through the makefiles in the subdirectories - have a read through the instructions for compiling under Linux, it will give you some idea of what's going on and may also discuss what to do if you want to change compiler. Once you've found a compatible compiler, the next stage is to understand what the makefiles are doing and edit them accordingly (change paths, compiler, compiler flags, etc.)
Then, from memory (it was a while ago), you get to enjoy a magical mystery tour through increasingly obscure compiler errors. Document everything because if you do get it working, you won't be in a mood to do this twice.
MATLAB R2016b on Windows now supports the MinGW compiler. I'm successfully using this to compile code written primarily for Linux/gcc. I installed this from the Add-On menu in MATLAB (search MinGW).
For my case, I'm building with the legacy code tool. The only thing I needed to do differently than normal was to tell the compiler to support c99 via a compiler flag. This does the trick:
legacy_code('compile', def, {'CFLAGS=-std=c99'})
I had trouble getting the flag command just right (I had some extra quotes that apparently broke things), and asked The MathWorks, so credit is due to their support team for this.
If you are using mex, I would expect to do something very similar.
I would guess that the makefiles are irrelevant for your application; you will need to tell the mex or legacy_code function about all of the files necessary to build the whole application or link against pre-built libraries (which it sounds like you don't have).
I hope this helps!
Sorry if this is an obvious question, but I've found surprisingly few references on the web ...
I'm working with an API written in C by one of our business partners and supplied to us as a .so binary file, built on Fedora 11. We've been testing out the API on a Fedora 11 development machine with no problems. However, when I try to link against the API on our customer's target platform, which happens to be SuSE Enterprise 10.2, I get a "File format not recognized" error.
Commands that are also part of the binutils package, such as objdump or nm, give me the same file format error. The "file" command shows me:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
and the "ldd" command shows:
ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1'
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1)
[dependent library list]
I'm guessing this is due to incompatibility between the C libraries on the two platforms, with the problem being that the code was compiled against a new version of glibc etc. than the one available on SuSE 10.2. I'm posting this question on the off chance that there is a way to compile the code on our partner's Fedora 11 platform in such a way that it will run on SuSE 10.2 as well.
I think the trick is to build on a flavour of linux with the oldest kernel and C library versions of any of the platforms you wish to support. In my job we build on Debian 4, which allows us to officially support Debian 4 and above, RedHat 3,4,5, SuSE 10 plus various other distros (SELinux etc.) in an unofficial fashion.
I suspect by building on a nice new version of linux, it becomes difficult to support people on older machines.
(edit) I should mention that we use the default compiler that comes with Debian 4, which I think is GCC 4.1.2. Installing newer compiler versions tends to make compatibility much worse.
Windows has it problems with compatability between different realeases, service packs, installed SDKs, and DLLs in general (DLL Hell, anyone?). Linux is not immune to the same kinds of issues.
The compatability issues I have seen include:
Runtime library changes
Link library changes
Kernel changes
Compiler technology changes (eg: pre and post EGCS gcc versions. This might be your issue).
Packager issues (RPM vs. APT)
In your particular case, I'd have them do a "gcc -v" on their system and report to you the gcc version number. Compare that to what you are using.
You might have to get hold of that version of the compiler to build your half with.
You can use Linux Application Checker tool ([1], [2], [3]) in order to solve compatibility problems of an application between Linux distributions. It will check your file formats and all dependent libraries. It supports almost all popular Linux distributions including all versions of SuSE and Fedora.
This is just a personal opinion, but when distributing something in binary-only form on Linux, you have a few options:
Build the gamut of .debs and .rpms for every distro under the sun, with a nominal ".tar.gz full of binaries" package for anything you've missed. The first part is ideal but cumbersome. The latter part will lead you to point 2 and 3.
Do as some are suggesting and find the oldest distro you can find and build there. My own opinion is this is sort of a ridiculous idea. See point 3.
Distribute binaries, and statically link where ever you can. Especially for libstdc++, which appears to be your problem here. There are seemingly very many incompatible versions of libstdc++ floating around, which makes it a compatibility nightmare. If you can't link statically, you can also put *.so files alongside your binary, and use stuff like LD_PRELOAD or LD_LIBRARY_PATH to make them link preferentially at runtime. Note that if you take this route you may have to comply with LGPL etc. since you are now distributing other people's work alongside your project.
Of course, distributing your project in source form is always preferred on Linux. :-)
If the message is file format not recognized then the problem is most likely one mentioned by elmarco in a comment -- namely, different architecture. It might (I'm not sure) be a dynamic linker version mismatch, but that would mean the .so file was built with an ancient dynamic linker. I do not believe any incompatibility in libc could cause this -- they could cause link failures and runtime problems (latter very rarely), but not this.
I don't know about Suse, but I know fedora likes to stay on the bleeding edge. So you may very well be right about library versions. Why don't you ask and see if you can get the source code and build it on your Suse machine?
The product-group I work for is currently using gcc 3.4.6 (we know it is ancient) for a large low-level c-code base, and want to upgrade to a later version. We have seen performance benefits testing different versions of gcc 4.x on all hardware platforms we tested it on. We are however very scared of c-compiler bugs (for a good reason historically), and wonder if anyone has insight to which version we should upgrade to.
Are people using 4.3.2 for large code-bases and feel that it works fine?
The best quality control for gcc is the linux kernel. GCC is the compiler of choice for basically all major open source C/C++ programs. A released GCC, especially one like 4.3.X, which is in major linux distros, should be pretty good.
GCC 4.3 also has better support for optimizations on newer cpus.
When I migrated a project from GCC 3 to GCC 4 I ran several tests to ensure that behavior was the same before and after. Can you just run a run a set of (hopefully automated) tests to confirm the correct behavior? After all, you want the "correct" behavior, not necessarily the GCC 3 behavior.
I don't have a specific version for you, but why not have a 4.X and 3.4.6 installed? Then you could try and keep the code compiling on both versions, and if you run across a show-stopping bug in 4, you have an exit policy.
Use the latest one, but hunt down and understand each and every warning -Wall gives. For extra fun, there are more warning flags to frob. You do have an extensive suite of regression (and other) tests, run them all and check them.
GCC (particularly C++, but also C) has changed quite a bit. It does much better code analysis and optimization, and does handle code that turns out to invoke undefined bahaviiour differently. So code that "worked fine" but really did rely on some particular interpretation of invalid constructions will probably break. Hopefully making the compiler emit a warning or error, but no guarantee of such luck.
If you are interested in OpenMP then you will need to move to gcc 4.2 or greater. We are using 4.2.2 on a code base of around 5M lines and are not having any problems with it.
I can't say anything about 4.3.2, but my laptop is a Gentoo Linux system built with GCC 4.3.{0,1} (depending on when each package was built), and I haven't seen any problems. This is mostly just standard desktop use, though. If you have any weird code, your mileage may vary.