5.6.0::macos intel libuuid:: undefined symbols for _libintl_gettext

[adriansev]

Hi @amadio ! With 5.6.0 we have a weird problem in intel macos where we get an error like:

[ 89%] Linking CXX shared library libXrdCl.dylib
ld: warning: dylib (/usr/local/opt/openssl@1.1/lib/libssl.dylib) was built for newer macOS version (13.0) than being linked (10.15)
ld: warning: dylib (/usr/local/opt/openssl@1.1/lib/libcrypto.dylib) was built for newer macOS version (13.0) than being linked (10.15)
Undefined symbols for architecture x86_64:
  "_libintl_gettext", referenced from:
      _random_tell_source in libuuid.a(libuuid_la-randutils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

some relevant details can be seen in comment alisw/alidist#5066 (comment)

Any idea about this?
Thanks a lot!

[amadio]

From what I see the static libuuid.a is not forwarding its own required dependencies to xrootd, who is trying to link against it. I see that you are potentially picking up openssl from Homebrew. If Homebrew dependencies are ok for you, I'd just install ossp-uuid, which is what I tested against on macOS (we test against Homebrew dependencies). If you want to pick up uuid provided by AliBuild, then I'd edit the pkg-config file for uuid so that it properly propagates all required flags when linking against the static library. However it may also be the case that my updated module to find uuid is not quite right and we may need to update it to pick up the right flags to link against a static libuuid. I will have a closer look at this tomorrow.

[amadio]

Do you happen to have a recipe I can use to reproduce this? I wonder what's different in your brew and mine to cause the problem.

[adriansev]

Hi! So, our recipe is this https://github.com/alisw/alidist/blob/master/xrootd.sh#L39
i point to start from this line as the intel macos is the only test that fails.
The cmake line is: https://github.com/alisw/alidist/blob/master/xrootd.sh#L71

to see our tests status see the PR alisw/alidist#5066

@TimoWilken suggested Maybe we should patch UUID's pkgconfig file to include -lintl, but I don't know if that's the right thing to do, since it works on the ARM Mac, and v5.5.3 of XRootD builds fine as-is, without explicitly specifying -lintl...

[amadio]

I have no permission to see the actual logs. I see that you unset UUID_ROOT (therefore do not pass any option to find it) in your recipe. On macOS, where is UUID coming from? Do you have the oosp-uuid package installed from Homebrew? You may need to set CMAKE_PREFIX_PATH or some other variable to find it. Is the static library you are linking against coming from where you expect?

[adriansev]

Hi @amadio you can see the full build log here:
https://asevcenc.web.cern.ch/asevcenc/xrootd_compilation_error/

on macos i have no idea what uuid is used, i will ping @TimoWilken as he is the software release and build guru

[TimoWilken]

Hm, that's true, that's an inconsistency. Our recipe still depends on AliEn-Runtime, which pulls in our UUID package. That sets PKG_CONFIG_PATH, so XRootD finds it through its installed .pc file. You can see this in the build log:

-- Checking for module 'uuid'
--   Found uuid, version UNKNOWN..0
-- Found libuuid: /Volumes/build/build/alice-ci-workdir/alidist-o2/sw/osx_x86-64/UUID/v2.27.1-local1/include/uuid  

We do not have ossp-uuid installed on the system through brew.

It works locally for me if I add --disable-nls to the compile options of UUID, but that'll cause a large rebuild, also on Linux...

[amadio]

@adriansev Thanks for the log.

@TimoWilken Ok, if you don't want to affect Linux, the easiest solution may be to install and pick up ossp-uuid from Homebrew on macOS.

It would be useful to have also the CMakeCache.txt and a verbose build output so that the full command which was run by CMake is visible. I could use these to adjust how I use pkg-config in Findlibuuid.cmake to work with your installed version of uuid. It could be that there's something I did not add, but should have added.

As a side comment, there were several changes in the build system and Python bindings, so I think your recipe could be updated to drop some options that no longer do anything, and to use a PEP517 build for the Python bindings. See https://github.com/xrootd/xrootd/blob/master/bindings/python/README.md for more information.

[TimoWilken]

Thanks @amadio. I think we need to change our libuuid in this case since apparently we've had problems using brew's libuuid in the past.

I've pushed a fix for it to the PR that set off this discussion (alisw/alidist#5066); hopefully it'll work now.

Thanks for the hint about unneeded build options, I'll leave @adriansev to change those if he prefers to!

[amadio]

I created a new pull request: alisw/alidist#5075. Please let me know how that works for you. I can update the uuid settings too before you merge.

[adriansev]

Thanks a lot! Well, that would be a second step, first would be to make the recipe "accepted" into our ecosystem and then do the improvements and updating of the recipe.

[amadio]

I have a fix for this issue which I will put in a patch release this coming week. Indeed, we used to detect and use the kernel uuid provided by macOS before, and after my recent changes, I see that this detection was broken.

[adriansev]

Thanks a lot @amadio for the help!!! Now that our tests are green (the the problem is understood) i think this can be closed ... would you like to be closed by you as solved by fb61481 ?

[amadio]

This will be automatically closed when I merge that into master, please leave it open for the time being. Thanks!