Re: nlohmann-json3-dev need to be reverted to trixie version
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 <ballombe@debian.org> 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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: