Opened 3 years ago
Closed 3 years ago
#63081 closed defect (fixed)
libcmis @0.5.2_1: fails to build
Reported by: | stilwellweather | Owned by: | Tatsh (Andrew Udvare) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | YesNo801 | |
Port: | libcmis |
Description
I'm running the MacPorts git development branch on Big Sur 11.4 and get a build error when attempting to update libcmis.
I think the error is related to this series of terminal output:
:info:build Undefined symbols for architecture x86_64: :info:build "boost::gregorian::greg_month::as_short_string() const", referenced from: :info:build boost::date_time::month_formatter<boost::gregorian::greg_month, boost::date_time::simple_format<char>, char>::format_month(boost::gregorian::greg_month const&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in libcmis.a(libcmis_la-object.o) :info:build ld: symbol(s) not found for architecture x86_64
Log file attached
Attachments (1)
Change History (10)
Changed 3 years ago by stilwellweather
comment:1 Changed 3 years ago by reneeotten (Renee Otten)
comment:2 Changed 3 years ago by reneeotten (Renee Otten)
for a "solution" right now, you can build locally in trace-mode (sudo port -t install libcmis
) so that it will ignore the boost
port if it is already installed or wait until the buildbots have generated a binary.
comment:3 Changed 3 years ago by reneeotten (Renee Otten)
Cc: | YesNo801 added |
---|
comment:4 Changed 3 years ago by reneeotten (Renee Otten)
okay, I cannot figure it out. It picks up the 1.71 headers in configure
and the problem is that it does -I/opt/local/include
before -I/opt/local/libexec/boost/1.76
j, but I have not succeeded in changing that order or otherwise telling it to do what I want. I give up - not personally using this port and don't want to spend more time on it...
I am sure it's trivial for someone who has dealt with this before... so please go ahead and I'll try to learn from it ;)
comment:5 Changed 3 years ago by Tatsh (Andrew Udvare)
I spent some time looking into this and I don't know how we can override the include path to prefer a non-built-in path other than using -nostdinc -I[boost::install_area] -I${prefix}/include
which might be feasible since this project's code is small.
The other possible solution for now is to temporarily deactivate boost: port -f deactivate boost && port install --unrequested libcmis && port activate boost
comment:6 Changed 3 years ago by Tatsh (Andrew Udvare)
Technically upstream isn't libcmis, but https://github.com/tsuna/boost.m4 . A PR was made to possibly fix this issue, but I tried with this patched version of boost.m4
and it did not fix it. https://github.com/tsuna/boost.m4/pull/82
comment:7 Changed 3 years ago by reneeotten (Renee Otten)
this should probably work now after the recent changes to the boost
PG. Can you try again and let us know?
comment:9 Changed 3 years ago by reneeotten (Renee Otten)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I can reproduce this locally when the
boost
port is also installed; it picks up files from${prefix}/include/boost
instead of using the specified one in/opt/local/libexec/boost/1.76
. I am looking for the correct configure variable now to correct this...