Clang should natively support fortran

FreeBSD switched to clang as a major compiler, but all fortran parts still require gcc. Since C++ code built with gcc and clang can't be mixed, C++ projects requiring fortran generally don't work in FreeBSD now (mostly math software).

Is clang going to support fortran?

Yuri

This is FUD. You can certainly mix compiled C++ between GCC and Clang as
long as you use a consistent STL implementation and avoid versions of
GCC that are no longer compatible with the Itanium ABI (aka using the
cxxabi crap).

Joerg

Sorry to troll your post, but who on earth uses FreeBSD+Fortran? As a
person who works on a Fortran compiler almost every day I'm actually
asking. I suspect FreeBSD could remove support for Fortran and it
wouldn't even get noticed.

Completely ignoring performance, I don't know *anyone* (iXsystems?)
shipping an HPC oriented solution with FreeBSD as the OS.

Sorry, my description wasn't accurate.

The real problem is that clang-built executables link with the older version of libgcc_s.so (/lib/libgcc_s.so.1), and the current gcc supplies its own version, ex. /usr/local/lib/gcc48/libgcc_s.so These two libgcc_s.so are in conflict. The reason why FreeBSD base system has an older version has to do with the changed gcc license, which became incompatible. The reason clang-built executables link with /lib/libgcc_s.so.1 is that an "unwind" API is only implemented there.

I guess the real question is: what is the best replacement of an unwind API? Does clang/llvm supply it? Or what is the best solution of this problem?

This problem has been in FreeBSD for a long while, with no solution in sight. It is related to clang, so I decided to ask here for an opinion.

Thank you,

Yuri

Well, FreeBSD is a full-featured OS, and generally supports most of the software that is available.

Otherwise, what is the OS, in your opinion, where fortran is used?

Yuri

Hi Yuri,

this was discussed in a lot of detail in the thread (http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html). The consensus was that there should be a separate fortran frontend, since the language is fairly different from C/C++ (which clang specializes in).

Nico

This is going down a rabbit hole pretty far off topic, but the most
sincere answer I can give

I disagree.

You seem to focus on the business use of the OS, and ignore some other uses. Do you know about Jupyter notebook software (http://jupyter.org)? It allows to create the interactive math- and physics-based books that allow the reader to explore and experiment with formulas and computations right inside the book? A lot of Jupyter uses fortran-based libraries in the background. And Jupiter is a pretty cool thing. There is also the symbolic computer algebra Cadabra2 (http://cadabra.science) that also uses fortran in the background. And many other packages use fortran too.

FreeBSD has a lot of advantages compared to Linux, OSX and Windows. For example, on FreeBSD you can have a 100% open source system, and all Linux distros always mix in some random third party-built binaries. This is a security risk. FreeBSD doesn't just grab the latest versions of packages from github like linux distros do. This is another security risk. You can't just blow this off, these are very significant advantages. And how can you make a case for the business use of Windows or OSX on a computation farm? Why add the licensing costs? It just doesn't make sense to me.

Following your logic, nobody should do any new things because there is some gigantic industry already doing things some other way. Why even develop clang if there is gcc that already compiles everything fine?

Yuri

LLVM has a sub-project called libunwind (same as the other one, sorry
for the bad naming).

http://llvm.org/viewvc/llvm-project/libunwind/trunk/

It's fairly active and mostly functional. I believe FreeBSD may
already use it (or some other non-gcc one) internally with Clang, so
you should just try to find it. It works pretty well with Compiler-RT
and libc++, and I believe both are also aready being used by Clang in
FreeBSD.

I have no idea, though, if the ageing GCC in FreeBSD will work with
libunwind, libc++ or compiler-RT. Actually, I'd be very surprised if
it did... :frowning:

I'm copying some FreeBSD folks to chime in.

cheers,
--renato

libunwind is GPLv3-licensed, so it is unusable in the system that has GPL-averse license policy, like FreeBSD.

Is there a way to dual-license it with the second license being the same as llvm has?

Yuri

I guess you're mistaking LLVM's libunwind for the other one with the same name:

http://blog.llvm.org/2013/10/new-libunwind-implementation-in-libcabi.html

Lei

Sorry, my bad, looked at the wrong place.

Yuri

This is FUD. You can certainly mix compiled C++ between GCC and Clang as
long as you use a consistent STL implementation and avoid versions of
GCC that are no longer compatible with the Itanium ABI (aka using the
cxxabi crap).

Sorry, my description wasn't accurate.

The real problem is that clang-built executables link with the older version of libgcc_s.so (/lib/libgcc_s.so.1), and the current gcc supplies its own version, ex. /usr/local/lib/gcc48/libgcc_s.so These two libgcc_s.so are in conflict. The reason why FreeBSD base system has an older version has to do with the changed gcc license, which became incompatible. The reason clang-built executables link with /lib/libgcc_s.so.1 is that an "unwind" API is only implemented there.

This is a long standing problem with the FreeBSD gcc ports, which is completely orthogonal to any fortran issue. The different versions of gcc all use different versions of their support libraries (of which libgcc is just one), and while these are usually backwards compatible, from gcc 4.3 onwards they are all under GPLv3. Therefore we never imported them into the FreeBSD base system.

Right at this moment some different solutions for this problem are being discussed, such as patching up the different gcc version to automatically add appropriate RPATH entries to the right location for their support libraries. But there are many ways of solving this, each with their own advantages and disadvantages; there is no consensus yet.

I guess the real question is: what is the best replacement of an unwind API? Does clang/llvm supply it? Or what is the best solution of this problem?

Ed Maste is already working on import the LLVM version of libunwind, which is under the usual dual MIT/UIUC license. But it is still an ongoing project.

This problem has been in FreeBSD for a long while, with no solution in sight. It is related to clang, so I decided to ask here for an opinion.

I disagree: it has nothing to do with clang or llvm, and everything to do with the way the FreeBSD ports packaging of gcc versions has been done for years. Please start discussing this on the FreeBSD ports mailing list instead.

-Dimitry

I guess the real question is: what is the best replacement of an unwind API?
Does clang/llvm supply it? Or what is the best solution of this problem?

LLVM has a sub-project called libunwind (same as the other one, sorry
for the bad naming).

http://llvm.org/viewvc/llvm-project/libunwind/trunk/

It's fairly active and mostly functional. I believe FreeBSD may
already use it (or some other non-gcc one) internally with Clang, so
you should just try to find it. It works pretty well with Compiler-RT
and libc++, and I believe both are also aready being used by Clang in
FreeBSD.

Yes, Ed imported it into FreeBSD head 8 months ago:

https://svnweb.freebsd.org/base/head/contrib/llvm/projects/libunwind/

However, it is currently only used for AArch64 and RISC-V.

I have no idea, though, if the ageing GCC in FreeBSD will work with
libunwind, libc++ or compiler-RT. Actually, I'd be very surprised if
it did... :frowning:

Nope, we only keep gcc 4.2 for some architectures such as PowerPC and Sparc.

-Dimitry

I'm completely unsure, as I never touch Fortran, but maybe Diane knows. :slight_smile:

-Dimitry

There are some very high profile libraries written in Fortran :frowning:

Joerg

Come on.. I love Fortran and there's a lot of good things about it.. I
do want to kick the J3 about certain things, but those dinosaurs
aren't likely to listen...

What libraries are you referring to specifically? I don't know
anything in a typical base OS which depends on Fortran.

Linear algebra makes the world go round. LAPACK in particular is used in all sorts of places one might not expect at first, and AFAIK the CLAPACK distribution is frozen at 3.2.1 vs (Fortran) LAPACK at 3.6.1.

– Steve

I work with LAPACK(E) every day, but it's not a base OS requirement.

One's being developed:

And it looks like it's like significant progress has been made:
http://lists.llvm.org/pipermail/llvm-dev/2016-May/100170.html