-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
p4-fusion fails to build on macOS with recent Helix Core C/C++ API versions #78
Comments
For what it's worth, one of the ways I dealt with similar build troubles on Linux (don't know why you didn't have trouble but I did) was to drop the p4script and p4script_c libraries from t_l_l since I didn't see any reason for lua scripting or curl or sqlite support to be needed (AIUI, those are mostly for the benefit of Helix Core Extensions). I was able to mirror ~25k CLs from a slice of our Perforce depot in the branchless mode successfully on Friday, so if I broke something, it certainly wasn't obvious.
So, I wonder if those libraries even need to be built in the first place for p4-fusion's usecase of blasting large quantities of a handful of commands at the server. It seems likely to me that they aren't needed and that it would simplify things if they in fact aren't needed. I'm early on in building my understanding of the p4-fusion codebase, so I could very well be overlooking something and would encourage other eyes/minds to check my work. |
If I reduce the set of libraries to just The easiest solution would be to include these 7 static libraries on all platforms, and let the linker drop unneeded ones (if there are any). Alternatively, we could introduce branching in CMake per platform. Which solution would you prefer @twarit-waikar ? |
@peter-esik Thanks for looking into this! I don't think anything would have changed in the logic by different libraries being linked on Linux. But letting the linker handle it sounds good. This part of the CMake scripts can turn out to be brittle due to us depending on how Perforce decides to build their libraries, so it's best let the complexity stay low here and let the linker handle chopping off the ones that are not required. |
I think I managed to find a correct solution. There is a copy of the source code of the SDK here (not sure if it is a leak, or legal, though...). Looking at the source code it's easy to see what's going on: some source files in the This is what the By adding this library, my build succeeds on both Linux and macOS. As a bonus, we don't have to refer the sqlite and curl libraries bundled with the SDK, so p4-fusion will still build with older P4 SDK versions. |
…cript_cstub library, for salesforce#78 - The p4client library seems to have unconditional references to the P4Script machinery, even if that feature is not used by the application (in this case, p4-fusion). This causes linking errors (undefined references to sqlite, and curl functions) - The p4script_cstub library seems to be an official solution for this situation, as it contains stubs (dummy, empty implementations) of all relevant functions
The
|
Yikes, my apologies for forgetting/omitting the fact I added the linkage to the cstub library; that was a very important detail! |
Also to ease any concerns about the P4API source licensing mentioned by @peter-esik: |
Repro
p4-fusion
Helix Core C/C++ API
for ARM macOS, at least version2023.2
(somewhat older versions might be affected, too)p4-fusion
Expected: The build succeeds
Actual: The build fails at the linking stage, citing many undefined references to
curl
andsqlite
functions.Interestingly, the issue does not occur on Linux (tried on Ubuntu 22.04 LTS).
The issue can be fixed by adding the
p4script_curl
andp4script_sqlite
libraries here:p4-fusion/p4-fusion/CMakeLists.txt
Line 43 in 3eb4342
I wonder if there are valid use cases for building the tool with older P4 SDK versions.
The text was updated successfully, but these errors were encountered: