-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Fix cross-compilation against Poco pre-built #2599
Conversation
Avoid hard-coded absolute paths to zlib by using the imported target ZLIB::ZLIB set by FindZLIB.cmake instead of ZLIB_LIBRARIES. Change-Id: Ia58fc0c37d40e84b04dc72cee94a77107d6c0f52 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Avoid hard-coded absolute paths to pcre by using the PCRE_NAMES variable instead of PCRE_LIBRARIES provided by FindPCRE module. Change-Id: I478dd393045ed3d108b7e9fcdda1d65d92c3df1a Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Hi @Bjoe, you seem to have some experience on Poco's build system. Do you have some time for a quick look into this PR? Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the change for ZLIB to importet targets is very good.
For PCRE I'm not that happy. What you did here is similar to the hack we did in OpenEmbedded.
Foundation/CMakeLists.txt
Outdated
@@ -97,7 +97,10 @@ set_target_properties(Foundation | |||
DEFINE_SYMBOL Foundation_EXPORTS | |||
) | |||
|
|||
target_link_libraries(Foundation PUBLIC ${PCRE_LIBRARIES} ${ZLIB_LIBRARIES}) | |||
if (POCO_UNBUNDLED) | |||
target_link_libraries(Foundation PUBLIC ${PCRE_NAMES} ZLIB::ZLIB) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using PCRE_NAMES
here seems very hacky. It's basically equivalent to just putting pcre
.
I would prefer to change the FindPCRE.cmake
module to provide an exported target that can be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @bachp,
Thanks for your comments !
I'm also not really happy with my solution for pcre but I didn't find a simpler solution for this. My first idea was also to modify FindPCRE.cmake
to provide an exported target, but this not enough:
The FindPCRE.cmake
is available during the compilation, but it is not part of the installed files. This end up with pre-build looking for an exported target that can not be resolved. This can be solved by installing FindPCRE.cmake
. The problem is not here with zlib
because cmake have already a FindZLIB.cmake
module.
If installing a module to find PCRE as part of Poco is not an issue, I would be happy to push the required changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think installing the modified FindPCRE.cmake
along Poco would be an acceptable solution. In my opinion you can continue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, thanks @lmayencourt . I fail to see this issue when I refactor/cleaup all XXX_LIBRARIES places to use the modern art of cmake.
I agree with @bachp , because what with the "include path" for PCRE ?
Let me cleanup the FindPCRE.cmake and install when POCO_UNBUNDLED is true.
I would like to use your merge request, is this ok for you @lmayencourt?
Finally, I found another place where ZLIB_LIBRARIES
is used: PDF/CMakeList.txt:129 ....
I can also fix this.
Sorry for the late answer.... |
@lmayencourt I create a pull request in your repo with my changes. see https://github.com/lmayencourt/poco/pull/1 Can you test please. Thanks |
@lmayencourt I have added to the cmake build to install FindPCRE see https://github.com/lmayencourt/poco/pull/1 . It will be installed in CMAKE_INSTALL_PREFIX/lib/cmake/Poco/FindPCRE.cmake .... I'm not sure if this is a "good place". Please test. Btw. I find that "expat" and "sqlite" has the same issue/problem. I will fix this also if this solution works fine. |
…ue in cmake build
Cleanup FindPCRE
@lmayencourt Thanks for merging my fixes .... Again, at the moment I install |
Btw. we should also merge this to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
Foundation/CMakeLists.txt
Outdated
@@ -40,7 +40,7 @@ if (POCO_UNBUNDLED) | |||
src/pcre_ucd.c | |||
src/pcre_tables.c | |||
) | |||
|
|||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unneeded whitespace?
* Use ZLIB and PCRE imported target to improve portability * Set EXPAT and SQLite3 library for XML and SQL if POCO_UNBUNDLED is true in cmake build
* Use ZLIB and PCRE imported target to improve portability * Set EXPAT and SQLite3 library for XML and SQL if POCO_UNBUNDLED is true in cmake build
This two patches remove hard-coded absolute paths to zlib and pcre when building with
POCO_UNBUNDLED
inside the exportedPocoFoundationTarget.cmake
.This enables cross-compiling against pre-built binaries of poco provided inside a sysroot.
The
ZLIB::ZLIB
imported target set byFindZLIB.cmake
is used instead ofZLIB_LIBRARIES
. The installed target will use thefindZLIB cmake
module to define the correct path of the zlib library.Use the
PCRE_NAMES
variable instead of thePCRE_LIBARIES
provided byFindPCRE.cmake
. This will addpcre
toINTERFACE_LINK_LIBRARIES
and will let the linker find the PCRE library.The current build will generate: (PocoFoundationTargets.cmake)
Which will fails to link, because the path
/usr/lib/aarch64-linux-gnu/libxxx.so
doesn't exist on the host machine.and with this modification: (PocoFoundationTargets.cmake)
Which will link properly.
This was tested on ubuntu 18.04: natively on x86 and cross-compiled for aarch64.