Skip to content
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

mac: fix explicit symbol exports #2389

Merged
merged 1 commit into from
Nov 13, 2023
Merged

mac: fix explicit symbol exports #2389

merged 1 commit into from
Nov 13, 2023

Conversation

Riolku
Copy link
Contributor

@Riolku Riolku commented Nov 11, 2023

Exception information necessary for properly catching exceptions, seems to not be exported on Mac unless we export the exception, which seems to be different from Linux & Windows.

In additional, Mac issues a warning when building the Python module (which itself builds as a shared library). The issue is that the python module links with our static library, and the static library does not export symbols (since it doesn't do anything for static libraries).

However, this mismatch in visibility causes a warning. Technically, we shouldn't build a shared library with a static library since the static library isn't position-independent code, but we don't really have other options unless we embed all of the object files?

My current solution is to keep the visibility annotations in the static library, which seems to work fine and avoids the warning. However, we should probably find some other solution. Embedding all of the object files isn't super appealing from a design perspective but seems the easiest. It'd be great to embed the shared library.. but that would require some changes to how we package for python, and I haven't looked into it.

Ref #2136.

@Riolku
Copy link
Contributor Author

Riolku commented Nov 11, 2023

Well, my solution seems to break windows.

@Riolku Riolku marked this pull request as draft November 11, 2023 03:05
Copy link

codecov bot commented Nov 11, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d117fe8) 91.04% compared to head (2b3ff24) 91.04%.
Report is 2 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2389   +/-   ##
=======================================
  Coverage   91.04%   91.04%           
=======================================
  Files        1015     1015           
  Lines       36014    36012    -2     
=======================================
- Hits        32789    32788    -1     
+ Misses       3225     3224    -1     
Files Coverage Δ
src/include/common/exception/binder.h 100.00% <ø> (ø)
src/include/common/exception/buffer_manager.h 0.00% <ø> (ø)
src/include/common/exception/catalog.h 100.00% <ø> (ø)
src/include/common/exception/connection.h 100.00% <ø> (ø)
src/include/common/exception/conversion.h 100.00% <100.00%> (ø)
src/include/common/exception/copy.h 100.00% <ø> (ø)
src/include/common/exception/exception.h 100.00% <ø> (ø)
src/include/common/exception/internal.h 100.00% <ø> (ø)
src/include/common/exception/interrupt.h 100.00% <ø> (ø)
src/include/common/exception/message.h 60.00% <ø> (ø)
... and 6 more

... and 9 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Riolku
Copy link
Contributor Author

Riolku commented Nov 13, 2023

After some thought, the best solution is probably to link the python library against libkuzu.so

@@ -13,9 +13,6 @@
#define KUZU_HELPER_DEPRECATED __attribute__((__deprecated__))
#endif

#ifdef KUZU_STATIC_DEFINE
#define KUZU_API
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing this is, I believe, what's causing the windows build failure. The embedded shell is linking against the static library, but kuzu_shared_EXPORTS is not defined when building the shell, so it's using the import symbols but can't find those symbols in the static library.

And without disabling it for the static library, I would think that gets built with export symbols, which doesn't really seem right.

Otherwise this PR looks good to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense. I'm primarily wondering how best to avoid the Mac warning and the Windows failure.

@Riolku
Copy link
Contributor Author

Riolku commented Nov 13, 2023

Actually I'll just ship this without fixing the warning for now and defer this to post release.

Exception information necessary for properly catching exceptions, seems
to not be exported on Mac unless we export the exception, which seems to
be different from Linux & Windows.

In additional, Mac issues a warning when building the Python module
(which itself builds as a shared library). The issue is that the python
module links with our static library, and the static library does not
export symbols (since it doesn't do anything for static libraries).

However, this mismatch in visibility causes a warning. Technically, we
shouldn't build a shared library with a static library since the static
library isn't position-independent code, but we don't really have other
options unless we embed all of the object files?

We should probably link the python library against `libkuzu.so` and ship
it alongside the python bindings. However, this will be delayed until
after the release.

Ref #2136.
@Riolku Riolku marked this pull request as ready for review November 13, 2023 17:07
@Riolku Riolku merged commit 0782f86 into master Nov 13, 2023
12 checks passed
@Riolku Riolku deleted the apple-symbol-fixes branch November 13, 2023 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants