After upgrade to Boost 1.75, compilation fails with ld: library not found for -licudata #67427

alvaropalmaaste · 2020-12-22T16:28:42Z

Bug report

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

ran brew update and can still reproduce the problem?
ran brew doctor, fixed all issues and can still reproduce the problem?
ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link?
if brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)

I simply upgraded boost to 1.75.0 using brew upgrade

What happened (include command output)

An application depending on boost no longer compiles successfully, now it returns:

ld: library not found for -licudata

Command output

ld: library not found for -licudata

What you expected to happen

To keep the behavior when boost 1.74.0 was installed.

Step-by-step reproduction instructions (by running `brew install` commands)

brew upgrade
Recompile any application using Boost::regex library

The text was updated successfully, but these errors were encountered:

alvaropalmaaste · 2020-12-22T16:32:26Z

I can simply fix the issue by creating manually the links to libicudata and others in /usr/local/lib (I have already installed icu4c, since boost 1.74.0 also depended on it, but there was no links to their libraries under that directory).

What intrigues me is the fact that boost::regex, which seems to be the culprit, hasn't changed any dependency between 1.74 and 1.75, as you can see here:

1.74 dependencies:

[12:42 apalma@alicanmini1 -> ~/MinePlanner/CMPMaster] otool -L /usr/local/Cellar/boost/1.74.0/lib/libboost_regex-mt.dylib
/usr/local/Cellar/boost/1.74.0/lib/libboost_regex-mt.dylib:
        /usr/local/opt/boost/lib/libboost_regex-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/local/opt/icu4c/lib/libicudata.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/local/opt/icu4c/lib/libicui18n.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/local/opt/icu4c/lib/libicuuc.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

1.75 dependencies:

[12:42 apalma@alicanmini1 -> ~/MinePlanner/CMPMaster] otool -L /usr/local/Cellar/boost/1.75.0/lib/libboost_regex-mt.dylib
/usr/local/Cellar/boost/1.75.0/lib/libboost_regex-mt.dylib:
        /usr/local/opt/boost/lib/libboost_regex-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/local/opt/icu4c/lib/libicudata.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/local/opt/icu4c/lib/libicui18n.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/local/opt/icu4c/lib/libicuuc.67.dylib (compatibility version 67.0.0, current version 67.1.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

So I can't understand why now I need libicudata.dylib in /usr/local/lib.

scpeters · 2020-12-22T18:34:33Z

I've noticed the same thing and opened an upstream issue about it: boostorg/boost_install#47

carlocab · 2020-12-23T08:06:54Z

@alvaropalmaaste, do you have a MWE? I don't think it's sufficient to just recompile something that uses Boost's regex library.

A lot of the initial CI failures from the Boost update came from formulae that used Boost's regex library, but I found that recompiling them against Boost 1.75 seemed to have fixed it, so it seems there's something more needed in order to reproduce this.

That said, it looks like a fix has been pushed to the develop branch: boostorg/boost_install@7b3fc73

If someone could test this, I'd appreciate it, so I can look into incorporating the fix into the Boost formula.

Time0o · 2020-12-23T08:34:47Z

@carlocab I discovered this when I tried to build a library depending on Boost Regex in a GithubActions VM. So on a "fresh" system, where only [email protected] is installed and everything is compiled from scratch this also fails unless I add /usr/local/opt/icu4c/lib to the linker path (and even then it fails at runtime unless I links those files to /usr/local/lib instead).

carlocab · 2020-12-23T08:37:09Z

Thanks @Time0o. I still need a MWE though.

Time0o · 2020-12-23T08:38:28Z

@carlocab I will try to create one by stripping down my project, give me a minute.

EDIT: might take a while, GitHub Actions macOS builds are currently experiencing issues (I think they announced this) and in my case brew times out repeatedly.

Time0o · 2020-12-23T09:25:37Z

@carlocab Okay, seems to work now, here is a simple repository and here is the action that fails because of -licudata.

I hope this is what you're looking for, I don't actually have a Mac so I had to do it this way.

carlocab · 2020-12-23T13:51:39Z

This is excellent, @Time0o. Thank you for this.

Update: I don't quite have the time to take a close look at this at the moment, but it's on my list.

scpeters · 2020-12-24T07:26:59Z

I've tested the patch, and it works for me, so I've submitted it in #67615.

In boost 1.75.0, the cmake INTERFACE_LINK_LIBRARIESS now include non-boost dependencies like libicudata from the keg-only formula icu4c. This introduces linking errors for software that previously linked successfully in brew against boost 1.74.0 shared libraries (see Homebrew#67427 and boostorg/boost_install#47). This adds a patch to the boost formula that has been merged upstream to limit the expansion of INTERFACE_LINK_LIBRARIES to boost's static libraries, so that the linking errors with shared libraries are resolved.

In boost 1.75.0, the cmake INTERFACE_LINK_LIBRARIESS now include non-boost dependencies like libicudata from the keg-only formula icu4c. This introduces linking errors for software that previously linked successfully in brew against boost 1.74.0 shared libraries (see #67427 and boostorg/boost_install#47). This adds a patch to the boost formula that has been merged upstream to limit the expansion of INTERFACE_LINK_LIBRARIES to boost's static libraries, so that the linking errors with shared libraries are resolved.

carlocab · 2021-01-03T21:11:16Z

#67615 has been merged, so this should be fixed now.

alvaropalmaaste · 2021-01-04T13:53:01Z

Indeed, the issue still exists.

carlocab · 2021-01-04T14:14:13Z

Are you sure? Have you done brew update && brew upgrade boost yet?

Because I just re-ran @Time0o's example, and it now works: https://github.com/carlocab/macos-boost1.75-regex-bug/runs/1644170782?check_suite_focus=true

I also tested it locally, and it works for me too.

If it's still not working for you, then you need to provide a minimum working example that can reproduce the error.

Time0o · 2021-01-04T17:36:01Z

Weirdly enough, I'm also still having this problem in the project where I originally discovered it and I don't know why since the minimal example now seems to be working. Does brew update update brew to the head of the current master branch?

carlocab · 2021-01-04T17:37:45Z

It should unless you've broken your local core repo somehow. What does brew config and brew doctor say? And brew info boost?

alvaropalmaaste · 2021-01-04T17:53:46Z

Indeed, I have the same issue. The MWE works fine, but my larger project fails.

alvaropalmaaste · 2021-01-04T17:56:07Z

As requested:

[14:54 cmp@alicanmini1 -> ~] brew doctor
Your system is ready to brew.

[14:54 cmp@alicanmini1 -> ~] brew config
HOMEBREW_VERSION: 2.7.1
ORIGIN: https://github.com/Homebrew/brew
HEAD: fdb71a5cb3029da2ef74d7e09c40575bbfb4ec72
Last commit: 7 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 75f696ff9c349d404c1cfdb50d0c05a30d37f406
Core tap last commit: 4 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 6
Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
CPU: hexa-core 64-bit kabylake
Clang: 12.0 build 1200
Git: 2.24.3 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
Java: 14.0.2
macOS: 10.15.7-x86_64
CLT: 12.0.32.28
Xcode: 12.3

[14:54 cmp@alicanmini1 -> ~] brew info boost
boost: stable 1.75.0 (bottled), HEAD
Collection of portable C++ source libraries
https://www.boost.org/
/usr/local/Cellar/boost/1.75.0_1 (15,058 files, 524.2MB) *
  Poured from bottle on 2021-01-04 at 11:19:59
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/boost.rb
License: BSL-1.0
==> Dependencies
Required: icu4c ✔
==> Options
--HEAD
        Install HEAD version
==> Analytics
install: 60,603 (30 days), 181,652 (90 days), 622,701 (365 days)
install-on-request: 20,716 (30 days), 58,407 (90 days), 211,896 (365 days)
build-error: 0 (30 days)

I'm still on Catalina, haven't upgraded to BigSur yet. May that be the issue?:

[14:54 cmp@alicanmini1 -> ~] sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.7
BuildVersion:   19H114

carlocab · 2021-01-04T17:56:15Z

I don't think there's anything actionable here until:

you ... provide a minimum working example that can reproduce the error.

carlocab · 2021-01-04T17:57:11Z

I'm still on Catalina, haven't upgraded to BigSur yet. May that be the issue?

I don't think so, as the GitHub runners for the MWE were running Catalina.

alvaropalmaaste · 2021-01-04T17:58:23Z

Maybe this is related to another boost library? I'm using filesystem, program_options, regex, system, thread, stacktrace_addr2line and python. I'll try to reproduce the error using one of those.

Time0o · 2021-01-04T18:08:04Z

EDIT: the repo is this one, I'm probably overlooking something simple.

@carlocab: I still haven't gotten my hands on a mac so this is in a fresh GitHub Actions vm, after brew upgrade and brew cleanup I get:

brew config:

  HOMEBREW_VERSION: 2.7.1
  ORIGIN: https://github.com/Homebrew/brew
  HEAD: fdb71a5cb3029da2ef74d7e09c40575bbfb4ec72
  Last commit: 7 days ago
  Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
  Core tap HEAD: 75d3d79a28a4ddea9689e59d198f800656e4479f
  Core tap last commit: 25 minutes ago
  Core tap branch: master
  HOMEBREW_PREFIX: /usr/local
  HOMEBREW_CASK_OPTS: ["--no-quarantine"]
  HOMEBREW_COLOR: set
  HOMEBREW_MAKE_JOBS: 3
  HOMEBREW_NO_AUTO_UPDATE: set
  Homebrew Ruby: 2.6.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
  CPU: 3-core 64-bit ivybridge
  Clang: 12.0 build 1200
  Git: 2.29.2 => /usr/local/bin/git
  Curl: 7.64.1 => /usr/bin/curl
  Java: 14.0.2, 13.0.2, 12.0.2, 11.0.9.1, 1.8.0_275, 1.7.0_285
  macOS: 10.15.7-x86_64
  CLT: 12.2.0.0.1.1604628099
  Xcode: 12.2 => /Applications/Xcode_12.2.app/Contents/Developer

brew doctor:

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
  /Users/runner/hostedtoolcache/Python/3.9.1/x64/bin/python3.9-config
  /Users/runner/hostedtoolcache/Python/3.9.1/x64/bin/python3-config

Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected dylibs:
  /usr/local/lib/libtcl8.6.dylib
  /usr/local/lib/libtk8.6.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
  /usr/local/include/fakemysql.h
  /usr/local/include/fakepq.h
  /usr/local/include/fakesql.h
  /usr/local/include/itcl.h
  /usr/local/include/itcl2TclOO.h
  /usr/local/include/itclDecls.h
  /usr/local/include/itclInt.h
  /usr/local/include/itclIntDecls.h
  /usr/local/include/itclMigrate2TclCore.h
  /usr/local/include/itclTclIntStubsFcn.h
  /usr/local/include/mysqlStubs.h
  /usr/local/include/odbcStubs.h
  /usr/local/include/pqStubs.h
  /usr/local/include/tcl.h
  /usr/local/include/tclDecls.h
  /usr/local/include/tclOO.h
  /usr/local/include/tclOODecls.h
  /usr/local/include/tclPlatDecls.h
  /usr/local/include/tclThread.h
  /usr/local/include/tclTomMath.h
  /usr/local/include/tclTomMathDecls.h
  /usr/local/include/tdbc.h
  /usr/local/include/tdbcDecls.h
  /usr/local/include/tdbcInt.h
  /usr/local/include/tk.h
  /usr/local/include/tkDecls.h
  /usr/local/include/tkPlatDecls.h

Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected .pc files:
  /usr/local/lib/pkgconfig/tcl.pc
  /usr/local/lib/pkgconfig/tk.pc

Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected static libraries:
  /usr/local/lib/libtclstub8.6.a
  /usr/local/lib/libtkstub8.6.a

brew info boost:

 boost: stable 1.75.0 (bottled), HEAD
 Collection of portable C++ source libraries
 https://www.boost.org/
 /usr/local/Cellar/boost/1.75.0_1 (15,058 files, 524.2MB) *
   Poured from bottle on 2021-01-04 at 18:03:17
 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/boost.rb
 License: BSL-1.0
 ==> Dependencies
 Required: icu4c
 ==> Options
 --HEAD
 	Install HEAD version
 ==> Analytics
 install: 60,603 (30 days), 181,652 (90 days), 622,701 (365 days)
 install-on-request: 20,716 (30 days), 58,407 (90 days), 211,896 (365 days)
 build-error: 0 (30 days)

carlocab · 2021-01-04T18:09:50Z

Ok, no obvious explanations there, unfortunately. Looks like we're back to needing a simple way to reproduce the bug.

alvaropalmaaste · 2021-01-04T18:20:42Z

I think I found it, it seems CMake is the culprit. I'm using it to build my environment, and /usr/local/lib/cmake/boost_regex-1.75.0/libboost_regex-variant-mt-static.cmake and /usr/local/lib/cmake/boost_regex-1.75.0/libboost_regex-variant-static.cmake forces the linkage against icudata, icui18n and icuuc:

[15:17 apalma@alicanmini1 -> /usr/local/lib/cmake/boost_regex-1.75.0] ag icudata
libboost_regex-variant-mt-static.cmake
95:    "$<$<CONFIG:release>:icudata;icui18n;icuuc>")
98:    icudata icui18n icuuc)

libboost_regex-variant-static.cmake
100:    "$<$<CONFIG:release>:icudata;icui18n;icuuc>")
103:    icudata icui18n icuuc)

I checked manually removing the forced -licudata -licui18n -licuuc in my generated Makefile, and my app compiles OK.

So, I guess we need to fill a bug for the CMake package now :-)

alvaropalmaaste · 2021-01-04T18:21:42Z

BTW, it seems to happen only in the static libraries (which are the ones I'm using to avoid having to distribute the dynamic ones).

Time0o · 2021-01-04T18:33:33Z

I can confirm that this happens when Boost_USE_STATIC_LIBS is set in the CMakeLists.txt of my MWE.

carlocab · 2021-01-04T18:35:42Z

Hmm, I see. Can you update the original issue filed with boost? boostorg/boost_install#47

Or, perhaps, open a new one. Feel free to ping me if they create another patch to fix it.

Time0o · 2021-01-04T18:42:55Z

I don't quite understand what the root of the issue is, Boost linking against these dependencies when linking statically is intentional, it's just that they're not found on MacOS. Is this now a problem with Boost's .cmake not looking in the right place or with brew not placing the dependencies where they should be?

scpeters · 2021-01-04T20:03:52Z

I don't quite understand what the root of the issue is, Boost linking against these dependencies when linking statically is intentional, it's just that they're not found on MacOS. Is this now a problem with Boost's .cmake not looking in the right place or with brew not placing the dependencies where they should be?

I think you're having trouble finding them on macOS because icu4c is a keg-only formula. If you adjust your LIBRARY_PATH, I think you can help them be found:

export LIBRARY_PATH=${LIBRARY_PATH}:/usr/local/opt/icu4c/lib

alvaropalmaaste · 2021-01-04T20:42:34Z

The problem is that, for an unknown reason, that changed in CMake 3.19.2, making that something that used to work stopped doing it. I guess there's no reason to change the LIBRARY_PATH setting if nothing has changed in your side.

carlocab · 2021-01-04T20:45:24Z

Yea, CMake usually does a good (sometimes too good) job of finding Homebrew dependencies. I don't see why LIBRARY_PATH needs to be set now when it didn't use to be.

scpeters · 2021-01-04T21:59:17Z

The problem is that, for an unknown reason, that changed in CMake 3.19.2, making that something that used to work stopped doing it. I guess there's no reason to change the LIBRARY_PATH setting if nothing has changed in your side.

I don't think it was a change in cmake 3.19.2; I believe it was a change in boost that was included in the 1.75.0 release (boostorg/boost_install@0e39586); see also the comments in boostorg/boost_install#47 (comment)

carlocab · 2021-01-08T02:43:12Z

I checked that setting LIBRARY_PATH fixes the issues for static libraries too: https://github.com/carlocab/macos-boost1.75-regex-bug/runs/1666368660

Also tested successfully locally.

carlocab added the upstream issue An upstream issue report is needed label Dec 23, 2020

scpeters mentioned this issue Dec 24, 2020

boost: patch for INTERFACE_LINK_LIBS bug #67615

Closed

5 tasks

mwydmuch mentioned this issue Dec 31, 2020

vizdoom installation on Mac Farama-Foundation/ViZDoom#481

Closed

mahrud mentioned this issue Jan 1, 2021

1.17 source build fails on macos Macaulay2/M2#1767

Closed

carlocab closed this as completed Jan 3, 2021

fusion2004 mentioned this issue Jan 4, 2021

ld: library not found for -licudata bbc/homebrew-audiowaveform#4

Closed

jamesb93 mentioned this issue Jan 4, 2021

Can't build no 10.14.6 Intel MacOS bbc/audiowaveform#132

Closed

BrewTestBot added the outdated PR was locked due to age label Feb 8, 2021

Homebrew locked as resolved and limited conversation to collaborators Feb 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

After upgrade to Boost 1.75, compilation fails with ld: library not found for -licudata #67427

After upgrade to Boost 1.75, compilation fails with ld: library not found for -licudata #67427

alvaropalmaaste commented Dec 22, 2020

alvaropalmaaste commented Dec 22, 2020

scpeters commented Dec 22, 2020

carlocab commented Dec 23, 2020

Time0o commented Dec 23, 2020

carlocab commented Dec 23, 2020

Time0o commented Dec 23, 2020 •

edited

Loading

Time0o commented Dec 23, 2020 •

edited

Loading

carlocab commented Dec 23, 2020 •

edited

Loading

scpeters commented Dec 24, 2020

carlocab commented Jan 3, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

Time0o commented Jan 4, 2021

carlocab commented Jan 4, 2021 •

edited

Loading

alvaropalmaaste commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

carlocab commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021 •

edited

Loading

Time0o commented Jan 4, 2021 •

edited

Loading

carlocab commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

Time0o commented Jan 4, 2021

carlocab commented Jan 4, 2021

Time0o commented Jan 4, 2021

scpeters commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

scpeters commented Jan 4, 2021

carlocab commented Jan 8, 2021

After upgrade to Boost 1.75, compilation fails with ld: library not found for -licudata #67427

After upgrade to Boost 1.75, compilation fails with ld: library not found for -licudata #67427

Comments

alvaropalmaaste commented Dec 22, 2020

Bug report

What you were trying to do (and why)

What happened (include command output)

What you expected to happen

Step-by-step reproduction instructions (by running brew install commands)

alvaropalmaaste commented Dec 22, 2020

scpeters commented Dec 22, 2020

carlocab commented Dec 23, 2020

Time0o commented Dec 23, 2020

carlocab commented Dec 23, 2020

Time0o commented Dec 23, 2020 • edited Loading

Time0o commented Dec 23, 2020 • edited Loading

carlocab commented Dec 23, 2020 • edited Loading

scpeters commented Dec 24, 2020

carlocab commented Jan 3, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

Time0o commented Jan 4, 2021

carlocab commented Jan 4, 2021 • edited Loading

alvaropalmaaste commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

carlocab commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021 • edited Loading

Time0o commented Jan 4, 2021 • edited Loading

carlocab commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

Time0o commented Jan 4, 2021

carlocab commented Jan 4, 2021

Time0o commented Jan 4, 2021

scpeters commented Jan 4, 2021

alvaropalmaaste commented Jan 4, 2021

carlocab commented Jan 4, 2021

scpeters commented Jan 4, 2021

carlocab commented Jan 8, 2021

Step-by-step reproduction instructions (by running `brew install` commands)

Time0o commented Dec 23, 2020 •

edited

Loading

Time0o commented Dec 23, 2020 •

edited

Loading

carlocab commented Dec 23, 2020 •

edited

Loading

carlocab commented Jan 4, 2021 •

edited

Loading

alvaropalmaaste commented Jan 4, 2021 •

edited

Loading

Time0o commented Jan 4, 2021 •

edited

Loading