mumps: Update to 5.8.2 and enable CLANG builds

[hmartinez82]

Requires #27437

[ognevny]

I had atomic issue on CLANG* in #26410, but adding -latomic somehow fixed it (while resulting v8's exe segfaulted...)

edit: oops, that wasn't CLANG* issue...

[hmartinez82]

I tried -latomic with Flang and it says it doesn't exist . I looked, there's no libatomic.a in /clang64/lib :-( , unless it's in another package, but I don't know which :(

[ognevny]

unless it's in another package, but I don't know which :(

❯ pkgfile libatomic.a
mingw64/mingw-w64-x86_64-gcc
ucrt64/mingw-w64-ucrt-x86_64-gcc
msys/gcc
msys/mingw-w64-cross-mingw32-gcc
msys/mingw-w64-cross-mingw64-gcc
msys/mingw-w64-cross-mingwarm64-gcc
msys/mingw-w64-cross-ucrt64-gcc

[hmartinez82]

@ognevny but none of them have the -clang- prefix, right? I found all those too, with pkgfile. And I would need for ARM64 anyway.

[ognevny]

@ognevny but none of them have the -clang- prefix, right? I found all those too, with pkgfile. And I would need for ARM64 anyway.

yes, none of clang packages has libatomic

[hmartinez82]

Well, once this #27437 is done, I got mumps building for clang64 and clangarm64 :)

[ognevny]

well, not all dependencies seem to be satisfied (from CLANG64 log):

	msmpi.dll => not found

[MehdiChinoune]

well, not all dependencies seem to be satisfied (from CLANG64 log):

	msmpi.dll => not found

The official msmpi should be installed by the user manually, mingw-w64-msmpi contains just import libraries.

[mmuetzel]

Maybe, I'm reading the changes wrong. But would it even be possible to link to the dll with these changes to the pkg-config files?

[hmartinez82]

@mmuetzel Yeah, I see what you are saying, the changes are actually much easier. I'll fix it. I saw all those .a files and thought that this was build statically, but it's a DLL.

Would linking to the output of -Wl,--out-implib be enough?

[hmartinez82]

Maybe, I'm reading the changes wrong. But would it even be possible to link to the dll with these changes to the pkg-config files?

It appears that the pkgconf file originally only had the static libraries, right?

[mmuetzel]

Wouldn't that mean that you would link to the dll and the static archives if you query the static linker flags?

[hmartinez82]

That's what I'm asking, I'm very sorry. I'm not a pkgconf guy :(.

[MehdiChinoune]

@hmartinez82 Please remove that extra .dll, It does not serve any purpose.

[hmartinez82]

Ok, so I tested. and yes you are right, --static includes both Libs.Private and Libs

What should I do?

[hmartinez82]

.dll removed

[mmuetzel]

The previous flags are correct. If you'd like to link statically, you'd add -static to the flags for the linker driver, and it would prefer static archives (*.a) over import libraries (*.dll.a) or dlls.

So, the goal should be that there is (at least) one static library with the same base name as the shared library (dll).

If I understand correctly, that didn't work with the LLVM toolchain because it can't create thin archives.

One possible way to work around that (untested) could be to manually extract all objects from the existing archives and create a new archive using something like this:

  for x in c z s d; do
    mkdir tmp-mumps-${x}so
    cd tmp-mumps-${x}so
    ar x ../lib${x}mumps_seq.a
    ar x ../libmumps_common_seq.a
    ar x ../libmumps_pord.a
    ar x ../libmumps_mpi_seq.a
    ar crs ../libmumps-${x}so.a *.o
    cd ..
    rm -rf tmp-mumps-${x}so

    mkdir tmp-mumps-${x}to
    cd tmp-mumps-${x}to
    ar x ../lib${x}mumps_shm.a
    ar x ../libmumps_common_shm.a
    ar x ../libmumps_pord.a
    ar x ../libmumps_mpi_seq.a
    ar crs ../libmumps-${x}to.a *.o
    cd ..
    rm -rf tmp-mumps-${x}to

[your commands to create the dlls go here]

    if [[ ${CARCH} == x86_64 ]]; then
      mkdir tmp-mumps-${x}mo
      cd tmp-mumps-${x}mo
      ar x ../lib${x}mumps_mpi.a
      ar x ../libmumps_common_mpi.a
      ar x ../libmumps_pord.a
      ar crs ../libmumps-${x}mo.a *.o
      cd ..
      rm -rf tmp-mumps-${x}mo

[your commands to create the dll go here]
    fi
  done

I guess llvm-ar would be able to do that. But I haven't tested that yet.

If that works, it shouldn't be necessary to change the pkg-config files

[hmartinez82]

llvm-ar can create thin archives from, but not from other archives. The issue is that lib${x}mumps_seq.a, libmumps_common_seq.a, etc are already archives themselves.

[mmuetzel]

llvm-ar can create thin archives from, but not from other archives. The issue is that lib${x}mumps_seq.a, libmumps_common_seq.a, etc are already archives themselves.

This is why I was suggesting to extract the objects from the static libraries (with ar x) and then recreating the static library (with the correct name) from the extracted object files.

[mmuetzel]

I tested that approach in the MINGW64 and the CLANG64 environment. And it seems to be working.
The package size would increase because we'd essentially distribute the objects twice in different archives. But it should behave identically for anyone that is linking to the installed binaries.

[mmuetzel]

Alternatively, you could probably also add an empty archive with the base name of the dll and add the actual archives to the Libs.private line in the pkg-config file.

[mmuetzel]

It appears that the pkgconf file originally only had the static libraries, right?

No. It had both.

The flags in the lines with *.private are returned by pkg-config additionally to the "normal" flags if you ask it for the flags for static linking.

[mmuetzel]

Looking the build artifacts that make creates, there are the two archives libmpiseq_seq.a and libmpiseq_shm.a which apparently aren't used for the dll or the installed static libraries.
Is that intentional? Or are they missing?
Should they be linked into the respective libraries (instead of or additionally to libmumps_mpi_seq.a)?

[hmartinez82]

@mmuetzel That I don't now :-( . I think that that's something only the project devs would be able to answer. I've tried to stay as close as possible to the original package recipe.