Menu
▾
▴
#13 "libCLI" CMake target won't cross-compile in OpenWRT build environment
This one is wierd,
when cross-compiling for an arm v7 in the OpenWRT build environment, all the CMake targets as set in the CMakeLists.txt seems to compile, except "libCLI", for some reason it fails,
but when i changed the format used in CMakeLists.txt for this target to look more like SGUtils(less like a library include "-IlibCLI"), it compiles successfully, maybe the added -lcrypt confuses the environment so it thinks this is a system library?
anyway, it compiles now and results in an arm v7 .ipk package, and now i have a router with fgms working flawlessly :)
Haven't uploaded the package to OpenWRT project yet, let me know if you need the build environment package Makefile to test.
--- a/CMakeLists.txt 2018-09-19 06:24:38.313362388 +0300
+++ b/CMakeLists.txt 2018-09-19 06:51:56.489319447 +0300
@@ -192,13 +192,14 @@
#### add_subdirectory( src/libcli )
# Project [libcli] [Static Library] [noinst_LIBRARIES], with 1 sources. 1 hdrs.
-set( libcli_SRCS
+set( name LibCLI )
+set( ${name}_SRCS
src/libcli/debug.cxx
src/libcli/filter.cxx
src/libcli/cli_client.cxx
src/libcli/libcli.cxx
)
-set( libcli_HDRS
+set( ${name}_HDRS
src/libcli/common.hxx
src/libcli/command.hxx
src/libcli/debug.hxx
@@ -206,14 +207,12 @@
src/libcli/cli_client.hxx
src/libcli/libcli.hxx
)
-if (WIN32)
- list(APPEND libcli_SRCS src/libcli/crypt-win.c)
-endif ()
-add_library( LibCLI ${LIB_TYPE} ${libcli_SRCS} ${libcli_HDRS} )
+
+add_library( ${name} ${LIB_TYPE} ${${name}_SRCS} ${${name}_HDRS} )
if(WIN32)
list(APPEND add_LIBS LibCLI)
else(WIN32)
- list(APPEND add_LIBS -lLibCLI -lcrypt)
+ list(APPEND add_LIBS ${name} -lcrypt)
endif(WIN32)
#### add_subdirectory( src/libmsc ) Windows Only
@@ -298,4 +297,4 @@
message(STATUS "*** Will read config from ${SYSCONFDIR}")
install(TARGETS ${EXE_NAME} DESTINATION ${SBINDIR})
endif(WIN32)
-# eof - CMakeLists.txt
\ No newline at end of file
+# eof - CMakeLists.txt
Sorry to hear you are having
OpenWRTcompile problems...I have no problem cross-compiling the
fgms-srcin a raspberrypi machine, armv7l, running Raspbian GNU/Linux 8.0 (jessie)... and of course there are no other unix/linux reports of a compile failure in other distributions...To me there seems a problem in each of the
list(APPEND add_LIBS <proj>)lines, in that each of the projects aprefixedwith-l<proj>, if NOT WIN32... in all other cmake projects I work with this is not required... I think this was mistakenly added, thinking it was required...And maybe the
line:216: list(APPEND add_LIBS -lLibCLI -lcrypt), where 2 lib projects have been added, using this prefix, in UNIX, is causing the problem... as you suggest...And that seems further indicated in the
patchyou showed. While I have nothing wrong with most of the patch... usingset(name LibCLI)- I use that most of the time - you seem to have maybe accidently removed the line:210, which is in anif (WIN32)block, and this would cause a windows build to fail...But this does not seem to fully explain the problem you are having, specifically in
OpenWRT, although it obviously fixes the compile, so with your help would like to explore a more cross-platform solution...Accordingly, I hope you can apply the following patch, and re-compile...
Notice I have just removed the
-lprefix, for all ports, and have added thecryptlibrary separately, if NOT WIN32...This compiles fine in my RPI machine, and Ubuntu, the only two tried so far... but expect it to work in all...
If this works for you, and others giving it a try, and reporting, I would feel comfortable in pushing such a cmake change... thanks...
Have pushed that change, plus a small WIN32 only change, to the
cmake.1branch. This branch is based onmaster...Would appreciate you, and others testing and reporting... thanks...
OT: A little off topic, but related...
When I look at the repo branches... maybe I missed, or have forgotten! which branch is current. In addition to the default
master, there is0.13.2which is the closest to the currentmasterexcept for a comment update, and then there is the0.13.3branch, which seems to contain an important tracker change...Then there is the
1.0.0branch, which currently fails in a Windows compile...Now it seems most mp servers are running
0.13.2, which I suppose ismaster...mpserver01 and 15 are running
0.13.3... should this now be merged intomaster... has it been tested enough...And Hamza, assume you are talking about
master, which is version0.13.2, since I think that is what we release as the latest stable, default, branch?But look forward to feedback...
Sorry for the late reply, but i wanted to find the time to setup an amd64 environment, to see if it's something to do with the architecture, cross-compiler or OpenWRT's environment CMake 3.9.3,
Initially i want to say the patch does work, but i found out it was unnessesary on some systems,
I've tested cross-compiling for both armv7 and amd64 targets on two native x64 systems, with or without the patch, turns out it hasn't to do with the target architecture, but for two different systems with same identical cross-compiler configs, one was able to pass the compile without the patch and the other has not, meaning the patch will guarantee it would compile for both, I really don't know the reason for this.
I have compared the build folder for both of these systems to figure out where the fault is, and i did not see any additional errors in the CMake error and output file, just that the faulty build didn't create a rule to build libCLI without the patch.
For the Makefile, this is how i have it setup, included you'll find the Makefile, patch and init files necessary to cross-compile for an OpenWRT build:
https://drive.google.com/open?id=1IFohS96ZHZL2IUdtAFBjPULjTzm1De5l
This is what the console output looks like for the faulty build vs the working one, both without patches:
https://www.diffchecker.com/NOUWvIPE
Thank you for the fix Geoff,
i fetch 0.13.2 (see the Makefile), OpenWRT guidelines state that we have to pull explicitly and version our Makefiles, regarding the status of fgms, I really only deployed this locally and haven't tested extensively the differences between the branches...
Thanks for the feedback Hamza... Yes, I can see your
Makefileuses commit 508376d79, which is indeedmaster, default branch,0.13.2, so no problem there...And yes I can see the
LibCLIsomehow failed, and agree we do not exactly know the problem, since it currently works in most distros, but think mycmake.1branch is better cmake wording anyway, and clears up a WIN32 only block... I have now tested it in Windows, and 2 Linux, so this seems to work for all... You will note I renamed the local static libraryCLILib, so becomeslibCLIlib.ain unix, just in case some tool had a problem withlibLibCLI, but can't see why...It is not for you, as a user, to test differences between branches, but always thankful if you do... Look forward to feedback from @ofschroeder and/or @quofei on that...
cmake is somewhat funny regarding names. Sometimes it insists on BIGLETTER names, sometimes not. And now it seems it even depends on the cmake version. We'll see...
I've included Geoffs patch in 0.13.4 (slightly adapted to avoid unnecessary variables in CMakeLists.txt). Please test...
I don't see version 0.13.4 on git. Neither master, branch or tag is 0.13.4. Where can I find version 0.13.4?
Sorry for not replying sooner,
I'm able to compile the 'fgms' package in OpenWRT's environment with no patches applied, Thank you for all your work everybody!
Hopefully this package gets accepted to OpenWRT, then it will be offered to all those who use OpenWRT forks downstream, like Entware-3X etc...
An easy way to deploy fgms on your router :)
Last edit: Hamza Alloush 2018-11-02