If you compile with gcc and use our base libgcc it should DTRT *provided* our libgcc has defined functions that are up to date with current libgcc. We compile with gcc, it needs foo() from libgcc to run (A typical function would be T multi3) and so our libgcc provides a foo() and gcc is happy.

This means in theory, we can interchangeably use gcc and clang in ports. This also means it made the initial port work from from gcc in base to clang in base a lot easier.

The problems come when we try to use architectures not fully supported by our libgcc_s.so or when we use fortran.

However, our libgcc lies in two ways:

1) our libgcc is mostly not GPL code anymore, though there are bits and pieces of GPL depending on what we don't have.

2) It claims to be only up to date with GCC 4.2.4

The moment you load libgfortran, it has a requirement for GCC_4.6 or better, and if our libgcc is already loaded things fail.

The reason ports gcc now has this requirement on 4.6 or better is GNU changed gfortran to always support quad math (*8) and hence needs /usr/local/lib/gccXX/libquadmath.so They then changed the dependancy stated in libgfortran to always require a later libgcc.

We *could* lie in our libgcc_s and claim to be 4.6 which would simply mean libgfortran would not complain and simply load the missing libquadmath.

If we updated the claimed GCC version in our libgcc_s.so to claim GCC_4.6, we really also should provide a libquadmath subsitute.

The other approach is to rename our libgcc_s.so to libclang_s.so or some such and link base with it instead of libgcc_s.so I frankly think this in the long term is the cleaner solution.

In the ports world, we have papered over this problem by adding -Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so Cmake does DTRT but programs that run python will not have prior knowledge that a binary module they are going to load during execution will be gfortran built and need libquadmath therefore asking for a later libgcc than in base. Hence if one forces the pre load of gfortran libgcc or LD_PATH it so it comes first, everything works just peachy. I'm guessing python is the biggest user of loaded gfortran binary modules but the problem could come up in other interpreters.

N.B. at this time clang does not realise flang is a valid fortran compiler.

Mixing gfortran and flang .obj's seem to work until I/O is involved.

$ more m.f

$ more a.f

$ more b.f

$ flang -o m m.f a.f b.f $ ./m

$ gfortran5 -o m m.f a.f b.f $ ./m /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc5/libgfortran.so.3 not found

# compile with flang only a.f

$ flang -c a.f -o a.o clang-3.9: [[0;1;35mwarning: [[0m-lflang: 'linker' input unused^[[0m clang-3.9: [[0;1;35mwarning: [[0m-lflangmain: 'linker' input unused^[[0m clang-3.9: [[0;1;35mwarning: [[0m-lflangrti: 'linker' input unused^[[0m clang-3.9: [[0;1;35mwarning: [[0m-lompstub: 'linker' input unused^[[0m clang-3.9: [[0;1;35mwarning: [[0m-lexecinfo: 'linker' input unused^[[0m clang-3.9: [[0;1;35mwarning: [[0margument unused during compilation: '-L/usr/l ocal/flang/lib'

# compile with gfortran only b.f $ gfortran5 -c b.f -o b.o

$ flang -o m m.f a.o b.o /usr/bin/ld: ESC[0;1;31merror: ESC[0mundefined symbol: _gfortran_st_write >>> referenced by b.f >>> b.o:(b_)

/usr/bin/ld: ESC[0;1;31merror: ESC[0mundefined symbol: _gfortran_transfer_character_write >>> referenced by b.f >>> b.o:(b_)

/usr/bin/ld: ESC[0;1;31merror: ESC[0mundefined symbol: _gfortran_st_write_done >>> referenced by b.f >>> b.o:(b_) clang-3.9: ESC[0;1;31merror: ESC[0mlinker command failed with exit code 1 (use -v to see invocation)ESC[0m $ flang -o m m.f a.o b.o /usr/local/lib/gcc5/libgfortran.so $ ./m /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc5/libgfortran.so.3 not found

$ gfortran -o m m.f a.o b.o /usr/local/lib/gcc5/libgfortran.soESC[60DgfortranESC[1@5 a.o: In function `a_': /home/db/a.f:3: undefined reference to `f90io_src_info03' /home/db/a.f:3: undefined reference to `f90io_print_init' /home/db/a.f:3: undefined reference to `f90io_sc_ch_ldw' /home/db/a.f:3: undefined reference to `f90io_ldw_end' collect2: error: ld returned 1 exit status

$ gfortran5 -o m m.f a.o b.o /usr/local/lib/gcc5/libgfortran.so /usr/local/flang /lib/libflang.so //usr/local/flang/lib/libflangrti.so: undefined reference to `backtrace_symbols' //usr/local/flang/lib/libflangrti.so: undefined reference to `backtrace' collect2: error: ld returned 1 exit status

# Removing I/O from a.f and b.f

$ cat a.b cat: a.b: No such file or directory $ cat a.f

C print*,'hello from a'

$ cat b.f

C print*,'hello from b'

$ flang -c -o a.o a. clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflang: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflangmain: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflangrti: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lompstub: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lexecinfo: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0margument unused during compilation: '-L/usr/local/flang/lib' $ gfortran5 -c -o b.o b.f

C print*,'hello from b'

$ flang -c -o a.o a. clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflang: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflangmain: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lflangrti: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lompstub: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0m-lexecinfo: 'linker' input unused clang-3.9: ESC[0;1;35mwarning: ESC[0margument unused during compilation: '-L/usr/local/flang/lib' $ gfortran5 -c -o b.o b.f $ flang -o m m.f a.o b.o $ ./m

$ gfortran5 -o m m.f a.o b.o $ ./m /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc5/libgfortran.so.3 not found

libgcc problem (last edited 2017-11-12 00:55:23 by DianeBruce)