qt5-qtlocation fails to link when rapidjson-devel is used

[barracuda156]

  mbgl::style::TextField::key, referenced from:
      void mbgl::style::conversion::stringify<mbgl::style::TextField, rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>, rapidjson::CrtAllocator>, rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator, 0u>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>(rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>, rapidjson::CrtAllocator>, rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator, 0u>&, mbgl::style::DataDrivenPropertyValue<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>> const&) in libqmapboxgl.a[220](symbol_layer.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [../../../../plugins/geoservices/libqtgeoservices_mapboxgl.dylib] Error 1

[chrstphrchvz (Christopher Chavez)]

qt5-qtlocation @5.15.11_0 is known to build for Sonoma on Intel, so maybe this issue is specific to ARM.

[chrstphrchvz (Christopher Chavez)]

I do not see any upstream bug reports for this already. I would note that the bundled Mapbox GL Native is from 2020 (open source development of it has since ceased; although there is a fork, maplibre-native).

I guess I would start by asking what symbols does e.g. /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qtlocation/work/qtlocation-everywhere-src-5.15.11/src/3rdparty/mapbox-gl-native/.obj/src/mbgl/style/layers/symbol_layer_properties.o contain, for comparison with Intel and what the error says is expected.

[chrstphrchvz (Christopher Chavez)]

Not sure if I am checking correctly, but on Intel, I find that not only does …/work/qtlocation-everywhere-src-5.15.11/src/3rdparty/mapbox-gl-native/.obj/src/mbgl/style/layers/symbol_layer_properties.o contain no symbols (according to otool -TV), but neither does …/qt5-qtlocation/work/qtlocation-everywhere-src-5.15.11/lib/libqmapboxgl.a.

[chrstphrchvz (Christopher Chavez)]

Sorry, I should not be using otool -TV anymore since it is obsolete. I will try nm instead…

mbgl::style::TextField::key is nowhere in libqmapboxgl.a; I was guessing it would at least appear in symbol_layer_properties.o, but nm says there are no symbols in symbol_layer_properties.o. Yet libqmapboxgl.a still contains void mbgl::style::conversion::stringify<mbgl::style::TextField, rapidjson::Writer… (from symbol_layer.o).

[barracuda156]

Still fails.

[barracuda156]

Replying to chrstphrchvz:

Turns out that qt5-qtlocation is broken with rapidjson-devel, but builds fine with an old rapidjson. Cannot test this on Intel, but I suspect it might be broken everywhere then, just we do not see it on buildbots, because they use the old rapidjson.

[barracuda156]

Opened an issue with rapidjson upstream to see if they advise something: ​https://github.com/Tencent/rapidjson/issues/2240

[chrstphrchvz (Christopher Chavez)]

I do not think upstream rapidjson should be bothered about this issue. The incompatibility between older and newer rapidjson is likely intentional, and that mixing them is not a configuration they can support.

Currently I would guess that -I${prefix}/include or a similar include flag is taking precedence over qtlocation’s bundled rapidjson. The simplest workaround would likely be to use the conflicts_build portgroup.

[barracuda156]

Replying to chrstphrchvz:

I do not think upstream rapidjson should be bothered about this issue. The incompatibility between older and newer rapidjson is likely intentional, and that mixing them is not a configuration they can support.

Well, I do not insist it is a bug or that upstream should do something about that necessarily. Informing them does not hurt; and “it is intended, not a bug” would be a valid response (if it is the case).

[chrstphrchvz (Christopher Chavez)]

I believe this issue also affects other qtlocation versions with bundled Mapbox GL Native: qt59-qtlocation, qt511-qtlocation, qt513-qtlocation

Replying to chrstphrchvz:

The simplest workaround would likely be to use the conflicts_build portgroup.

This is proposed in ​https://github.com/macports/macports-ports/pull/21961

[chrstphrchvz (Christopher Chavez)]

In bf029a7fcad5ad39a7301d6ee273c2210cd75f80/macports-ports (master):

qt(59|511|513|5)-qtlocation: conflicts_build rapidjson(devel)

Closes: #68508