Do we need name mangling any more?

[LouHafer]

So I got to looking at CHK_LAPACK and pretty quickly got down to the name mangling macros. They never did handle the 'extra underscore' bit correctly and I thought I'd poke at it. So I went looking for name mangling conventions. Historically, there are a lot, but recently the situation seems to have improved. This thread in a cmake mail list says, in essence, that any Fortran compiler that supports the Fortran 2003 standard should no longer have this issue if the compiler writer has any concerns about C compatibility. By the time you get towards the end of the thread, the claim is that pretty much all modern Fortran compilers support this. For folks with more experience at this than me, is this really the case?

Sadly, some further search turns up this thread in an autoconf list that talks about Fortran modules. Do we need to cope with these?

If memory serves, the native autoconf macros actually require a Fortran compiler to compile a test program which is analysed to get the mangling convention. We were trying to avoid that by just trying a set of the most common conventions. So we may have to limit our ambition.

[LouHafer]

To follow up with some experimentation on my Fedora system, the packaged libraries liblapack and libopenblas seem to require lower case, trailing underscore. Intel's MKL distribution declares all of lower case; lower case with trailing underscore; and uppercase (but not uppercase with trailing underscore). So it seems we still need the basic {upper, lower} x {(no) trailing underscore}. Testing using a symbol name with an embedded underscore (dorhr_col) shows no sign of the extra trailing underscore. Can we just drop this complication? What about macOS? One source claims Macs have both leading and trailing underscore.

[svigerske]

No, I think.

There are macros in autoconf that check for the naming convention that the Fortran compiler is using when it builds a library. These define F77_FUNC, etc. These macros need a Fortran compiler.

The current macros in coin.m4, e.g., the ones that check for Lapack or are used to check for HSL, check the naming convention that is used by a given library. This is done by compiling C code and without requiring a Fortran compiler. So, for example, you shouldn't see a check for a Fortran compiler in CoinUtils/master.

[tkralphs]

OK, good to know. I've been struggling to try to build Cbc 2.10 on Windows with conda and the big stumbling block is that CoinUtils wants a Fortran compiler. flang is the only one available and it doesn't work with the old build system for a number of reasons. I'm about to give up on that and just work towards the new Cbc release unless anyone has ideas (sorry to hijack the thread a bit).

[svigerske]

Of course, you should not waste time on building the old 2.10 on Windows (or anywhere else). The current masters seem relatively stable and if it were up to me, we would have made releases from them a while ago.

[tkralphs]

Yeah, I know you want me to make the releases from master. I've been making steady progress on the refactoring and will get back to it again soon, hopefully finishing it off. The goals of the refactoring seem to be something we should all want, but no one is pitching in or seems much interested. If I don't manage to finish soon, I will just make some releases now and then make more later. It should soon be in a state where I can see if anyone outside the team wants to help.

[LouHafer]

What Stefan said. There are lots of comments in coin_fortran.m4 about this. The gist of it is that we test a selection of possibilities and carefully avoid calling any of the documented autoconf macros because they all eventually AC_REQUIRE something that needs a working compiler.

[LouHafer]

It's easy to fix COIN_NAMEMANGLING to add code to check for extra underscore, if don't bother to check to see if the name being tested really needs it. The danger (which we cannot really guard against) is that the user will test a name with no embedded underscore in a system that really needs the extra underscore. We can change our lapack test method to dorhr_col (or some better choice, as long as it has the embedded underscore) so we'll get it right for that. To avoid unnecessary tests in the common case, we should probably move the no extra underscore, extra underscore choice to the outermost loop.

Seems to me a good enough solution for something that really isn't a problem that we've heard about.

[svigerske]

Yes, sounds good.

I didn't know about the connection of the extra underscore and the embedded underscore.

[svigerske]

Had to change the lapack test back, as dorhr_col is too new, ref b276963.

[LouHafer]

@svigerske, am I right to think that COIN_TRY_LINK makes COIN_NAMEMANGLING unnecessary?

[svigerske]

They look similar, but their "API" is a bit different:

COIN_NAMEMANGLING (lib,func,lflags)
COIN_TRY_LINK(func,lflags,pcfiles,action-if-success,action-if-failed)

In COIN_NAMEMANGLING the macros use lib to make up the name of the #define's, but in COIN_TRY_LINK func is used for that.

I'm using the AC_COIN_NAMEMANGLING in Ipopt to check for the namemangling used by HSL:

AC_COIN_CHK_PKG(HSL,[IpoptLib HSLLib],[coinhsl],[build])
if test "$coin_has_hsl" = yes ; then
  AC_COIN_FINALIZE_FLAGS([HSLLib])
  AC_COIN_NAMEMANGLING([HSL],[ma27ad],[$HSLLIB_LFLAGS])
  if test "$ac_cv_hsl_namemangling" = "unknown" ; then
    AC_MSG_ERROR([Provided package HSL is not working or does not contain MA27.])
  fi
endif

I guess I could change the last part to

  AC_COIN_TRY_LINK(ma27ad,$HSLLIB_LFLAGS,,
    AC_COIN_DEFINENAMEMANGLING(HSL,$ma27ad_namemangling),
    AC_MSG_ERROR([Provided package HSL is not working or does not contain MA27.]))

[svigerske]

So I'm changing configure.ac of Ipopt accordingly in coin-or/Ipopt@eb7c15a
This is on the branch that adjusts to the changes from #148.

As far as I see in the projects that I have checked out, this was the only use for AC_COIN_NAMEMANGLING, so I'm going to remove it from coin.m4 in branch issue143 (#148).