Possible compilation error resulting in a shared object referring to a source file

[Vishnu V. Krishnan]

The build and install scripts of my distro seem to check compiled binaries for any references to the source files, since such things may result in broken links. In doing so, it warned me about the file "/usr/lib/libcaf_mpi.so.3" containing such a reference.

Upon checking that file for 'strings', the culprit seems to be the following:

At line 590 of file /<build_directory>/OpenCoarrays-2.1.0/src/extensions/opencoarrays.F90

Is this indicatory of an error in the compilation?

[Zaak Beekman]

Hi,

Can you please tell use what distro you are using, and if possible, link to the page with information about the OpenCoarrays package in the package manager?

Can you please open a new issue to track this at https://github.com/sourceryinstitute/OpenCoarrays/issues/new ? (And please fill out the bug report template to the best of your abilities.)

I'm guessing that the library was compiled with debug symbols. If this is indeed the case, then paths to the source files at the time of compilation may be embedded in the object files, and, in turn, the dylibs. AFAICT, if that is indeed the case it should not cause any problems for you.

Sorry it took so long to respond, however the best place to report bugs is on GitHub.

Thanks,

Zaak

[Vishnu V. Krishnan]

> Can you please tell use what distro you are using, and if possible, link to
> the page with information about the OpenCoarrays package in the package
> manager?

This is on Archlinux, and the packgage is installed from the AUR, which is to
say that it is built locally upon (every) install (it isn't packaged as a
binary).

The build script used is:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=opencoarrays

> Can you please open a new issue to track this at
> https://github.com/sourceryinstitute/OpenCoarrays/issues/new ? (And please
> fill out the bug report template to the best of your abilities.)

I will open one if it isn't something trivial like you suggest below. We can
maybe triage it here?

> I'm guessing that the library was compiled with debug symbols. If this is
> indeed the case, then paths to the source files at the time of compilation
> may be embedded in the object files, and, in turn, the dylibs. AFAICT, if
> that is indeed the case it should not cause any problems for you.

Do I need to add something like a `-DCMAKE_BUILD_TYPE=Release`, in the cmake
command? I would've thought that is the default.

Vishnu
--
⚷ OpenPGP fingerprint: 5015 1D4C 9BDF 9062 A9E1 62CB 5B1F4BEE7EED7131

[Zaak Beekman]

Vishnu,

I have no reason to believe that this warning/error message about source file references is a cause for concern. I don't know where it's coming from, but the binary versions distributed with Homebrew, the package manager on macOS, reference the same source file in the build tree on the CI VM. Running OpenCoarrays installed from a binary package on macOS has never caused me any issues, nor have we ever received a bug report that would indicate a problem.

The build script looks correct. OpenCoarrays automatically sets the corresponding `-DCMAKE_BUILD_TYPE:STRING=Release` if not specified on the command line.

If there is a string pointing to a source file in your build tree embedded in the shared library, then I don't think it was explicitly put there by us, and I suspect that it will have no runtime impact. Running strings on my own dylib (on macOS) I see a reference to line 590 which is a transfer statement in co_broadcast_c_char(). Code from this file will not be executed unless the user explicitly requests the OpenCoarrays extensions module which lets one use collectives with compilers that may or may not support coarrays, and do not adequately support collectives.

Thanks,

Zaak

P.S. OpenCoarrays 2.2.0 has been released.

[Vishnu V. Krishnan]

Thanks for the detailed reply, Zaak. I reported the occurance, not because it
was causing any runtime error, but so that you guys could sanitize whatever
was causig it, assuming that you would at some point, like your builds to be
"reproducible" ( https://reproducible-builds.org/ )

Cheers!
Vishnu