When the protobuf libraries have been compiled as shared libraries the users of the library need to add `-DPROTOBUF_USE_DLLS` to their build line. Otherwise some symbols are missing.
Fixes#12699
FWIW, I am not sure this is an ideal fix. It may be better to fix the headers such that no macros change the ABI.
Closes#12700
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12700 from coryan:fix-define-protobuf-use-dlls-in-pkg-config-file 13c792eebd
PiperOrigin-RevId: 530116678
This migrates from reusable workflows to composite GHA actions. This has the following advantages:
1) We can split them into smaller, easier to reason about chunks
2) We can reuse them more freely between each other and workflows
3) They don't complicate the job names
4) In theory they'll be easier to test in isolation. While composite actions can't be unit-tested, we can easily break them up into nodejs or docker actions that can be.
As a proof of concept, some of our non-Bazel tests are migrated to GHA as well (CMake + Composer)
Closes#11718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11718 from protocolbuffers:gha-actions 5403307bc00616e94816aa460813939d8f37a1bd
PiperOrigin-RevId: 506375417
* Use generated WKT code in Bazel builds
* Prefer src over external for genrule
* Prefer external over src for genrule
* Proper fix for windows proto path issues
When using "FetchContent_Declare" with OVERRIDE_FIND_PACKAGE,
protobuf-config.cmake won't be used, thus the protobuf-generate macro
would be unavailable. By moving protobuf_generate to its own file, it
can be sourced and used even when using CMake's FetchContent.
Co-authored-by: Harald Fernengel <547273+haraldF@users.noreply.github.com>
* Proof of concept for Abseil dependency
* Adding most common Abseil libraries
* Fixing shared library breakages
* Switching to quotes over angled brackets
* Disable install target by default
* Fixing abseil to LTS commit
* Upgrade to latest Abseil LTS
* Turning install back on by default, removing unnecessary export statements
* Add note to future self
* Fixing unsafe globals
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
* Initial implementation of cmake tests for linux
* Reverting accidental distcheck changes
* Deleting extract_includes.bat now that it's been replaced with the generated file_lists.cmake
* Removing unnecessary endif conditions
Package repositories such as NixOS will pass
an absolute paths to CMAKE.
- Also clarify installation of cmake configuration
files between the build and install directories.
This reverts commit c80808ce1d.
Thix fixes#10045. Somehow the change caused these four .cmake files to
stop being installed:
protobuf-config.cmake
protobuf-config-version.cmake
protobuf-module.cmake
protobuf-options.cmake
After reverting the change, I confirmed that the files are being
installed again.
* Avoid exporting build tree targets to installation directory
`export(TARGETS ...)` is meant to allow for build trees to be found
from other projects, however, writing the file to an installation
directory causes buildtree paths to be hardcoded in the installed
protobuf-targets.cmake
* Install protobuf-targets.cmake from target, not build tree
This allows for installation prefixes to match the intended
installation directories, instead of being copied from
the build tree.
In some platforms ${CMAKE_INSTALL_LIBDIR} expands to `lib64`. The libraries
are correctly installed in that directory, but the RPATH is set to point to
`$ORIGIN/../lib`, where it should be `$ORIGIN/../lib64`.
* CMake: Add comment for CMP0048
* CMake: osx use @rpath/ as target's install name (CMP0042)
On MacoS library should use @rpath/ as prefix path instead of absolute build path
e.g. otool -L libprotobuf.dylib
libprotobuf.dylib:
@rpath/libprotobuf.dylib (...)
...
* CMake: add rpath to target for LINUX and APPLE
Ruby: generated foo.proto -> foo_pb.rb instead of foo.rb.
This brings us more into line with other langauges, and makes it more
obvious when we are requiring protobuf generated code.
Add a script to build protoc zip packages.
[ci skip]
Change-Id: Ia0e0bf3bb6bd24633dc8f294318bb20ac837f8b9
Ruby: translate package names from snake_case -> PascalCase.
Added unit test for PascalCasing package names in Ruby.
Added new file to ruby_EXTRA_DIST.
A series of improvements:
- Improved Protobuf module compatibility (disabled by default);
- Hide advanced settings;
- Added build tree configuration;
- Added build of examples.
Carlos O'Ryan
Mike Kruskal
Mike Kruskal
Harald Fernengel
Jonathan Ringer
Adam Cozzette
Arfrever Frehtes Taifersar Arahesis
johanmoe
Anton Danielsson
Tongliang Liao
Daniel Joos
listonjesse
Carlos O'Ryan
Mizux
Yangqing Jia
Jisi Liu
Axel Huebl
Feng Xiao
Adnan
Walter Gray
Konstantin Podsvirov
Jeff Merver