According to the protobuf migration guide as of June 2023 [0], protobuf
22.0 (aka 4.22.0) took a dependency on something called "abseil" and as
a result the "stubs" have been removed. This apparently caused all the
uses of GOOGLE_* identifiers in protoc-c to fail when building against
newer versions of protobuf.
This commit introduces compatibility definitions when building against
protobuf >= 4.22.0 so that protobuf-c can build against older and newer
versions of protobuf.
[0] https://web.archive.org/web/20230611151200/https://protobuf.dev/support/migration/#abseil
Looking at where these identifiers are ultimately defined [0], it looks
like "DFATAL" means either "ERROR" or "FATAL" depending on whether
NDEBUG is defined. However, looking at the actual code sites in protoc-c
where DFATAL is used, it's not clear why we couldn't just use FATAL
unconditionally.
This is aimed at supporting newer versions of protobuf where the DFATAL
identifier apparently no longer exists.
[0] https://github.com/protocolbuffers/protobuf/blob/v21.12/src/google/protobuf/stubs/logging.h#L61-L65
protobuf has removed the definition of this macro as of commit
1595417dd3859bbff7d3d61ad0b6e39044d47489, so the invocation of this
macro in protobuf-c breaks the build when building agaist the protobuf
22.x or 23.x series.
Simply removing the macro invocations seems to be safe and doesn't break
the build on Debian's protobuf 3.21.12 nor Debian's protobuf 3.6.1.3.
protoc depends on protobuf libraries for execution. Order libraries
accordingly. Observing link errors with yocto's meta-mingw project
during static linkage.
Signed-off-by: Sinan Kaya <sinan.kaya@microsoft.com>
The steps to add this functionality are from the cmake tutorial:
https://cmake.org/cmake/help/latest/guide/tutorial/index.html
The include directories being set on the targets is necessary
for dependent targets. There is some redundancy with the
INCLUDE_DIRECTORIES calls alreday present, but I left it alone
to make the PR smaller and more approachable.
The project currently uses mixed cases in functions. This uses
lowercase on calls I touched, as this is what CMake documentation
uses and seems to be the preferred way.
I also started wrapping long lines, as some of the lines I touched
were over 170 characters.
I tested this on both Mac OS 10.15 Catalina and CentOS 7 (with
devtoolset-7) with CMake 3.10.3.
Will work on tests in CI next.
From https://developers.google.com/protocol-buffers/docs/proto3#updating:
int32, uint32, int64, uint64, and bool are all compatible – this means
you can change a field from one of these types to another without
breaking forwards- or backwards-compatibility. If a number is parsed
from the wire which doesn't fit in the corresponding type, you will
get the same effect as if you had cast the number to that type in C++
(e.g. if a 64-bit number is read as an int32, it will be truncated to
32 bits).
Until this fix, protobuf-c did not conform to the rule above when it
came to deserializing non-boolean packed repeated data into a
protobuf_c_boolean array. Fully scan the varint and use parse_boolean to
truncate the resulting value.
Fixes#440
FullName* methods are designed to split a full name based on '.' in the
name. name() does not have '.' separators, so call CamelToLower and
CamelToUpper in place of FullNameToLower and FullNameToUpper.
Allows for generic oneof offset lookups based on the name of the oneof,
instead of having to know the field name. All oneof fields should have
the same offset, since they are members of a union.
Fixes#204
Allows treating proto strings as ProtobufCBinaryData to work around
limitations such as NULL characters in strings, which are allowed in
protobuf, but not allowed in 'char *' types.
Fixes#203
Add options controller helper function generation. Preserve existing
behavior of not generating pack/unpack functions for sub-messages if
option is not explicitly set.
Fixes#240Fixes#442
Allows suppression of .pb-c.{c,h} file generation on a .proto file
basis.
protobuf-c.proto: Use the new option in itself, because the options are
never used by protobuf-c runtime, only by the protoc-gen-c compiler.
t/test-full.proto: import protobuf-c.proto to test that
protobuf-c.pb-c.h dependency does not get included in test-full.pb-c.h.
MSVC has issues importing protobuf_c_empty_string from the DLL and using
it in initializers, resulting in errors like when linking against
protobuf-c.dll:
test-proto3.pb-c.c(13): error C2099: initializer is not a constant
test-proto3.pb-c.c(19): error C2440: 'initializing': cannot convert from 'void *' to 'Foo__Person__PhoneType'
Work around the issue by not exporting protobuf_c_empty string and
defining it as static const char[] in the protobuf-c.h file itself. This
change only applies to _WIN32 shared library builds.
A user of the protobuf-c library is confronted with MSVC warnings about missing
PDB if the library happens to be built/configured using the CMAKE_BUILD_TYPE
"Debug" or "RelWithDebInfo". This commit deals away with the warning by
installing the "protobuf-c.pdb" alongside the lib. The .pdb is installed only
if it exists. Configuring "Release" or building under Linux won't produce and
won't install the PDB.
The protobuf common.h header currently has a "using std::string;"
statement that pulls std::string into the google::protobuf namespace:
ce66f6047d/src/google/protobuf/stubs/common.h (L195)
I plan to delete that line soon. To keep protobuf-c working, this commit
updates the generator to fully qualify std::string.
Bionic contains more recent compilers, which are required to have
the sanitisers work under s390x.
While we're at it, the 'sudo' key is deprecated, so remove it:
https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration
(It used to be used to mark VM vs docker container infrastructure,
but currently all amd64 builds run on VMs and all other archs run
inside LXD containers.)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Fixes#188.
Implements suggested fix from the issue:
The struct tag namespace is different from the type namespace. Use the
same symbol names (i.e. without leading underscores) in every namespace.
PACKAGE_DESCRIPTION is defined in configure.ac. PACKAGE_NAME,
PACKAGE_VERSION, and PACKAGE_URL come from AC_INIT.
This change will ensure that libprotobuf-c.pc.in could also be used by
CMake.
Issue #330 is a bug in proto3 behavior and the test case handling it
needs a 'syntax = "proto3";' line in its .proto file, which is not
supported by the protobuf 2 implementation.
Since we still support building against protobuf 2, this commit
conditionalizes the Issue #330 test case so that it is only built when
protobuf-c is being built against protobuf 3.
