I'm working with a very large piece of mortran code. I'm trying to compile it on my own machine, and the mortran part goes ok, but the fortran compile fails.
On both machines I'm using gfortran with the same flags (-fPIC).
Machine 1:
Linux [omitted] 2.6.18-194.3.1.el5 #1 SMP Fri May 7 01:43:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux with gfortran 4.1.2 (Working - very old kernel)
Machine 2:
Linux [omitted] 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux with gfortran 5.4.0 (Not working)
The error (most of the time) I'm getting is:
Error: Invalid character in name at (1)
ExIN=$ExDEF
1
There's also a few errors about var has no implicit type.
I don't have much experience with fortran, but I'd expect compilers to be consistent across platforms, especially since this was developed with the intent of being cross-platform.
Edit - it looks like I had a different version of the mortran compiler. I'm going to try to find the old version and see if that does it. They are mortran macros and they are supposed to expand to something.
Dollar is not a valid character of the Fortran character set.
Some compilers allow it by extension. To allow it in GNU Fortran, but not as first character and only if the target system supports it, use
-fdollar-ok
See https://gcc.gnu.org/onlinedocs/gfortran/Naming-conventions.html
Looks like you are out of luck with this compiler.
You may try g77 with the same option, see https://gcc.gnu.org/onlinedocs/gcc-3.4.5/g77/Dollar-Signs.html
The old gfortran 4.8.1 also does not speak about the initial letter restriction
-fdollar-ok
Allow `$' as a valid character in a symbol name.
Related
I develop software for an embedded device using the PowerPC architecture. Recently we got a new firmware upgrade and the manufacturer has provided a toolchain which is incapable of building runnable binaries.
Except for a few exceptions, where I've completely statically compiled the binary, the OS gives me following error:
isobuslog.bin: /lib/ld.so.1: version `GLIBC_2.22' not found (required by isobuslog.bin)
I've been up and down a multitude of mailing lists and threads all day, looking for a solution to this.
I finally read a post where following command was entered: powerpc-linux-gnu-readelf -Ws app/bin/isobuslog.bin | grep GLIBC_2.22
The output is as follows:
142: 00000000 0 FUNC GLOBAL DEFAULT UND __tls_get_addr_opt#GLIBC_2.22 (14)
Looking further in to the matter, it seems this is a thread-local storage optimisation routine which became available w/ GLIBC v2.22. Both the SDK I was provided and the SDK I installed myself both have GLIBC version higher than 2.22 and at least G++ 6.3 (6.3 provided by OEM, 9.2.1 installed locally on my machine) - so there's no way around this, unless I use the previous VM provided, which is based on an old Debian using GCC 4.6 - this is not an option, as we require C++11 and higher, without the use of Boost.
I've tried searching around some more, and have found these two linker flags which don't seem to work, causing the linker to exit with an error code, saying it couldn't recognise the flags provided.
--no-tls-optimize
--no-tls-get-addr-optimize
Is there a way to disable __tls_get_addr_opt so that my applications will build, or is there a way around this issue (except going back to ancient times)?
I've finally figured it out.
The trick is to tell G++ to pass the parameters to the linker.
This was achieved by adding the aforementioned switches to the comma-separated list like so:
-Wl,-rpath-link,${DEPS_DIR}/powerpc-linux-gnu/lib,--no-tls-optimize,--no-tls-get-addr-optimize
I've been provided with a very large bank of code which I need to be able to adjust, compile, and run. After some fiddling and attempts, I've deduced that the code was written with DEC standards. gfortran (version 5.4.0, running on Linux Mint / Ubuntu) does not seem able to compile it smoothly, and the -fdec command line option does not appear to be recognized. I started trying to update the code (replacing ACCEPT with READ, etc) but the task is rather daunting - especially since every step is preceded by 30 minutes of research to find the fix.
The provider of said code used PGF77. As far as I can tell, this is not a compiler I can get for free. Are there other, free compilers that can do a comparable job? Alternatively, can I get gfortran -fdec to work somehow?
gfortran version 7 or later supports -fdec option. https://gcc.gnu.org/gcc-7/
option 1 - GNU gfortran
GNU compiler collection as of version 7 supports (released around 2018) the "-fdec" option. So go get gfortran from GCC version 7 or later or most recent. https://gcc.gnu.org/gcc-7/
option 2 - Intel ifort
Also an option but more of a hassle is to get the Intel compiler ifort which has supported the DEC extensions to fortran for many years. Intel's compiler is more of a hassle because of it is proprietary and costs money (hundreds of $ or more) and requires managing licenses.
I'm currently a student, and I am supposed to build a program from a lot of source files / plugins that I've installed. The final step in order to actually build the program is running a central makefile.
The problem is, I get this error towards the end: ld: warning: could not create compact unwind for _what0_: stack subq instruction is too different from dwarf stack size and the build fails.
I'm currently on OSX 10.9.5, and my friend never had this issue when building his version of the same program. The TA to the class told me the reason it wouldn't build was because: "I was building it as 32 bit instead of 64 bit." And to solve this I needed to do one of two things:
Use a 64 bit version of the xCode tool chain instead of the 32 bit one.
Provide the proper option during compilation in order to emit x86_64 code.
After doing some researching, I'm not sure how I could install a 64bit version of the toolchain, since my xCode is 64 bit. And for the second one, I wasn't able to find any command to compile as x86_64 within the makefile.
Is there some easy way to accomplish this? I'm not even sure where else I could post this.. so any advice would be appreciated.
Possible workaround could be to silence the linker warning. I don't see any option to suppress the warning about compact unwind. There seems to be only an option to enable the warning (-warn_compact_unwind). What you could do is to suppress all linker warnings passing -Wl,-w option to compiler.
Another temporary solution you could try is passing -Wl,-no_compact_unwind to clang. It should instruct the linker not to generate compact unwind information.
Regarding your question about compiling for 64 bit architecture. You specify the architecture with -arch compiler option – in your case -arch x86_64.
I know there are already a few answers to this question but I can't seem to understand why I keep getting this error.
So here's the explanation:
I have 64 bits machine in which I've installed Windows 7 x64. I am compiling my Code under GCC (CodeBlocks) on Windows without any problem AT ALL. Then I decided that my application has to be portable, and I decided to compile it under GCC on Linux. In my other 32bit machine the code is compiling without any problem. However, on my 64 bit machine, I decided to install Ubuntu as Wubi. Of course I have installed Wubi x64 version as well.
I installed Ubuntu successfully under Wubi, I installed all necessary stuff, but when I try to compile my project, I get in the very first line the error 'cpu you selected does not support x86-64 instruction set'. Ok, this sounds completely non sense to me, taking into account that I've installed Wubi x64, on Windows 7 x64, on a 64bits machine. So why the hell am I getting an error saying that my CPU does not support x86-64 instruction set?
Could it be JUST because I have installed WUBI instead of installing Ubuntu on root in a normal way? I really can't seem to get this thing.
Thank you very much
EDIT: Ok, somewhere in Codeblocks I found the option that was checked for "Pentium M" architectures. I've unchecked it and now I get several erros such as:
error: cast from void* to int loses precision.
For which reason should this happen ONLY on Linux and not on Windows?
Based on this comment:
EDIT: Ok, somewhere in Codeblocks I found the option that was checked for "Pentium M" architectures. I've unchecked it and now I get several erros such as:
This was the reason for the compilation problem - "Pentium M" is a 32bit architecture. gcc under CodeBlocks will produce 32bit code on Windows by default
The error:
error: cast from void* to int loses precision.
Is caused because the model for 64bit on linux x64 is LP64, where sizeof(long) == sizeof(pointer) == 64bits, and sizeof(int) == 32bits and you're trying to shove a pointer(void *)(64bits) into an int(32bits), which causes pointer information to be lost.
With a compilation error like that, it's most likely that the code is not 64bit clean.
For which reason should this happen ONLY on Linux and not on Windows?
Linux on x64 defaults to producing 64bit applications, you would need to add -m32 to the build options for the program to make it produce 32bit code (there is probably a CodeBlocks target option to do this)
I build an application on a machine running Linux (Debian) with kernel 2.6.26-2-amd64 and I want to run this application on another machine running Linux (Suse) with kernel 2.6.16.60-0.21-smp but I get the error "FATAL: kernel too old".
I know from research on the internet that this can happen when building against a glibc library that was not compiled to support older kernel versions, but it usually concerns version 2.4. Is it possible to get such errors for kernel of the same series (2.6) or can this be from something else ?
Additionally I read that the solution to this problem is to rebuild the application against another version of glibc compiled with appropriate --enable-kernel=VERSION option. As an alternative can you just dynamically link your application with glibc to solve the problem ?
Thank you for your help.
UPDATE: I understand my question may seem vague or solved by one of the solutions already mentionned (dynamically linking, building on another [virtual] system, rebuilding glibc [which seems quite tricky considering the comments I read about it]) but what I am ultimately looking for are ways to prevent such problems.
For instance, is it possible to find which versions of the Linux kernel are compatible with a particular build of glibc ?
UPDATE 2: I eventually found a source patch for glibc (for Debian but I guess there are similar docs online for other distros) that (I guess) contains the information I was looking for.
From this page:
--- eglibc-2.11.2.orig/debian/sysdeps/linux.mk
+++ eglibc-2.11.2/debian/sysdeps/linux.mk
## -0,0 +1,51 ##
[...]
+MIN_KERNEL_SUPPORTED := 2.6.18
[...]
+# Minimum Kernel supported
+with_headers = --with-headers=$(shell pwd)/debian/include
--enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
[...]
Which explains the "kernel too old" error. Hope it helps other people.
One way you can determine the minimum kernel version for a given ELF file is to run file on it, like so:
$ echo 'int main(){}' > test.c
$ gcc -o test test.c
$ file test
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.38, not stripped
The important part here is the "for GNU/Linux 2.6.38", which indicates the minimum kernel version.