vecLibFort @0.4.2_0: error: conflicting types for 'sdsdot_'

[Nevensky (Neven Golenić)]

Unfortunately vecLibFort fails to build on macOS Monterey 12.0.1 (intel cpu, I don't know about M1), it is a dependency for some physics related packages like Quantum Espresso so its quite important.

--->  Fetching archive for vecLibFort
--->  Attempting to fetch vecLibFort-0.4.2_0.darwin_21.x86_64.tbz2 from https://packages.macports.org/vecLibFort
--->  Attempting to fetch vecLibFort-0.4.2_0.darwin_21.x86_64.tbz2 from https://fra.de.packages.macports.org/vecLibFort
--->  Attempting to fetch vecLibFort-0.4.2_0.darwin_21.x86_64.tbz2 from https://cph.dk.packages.macports.org/vecLibFort
--->  Building vecLibFort
Error: Failed to build vecLibFort: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_vecLibFort/vecLibFort/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is
a bug.
Error: Processing of port vecLibFort failed

[reneeotten (Renee Otten)]

please attached the main.log file mentioned in the error message to this ticket.

[Nevensky (Neven Golenić)]

main.log

[Nevensky (Neven Golenić)]

Added main.log as requested.

[TruePath (Peter Gerdes)]

It also fails to build on M1 (also on Montery though with Xcode-beta version 13.2). I'll attach the log.

[TruePath (Peter Gerdes)]

main.log from build on Montery with M1

[ryandesign (Ryan Carsten Schmidt)]

A zillion errors starting with:

vecLibFort.c:124:1: error: conflicting types for 'sdsdot_'
BLS_CALL(float,sdsdot,6)
^
vecLibFort.c:117:13: note: expanded from macro 'BLS_CALL'
extern type name ## _( VOIDS(n) ); \
            ^
<scratch space>:85:1: note: expanded from here
sdsdot_
^
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/fortran_blas.h:95:8: note: previous declaration is here
double sdsdot_(int *n, float *sb,
       ^

[dasice (Dave)]

I see the same error on Monterey 12.0.1 on an M1 chip as Peter Gerdes starting with:

:info:build /usr/bin/clang -shared -arch arm64 -DVECLIBFORT_INTERPOSE -o libvecLibFortI.dylib -O vecLibFort.c \
:info:build             -Wl,-reexport_framework -Wl,Accelerate \
:info:build             -install_name /opt/local/lib/libvecLibFortI.dylib
:info:build vecLibFort.c:124:1: error: conflicting types for 'sdsdot_'
:info:build BLS_CALL(float,sdsdot,6)
:info:build ^
:info:build vecLibFort.c:117:13: note: expanded from macro 'BLS_CALL'
:info:build extern type name ## _( VOIDS(n) ); \
:info:build             ^
:info:build <scratch space>:37:1: note: expanded from here
:info:build sdsdot_
:info:build ^
:info:build /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Accelerate.framework/Fra
meworks/vecLib.framework/Headers/fortran_blas.h:95:8: note: previous declaration is here
:info:build double sdsdot_(int *n, float *sb,
:info:build        ^

[mcmara (Jack McMara)]

Besides Quantum Espresso, this defect is also preventing the installation of Octave. How about increasing the priority?

[gjolleyrogers (Garry Jolley-Rogers)]

+ 1 need octave

[TruePath (Peter Gerdes)]

So I'm wondering if maybe the headers in Monterey just include the type definitions we need for vecLibFort.

I mean if I comment out lines 124 to 139 in vecLibFort.c and the lines 28-115 in static.h as (as follows) it builds fine.

However, it's been forever since I did any development in C/C++ and I don't really understand what's going on with the macros here so I worry that this will break things later. Can someone who knows what they are doing double check this?

// BLS_CALL(float,sdsdot,6)
// BLS_CALL(float,sdot,5)
// BLS_CALL(float,snrm2,3)
// BLS_CALL(float,sasum,3)
// BLS_CALL(c_float,cdotu,5)
// BLS_CALL(c_float,cdotc,5)
// BLS_CALL(float,scnrm2,3)
// BLS_CALL(float,scasum,3)
// BLS_CALL(c_double,zdotu,5)
// BLS_CALL(c_double,zdotc,5)
#if defined(VECLIBFORT_SGEMV)
// BLS_CALL(void,sgemv,11)
#endif

#else

/*

// STATIC float FNAME(sdsdot)( const int* N, const float* alpha, const float* X, const int* incX, const float* Y, const int* incY )
// {
//   DEBUG_S( "sdsdot" )
//   return cblas_sdsdot( *N, *alpha, X, *incX, Y, *incY );
// }

// STATIC float FNAME(sdot)( const int* N, const float* X, const int* incX, const float* Y, const int* incY )
// {
//   DEBUG_S( "sdot" )
//   return cblas_sdot( *N, X, *incX, Y, *incY );
// }

// STATIC float FNAME(snrm2)( const int* N, const float* X, const int* incX )
// {
//   DEBUG_S( "snrm2" )
//   return cblas_snrm2( *N, X, *incX );
// }

// STATIC float FNAME(sasum)( const int* N, const float *X, const int* incX )
// {
//   DEBUG_S( "sasum" )
//   return cblas_sasum( *N, X, *incX );
// }

// STATIC c_float FNAME(cdotu)( const int* N, const void* X, const int* incX, const void* Y, const int* incY )
// {
//   DEBUG_S( "cdotu" )
//   c_float ans;
//   cblas_cdotu_sub( *N, X, *incX, Y, *incY, &ans );
//   return ans;
// }

// STATIC c_float FNAME(cdotc)( const int* N, const void* X, const int* incX, const void* Y, const int* incY )
// {
//   DEBUG_S( "cdotc" )
//   c_float ans;
//   cblas_cdotc_sub( *N, X, *incX, Y, *incY, &ans );
//   return ans;
// }

// STATIC float FNAME(scnrm2)( const int* N, const void* X, const int* incX )
// {
//   DEBUG_S( "scnrm2" )
//   return cblas_scnrm2( *N, X, *incX );
// }

// STATIC float FNAME(scasum)( const int* N, const void *X, const int* incX )
// {
//   DEBUG_S( "scasum" )
//   return cblas_scasum( *N, X, *incX );
// }

// STATIC c_double FNAME(zdotu)( const int* N, const void* X, const int* incX, const void* Y, const int* incY )
// {
//   DEBUG_S( "zdotu" )
//   c_double ans;
//   cblas_zdotu_sub( *N, X, *incX, Y, *incY, &ans );
//   return ans;
// }

// STATIC c_double FNAME(zdotc)( const int* N, const void* X, const int* incX, const void* Y, const int* incY )
// {
//   DEBUG_S( "zdotc" )
//   c_double ans;
//   cblas_zdotc_sub( *N, X, *incX, Y, *incY, &ans );
//   return ans;
// }

// #ifdef VECLIBFORT_SGEMV
// STATIC void FNAME(sgemv)( const char* trans, const int* m, const int* n, 
//   const float* alpha, const float* A, const int* ldA,
//   const float* X, const int* incX,
//   const float* beta, float* Y, const int* incY )
// {
//   DEBUG_S( "sgemv" )
//   enum CBLAS_TRANSPOSE T;
//   switch ( trans[0] ) {
//     case 'T': case 't':
//       if ( (long)X % 32 == 0 ) { T = CblasTrans; break; }
//       /* Implement as alpha * X^T * A + beta * Y^T */
//       cblas_sgemm( CblasColMajor, CblasNoTrans, CblasNoTrans, 1, *n, *m, *alpha, X, *incX, A, *ldA, *beta, Y, *incY );
//       return;
//     default:
//       T = CblasNoTrans;
//   }
//   cblas_sgemv( CblasColMajor, T, *m, *n, *alpha, A, *ldA, X, *incX, *beta, Y, *incY );
// }
// #endif

[TruePath (Peter Gerdes)]

So I added two patch files to be applied to vecLibFort.c and static.h respectively *after* the included patches are applied. But it may just screw everything up since I haven't yet tested beyond that it builds.

[wouterel (Wouter Ellenbroek)]

Output of vecLibFort tester program compiled with patches provided by TruePath

[wouterel (Wouter Ellenbroek)]

Thanks Peter, I also got it to build (on an M1 MBP with Monterey 12.1) using your patches. I tried testing the resulting library using the tester.f90 program included with the vecLibFort github repo.

Just adding here that the results of that test were not encouraging (see attached file). However, I do not know if this 8-year-old test program is even supposed to still work (e.g., does it work on Big Sur?), and if I used it correctly. So I won't try to draw conclusions here, just posting it, hoping that this info may be helpful to whoever wants to look into this further.

[gergomez]

In fact, the tester.f90 file still works as shown by using -ff2c when compiling it against Accelerate directly. It seems that the new fortran_blas.h header file has completely polluted the namespace and breaks the approach from vecLibFort. One easy temporary solution is to manually edit the corresponding vecLib.h (for me it is in /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/) and comment out the line that includes vecLib/fortran_blas.h (line 50 for me), then you will be able to port install vecLibFort and lapack +accelerate. You can uncomment the line back in for safety after that.

[wouterel (Wouter Ellenbroek)]

That works, @gergomez. Thanks. Now when I compile tester.f90 with "-framework Accelerate" the compilation looks fine but the tester output is bad, but when I compile with "-L/opt/local/lib -lvecLibFort" the output looks OK. I presume that is the expected behavior (I'm not sure I understand exactly what vecLibFort does so perhaps I'm missing something here).

I hope the port will be fixed at some point but this will do for now.

[jsalort (Julien Salort)]

Replying to gjolleyrogers:

+ 1 need octave

In principle, Octave should build without vecLibFort, if you choose the openblas variant instead of accelerate. I have tried it, it seems to compile, but fails to stage into destroot. See: comment:ticket:61860:3

[Nevensky (Neven Golenić)]

This also prevents Quantum Espresso from being installed. I vote for an increase in priority as well.

[tenomoto (Takeshi Enomoto)]

vecLibFort aims to replace several functions in vecLib that returns double instead of float. I still can't figure out what happened with Monterey or macOS sdk 12.0. I suggest making openblas default for Monterey.

[rshuston]

The problem isn't necessarily Monterey, but rather it's due to changes that Apple made to the vecLib.framework in the MacSDK12.x.sdk SDK folder, which was brought in with Xcode 13.2 (might even be Xcode 13, but I don't know). So the problem also exists on Big Sur if you have Xcode 13.2 installed.

If you examine

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/vecLib.h

you'll see a new entry at line 50:

#include <vecLib/fortran_blas.h>

First of all, this line is unguarded without an "#if defined" block, so it brings in fortran_blas.h no matter what. Looking at the contents of fortran_blas.h reveals the definitions for all of the prototypes that vecLibFort is trying to wrap.

If you install the "Command Line Tools for Xcode 13.2" download from Apple, you'll find that it installs SDKs for both MacOSX11 and MacOSX12:

/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -> MacOSX11.3.sdk /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -> MacOSX12.1.sdk

Examining the vecLib.h file in the MacOSX11.sdk tree shows that it's the older version that does not include fortran_blas.h. So, adding

-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk

to the CFLAGS variable in the vecLibFort Makefile allows the project to build the way is used to.

I'm not sure how to yet handle the Apple change, and also if the new Apple change even alleviates the need for vecLibFort entirely, but this modification may help people who need to get the library to build.

[rshuston]

I was able to fork the ​https://github.com/mcg1969/vecLibFort project and add a local instance of Apple's MacOSX11.3.sdk version of vecLib.h. Including this local file before the #include <Accelerate/Accelerate.h> line allows the project to build and test without having to modify the CFLAGS variable of the project Makefile. I submitted a PR to the original project, but you can view my changes in my fork at ​https://github.com/rshuston/vecLibFort .

I don't know how this should be incorporated into the portfile so I'm hoping that this is sufficient to allow the port maintainers to incorporate a suitable fix.

[rshuston]

Patch to add local vecLib-760.100 header file

[rshuston]

Patch to update vecLibFort.c to use local vecLib-760.100 header file

[rshuston]

As a workaround, copy both the patch-add-local-vecLib-760.100-header.diff and patch-vecLibFort.diff attachments to the vecLibFort Portfile files directory:

/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/vecLibFort/files

Then, update the Portfile patchfiles entry to be

patchfiles          patch-Makefile.diff \
                    patch-add-local-vecLib-760.100-header.diff \
                    patch-vecLibFort.diff

The vecLibFort port should now build correctly. The first patch simply creates the local vecLib-760.100.h header file, the and second patch updates vecLibFort.c to include it before the Accelerate.h header.

[tenomoto (Takeshi Enomoto)]

Thanks for the patch. I'm going to commit them. There seems to be other problems to build octave on Monterey.

[tenomoto (Takeshi Enomoto)]

In 7fd4e461e6c49b209327153a9b39e7397c373e2a/macports-ports (master):

vecLibFort: incorporate contributed patches to fix build with MacOSX12.sdk or later

Closes: #63717

[rshuston]

You're welcome. To take care of the other issues to build Octave on Monterey, see my comment on the 62874 ticket:

comment:ticket:62874:11