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

libonxx + 1.15.0 migration #105

Closed
wants to merge 30 commits into from
Closed

Conversation

hmaarrfk
Copy link
Contributor

@hmaarrfk hmaarrfk commented Nov 5, 2023

Note that the windows library is still static

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

  • The top level meta key oututs is unexpected
  • The recipe must have some tests.

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

  • The outputs section contained an unexpected subsection name. tests is not a valid subsection name.

For recipe:

  • It looks like the 'onnx' output doesn't have any tests.

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@hmaarrfk hmaarrfk changed the title Libonxx ibonxx + 1.15.0 migration Nov 5, 2023
@hmaarrfk hmaarrfk changed the title ibonxx + 1.15.0 migration libonxx + 1.15.0 migration Nov 5, 2023
@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 6, 2023

I don't really understand what I am doing wrong on windows..... help appreciated.

@hmaarrfk hmaarrfk marked this pull request as ready for review November 6, 2023 03:26
@traversaro
Copy link

I don't really understand what I am doing wrong on windows..... help appreciated.

ONNX_API is used as export macro for both onnx_proto and onnx libraries. So, onnx_proto symbols get marked with __declspec(dllexport) also in onnx's compilation units, and so the linker complains that they are not found even if they are present in the linked import librar onnx_proto.lib .

A quick fix (I just tested locally, it seems to work) is to change the export macro for onnx-proto : traversaro/onnx@e7719fd . It is not ideal as non-CMake downstream users needs to manually set ONNX_PROTO_API , but better than not working. A better fix is to define ONNX_PROTO_API in an header, but unfortunately protobuf does not support including an arbitrary header inclusion in the generated headers, so downstream projects typically do that via external scripts, see protocolbuffers/protobuf#4198 for more details. If it is not a problem to expose all symbols of onnx_proto , an alternative simple solution is to set the WINDOWS_EXPORT_ALL_SYMBOLS CMake definition just for onnx_proto, and avoid to use any export pre-processor macro.

endif()
endif()
add_onnx_global_defines(onnx_proto)
@@ -528,7 +531,7 @@ target_include_directories(onnx PUBLIC

Choose a reason for hiding this comment

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

If you find protobuf to find_package(Protobuf CONFIG), this should be handled automatically by CMake.

Choose a reason for hiding this comment

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

Anyhow, if this works fine it is ok to use that.

- make # [unix]
host:
- libprotobuf
- libabseil # [win]

Choose a reason for hiding this comment

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

I guess this should be present also on non-Windows platforms, so the correctly run_exports are exported for abseil (as it is a public dependency of libprotobuf).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the linking analysis at the end doesn't make libaseil appear on unix

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i think this is due to the fact that linux uses shared libraries

Choose a reason for hiding this comment

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

I see probably the protobuf headers that transitively include abseil are not used. Given that you are linking with https://github.com/conda-forge/onnx-feedstock/pull/105/files/16d193ff4ab9a19c6e551858659303148bb89e21#diff-f3725a55bf339595bf865fec73bda8ac99f283b0810c205442021f29c06eea9aR13 and not via find_package(Protobuf CONFIG), if those are used probably build will fail?

Choose a reason for hiding this comment

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

For reference, this was the discussion on libprotobuf now requiring linking to libabseil: conda-forge/conda-forge-pinning-feedstock#4075 (comment) .

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 6, 2023

Thanks for the great explination.

Why is compilation not failing for #103 (comment)

recipe/bld_libonnx.bat Outdated Show resolved Hide resolved
@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 6, 2023

i see it is due to the fact that they aren't building shared libraries for windows.

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 6, 2023

I think WINDOWS_EXPORT_ALL_SYMBOLS is probably the best way to go.... but i'm not sure of any unintended effects.

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 6, 2023

maybe we can in CMake inject something into the header.

@traversaro
Copy link

maybe we can in CMake inject something into the header.

Just to understand, what is the goal now? Building as shared in Windows? In theory the patch in #105 (comment) should work fine, are you afraid the problem will create on non-cmake users of libonnx ?

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 7, 2023

are you afraid the problem will create on non-cmake users of libonnx

yes.

I would ideally also like to upstream whatever patch i make since these build patches are pretty hard to maintain.

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Nov 7, 2023

It seems onnx worked around this issue by creating an other header file.

Maybe I have to move files around to create this shared library

https://github.com/onnx/onnx/blob/main/onnx/onnx_pb.h#L12

@hmaarrfk hmaarrfk mentioned this pull request Mar 9, 2024
@hmaarrfk hmaarrfk closed this Nov 22, 2024
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