export CFLAGS=-DNLOHMANN_JSON_NAMESPACE_NO_VERSION=1Hello, new idea, what if I upload 3.12 with abi stick to 3.11, such as not changing the namespace anymore? #define NLOHMANN_JSON_ABI_TAGS_CONCAT_EX(a, b, c) json_abi ## a ## b ## c
It might be a matter of patching out this string, to avoid putting that stuff inside the library. My proposal is: 1) Upload 3.12 with 3.11 hardcoded in library. 2) From 3.12+ try to make some sort of transition and make this ABI version disappear from library. Any comment on the above? Also this might be interesting https://salsa.debian.org/debian/nlohmann-json3/-/blob/master/single_include/nlohmann/json.hpp?ref_type=heads#L103 #ifndef NLOHMANN_JSON_NAMESPACE_NO_VERSION #define NLOHMANN_JSON_NAMESPACE_NO_VERSION 0 #endif I tried to build xeus with export CFLAGS=-DNLOHMANN_JSON_NAMESPACE_NO_VERSION=1 export CXXFLAGS=-DNLOHMANN_JSON_NAMESPACE_NO_VERSION=1 so my proposal is to make that NAMESPACE_NO_VERSION default inside nlohmann-json3 code from next release, what do you think? G. Il lunedì 15 settembre 2025 alle ore 23:19:18 CEST, Bill Allombert <[email protected]> ha scritto: On Mon, Sep 15, 2025 at 08:23:50PM +0000, Gianfranco Costamagna wrote: > Hello, > > >I do not see much alternative. > > I still would like to quickly have a strong solution to this instead of > reverting to old version > > >We tried to explain this four times already. If you were unsure, you could > >have discussed your plan in the bug report #1106511 in advance, and please > >remember to always CC the submitter when posting to a bug, otherwise the > >submitter does not get a copy, only the maintainer. > > I got a ton of bug reports, tried to find the discussion, and I still didn't > manage to find it, 1106511 doesn't contain the information > my brain is sure to have read some time ago, but don't remember where > > >libxeus11 is a shared library and so has a _fixed_ ABI that _cannot_ be > >changed. > >However its ABI incorporates nlohmann-json3 ABI so it needs to be build > >always with the same nlohmann-json3 ABI. > >However nlohmann-json3 upstream has set up nlohmann-json3 so that its ABI > >include the version number, so > >that means that libxeus11 must always be built with the exact same version > >of nlohmann-json3, which is 3.11.3. > >When libxeus12 is released, it will incorporate a newer nlohmann-json3 > >version, and so we will be able to move to > >that new version, but not before. > > > >Rebuilding libxeus11 with 3.12.0 with lead to a libxeus11 package with a > >wrong ABI. > > I presume having libxeus11a/b/c is a no-go, I don't want to discuss because > looks wrong to me too. Yes this would be a Debian specific ABI. This would be annoying. > I still would like to know if we can fix by having some shlibs bump like > libfilezilla did some years ago, forcing rebuilds, > or to have libxeuss11 implement some abi Provide in the same way > nlohmann-json3 is now doing. Would it be feasible? If you change nlohmann-json3 ABI, you change libxeus11 ABI, so you need a new soname for libxeus11 (say libxeus11-nlohmann-json3.12.0) so a Debian-specific ABI, and according to Debian convention, a new package name libxeus11-nlohmann-json3.12.0. Having a package name change due to a binNMU is not realistic. And not just for libeus but for all other libraries affected. > At the end we are speaking about forcing reverse-dependencies to pick up the > right version, and make sure it is used or rebuilt This is not possible. You cannot change the ABI in a binNMU. The only solution is to use a different source and binary package name for every nlohmann-json3 versions, as I explain in the bug report. > just a question, why is xeus the only affected package? It is not, it is just that nobody has reported the bug for other libs. For example libvisp-mbt3.6t64 has the same bug: stable: libvisp-mbt3.6t64_3.6.0-5_amd64.deb % nm -D usr/lib/x86_64-linux-gnu/libvisp_mbt.so.3.6.0 | grep nlohmann U _ZN19vpHomogeneousMatrix10parse_jsonERKN8nlohmann16json_abi_v3_11_310basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE U _ZNK19vpHomogeneousMatrix15convert_to_jsonERN8nlohmann16json_abi_v3_11_310basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE so v3_11_3 testing: libvisp-mbt3.6t64_3.6.0-5+b1_amd64.deb % nm -D usr/lib/x86_64-linux-gnu/libvisp_mbt.so.3.6.0 | grep nlohmann U _ZN19vpHomogeneousMatrix10parse_jsonERKN8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE U _ZNK19vpHomogeneousMatrix15convert_to_jsonERN8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS1_14adl_serializerES4_IhSaIhEEvEE so v3_12_0 So the binNMU changed the ABI, which is wrong. This will cause a crash when upgrading to forky. Now really to fix this bug you need to check every library linking with nlohmann-json and report a bug if they use the wrong ABI. Once the correct nlohmann-json3 3.11.3 is back in the archive, you can request a binNMU of the affected packages. If you want to upload 3.12.0, create new source nlohmann-json3.12.0 and binary package nlohmann-json3.12.0-dev. Cheers, -- Bill. <[email protected]> Imagine a large red swirl here.
