cre: fix and enable teardown #1617
Conversation
benoit-pierre
force-pushed
the
pr/fix_cre_teardown
branch
from
8f2c218
to
f97e9a6
Compare
benoit-pierre
changed the title
benoit-pierre
force-pushed
the
pr/fix_cre_teardown
branch
2 times, most recently
from
ac53720
to
b6a8cc4
Compare
|
Damn, android ancient toolchain… ;( |
|
So I don't know how to proceed… I updated my meson branch to use the latest android toolchain (
|
You would make us very happy, specially @NiLuJe :) So, please go ahead if you will :)
As far as I understand r18 drops ICS support and r24 drops JB support (based on https://developer.android.com/ndk/downloads/revision_history) We're good with both drops, IMHO. |
|
Yup, I'd be more than okay with that ;p. |
|
+1 on r23
And if it's not too much effort also https://github.com/koreader/koreader-base/blob/e3f0c99aaad218c6b26030fbfc229ea5a1e4e887/toolchain/Makefile which we use here: https://github.com/koreader/virdevenv/blob/9052cee45b019180d787d61b6d56b5428f847590/docker/ubuntu/koandroid/fetch_android_tc.sh#L5 Those Android TC scripts have an annoying tendency to change just about every release. |
|
Is someone working on the Android toolchain update ? Or expecting someone else to do it ? :) |
|
As far as I'm concerned, if I ever get to it, that'll be after the Linux TC updates, and that's been somewhat stalled by amdgpu drivers being a mess on my new build, making doing anything productive with it extremely frustrating. |
|
I'm certainly not expecting anyone to work on that dumb always pulling the rug out from under you nonsense. ;-) Anyway, it can be done in steps; it doesn't need to be all at once. |
|
We can't just remove the As for the NDK update, I'm working on it, current state:
Notes:
Are we okay with dropping support for API < 17, or even < 18? |
|
I'd be mildly interested in logs from the dl related stuff, for science! |
|
Hmm, fun, thanks!
Possibly namespace issues? I can't recall why I kept using RTLD_LOCAL by default instead of RTLD_GLOBAL in there... (Possibly to mimic ffi.load's native behavior, which defaults to local (which also happens to be dlopen's default). Interestingly enough, require defaults to global instead...). (On a related note, ffi.load requests lazy symbol resolution, unlike require). |
in exchange for a modern toolchain? Hell yes! :) |
|
Yeah, fine by me. |
|
What they said ;). |
But there's no inter-dependency, since FreeType is compiled without HarfBuzz support. I've managed to check the build works on KitKat after reflashing an old Motorola smartphone (except for networking features, as WIFI wasn't working).
I should have written |
Oops, yeah; I mixed up mupdf's DT_NEEDED entries with freetype's ;). |
|
Just mentionning this (dunno if you have made a tweak somewhere in your numerous PRs about these |
|
And with this patch: thirdparty/kpvcrlib/CMakeLists.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git i/thirdparty/kpvcrlib/CMakeLists.txt w/thirdparty/kpvcrlib/CMakeLists.txt
index 4b28fe4b..4e806675 100644
--- i/thirdparty/kpvcrlib/CMakeLists.txt
+++ w/thirdparty/kpvcrlib/CMakeLists.txt
@@ -202,8 +202,8 @@ set (CRENGINE_SOURCES
${CRE_DIR}/src/crconcurrent.cpp
)
add_library(crengine SHARED ${CRENGINE_SOURCES})
-# Make sure we'll get C++11 support
-target_compile_features(crengine PRIVATE cxx_constexpr)
+# Make sure we get full `constexpr` support.
+target_compile_features(crengine PRIVATE cxx_std_17)
target_link_libraries(crengine PRIVATE chmlib antiword)
target_link_libraries(crengine PRIVATE ${THIRDPARTY_LIBS})? |
|
^ yep, this makes these warnings disappear on my side. |
|
@poire-z : can you successfully build with this patch? Makefile.defs | 32 +++++---------------------------
thirdparty/djvulibre/CMakeLists.txt | 4 ++++
thirdparty/kpvcrlib/CMakeLists.txt | 4 ++--
thirdparty/libk2pdfopt/CMakeLists.txt | 4 ++++
4 files changed, 15 insertions(+), 29 deletions(-)
diff --git i/Makefile.defs w/Makefile.defs
index f1ac159b..d4d18410 100644
--- i/Makefile.defs
+++ w/Makefile.defs
@@ -518,33 +518,11 @@ ifdef DARWIN_AARCH64_HOST
endif
endif
-# Anything below GCC 6 gets to be forcefully switched to decent standards, because some of our deps require C11 & C++11 support.
-# NOTE: Technically, this also means we require Clang >= 3.2, but that should more or less hold true on our end, because that's truly ancient.
-# Tests heavily inspired from Linux's build system ;).
-CC_IS_CLANG:=$(shell PATH='$(PATH)' $(CC) -v 2>&1 | grep -q "clang version" && echo 1 || echo 0)
-CC_VERSION:=$(shell PATH='$(PATH)' printf "%02d%02d%02d" `echo __GNUC__ | $(CC) -E -x c - | tail -n 1` `echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1` `echo __GNUC_PATCHLEVEL__ | $(CC) -E -x c - | tail -n 1`)
-# Detect Clang's SA, too...
-ifeq "$(CC_IS_CLANG)" "0"
- ifeq "$(lastword $(subst /, ,$(CC)))" "ccc-analyzer"
- CC_IS_CLANG:=1
- endif
-endif
-ifeq "$(CC_IS_CLANG)" "0"
- # NOTE: GCC 6.1.0 switched to gnu11 & gnu++14, so only tweak older ones.
- # c.f., https://stackoverflow.com/q/14737104 for a nice recap.
- ifeq "$(shell expr $(CC_VERSION) \< 060100)" "1"
- CSTD_FLAGS:=-std=gnu11
- CXXSTD_FLAGS:=-std=gnu++11
- endif
-else
- # NOTE: Enforce the current default everywhere, otherwise XCode does stupid things on Darwin.
- # c.f., https://clang.llvm.org/docs/CommandGuide/clang.html#language-selection-and-mode-options
- # & https://github.com/llvm/llvm-project/blob/1c4b5a8dfed853ca8cbee98f274ff0a173186586/clang/lib/Frontend/CompilerInvocation.cpp#L2136-L2164
- # FWIW, the C++ move to gnu++14 by default dates back to Clang 6:
- # c.f., https://github.com/llvm-mirror/clang/commit/466d8da5f89b1a780f735c86f414fa69ce63221b
- CSTD_FLAGS:=-std=gnu11
- CXXSTD_FLAGS:=-std=gnu++14
-endif
+# Some of our deps require C11 & C++17 support.
+# NOTE: Technically, this also means we require GCC >= 8.0 (2018) or Clang >= 5.0.0 (2017),
+getstd = $(or $(shell $1 -x $2 -E -dM /dev/null | sed -ne 's/#define $3 \([0-9]\+\)L$$/\1/p'),0)
+CSTD_FLAGS := $(intcmp $(call getstd,$(CC),c,__STDC_VERSION__),201100,-std=gnu11)
+CXXSTD_FLAGS := $(intcmp $(call getstd,$(CXX),c++,__cplusplus),201700,-std=gnu++17)
HOSTCFLAGS:=$(HOST_ARCH) $(BASE_CFLAGS) $(QFLAGS)
diff --git i/thirdparty/djvulibre/CMakeLists.txt w/thirdparty/djvulibre/CMakeLists.txt
index bfef6c12..edb3d960 100644
--- i/thirdparty/djvulibre/CMakeLists.txt
+++ w/thirdparty/djvulibre/CMakeLists.txt
@@ -19,6 +19,10 @@ ep_get_source_dir(SOURCE_DIR)
# fix build error due to -Werror under Fedora 26 (and potentially other systems)
set(CFLAGS "${CFLAGS} -Wno-error")
+# Fix build error when compiling with -std=gnu++17: ISO
+# C++17 does not allow 'register' storage class specifier.
+set(CXXFLAGS "${CXXFLAGS} -Wno-error=register")
+
set(CFG_ENV_VAR "CC=\"${CC}\" CXX=\"${CXX}\" CFLAGS=\"${CFLAGS}\" CXXFLAGS=\"${CXXFLAGS}\" LDFLAGS=\"${LDFLAGS}\"")
set(CFG_OPTS "-q --disable-desktopfiles --disable-static --enable-shared --disable-xmltools --disable-largefile --without-jpeg --without-tiff -host=\"${CHOST}\"")
set(CFG_CMD1 sh -c "${CFG_ENV_VAR} ${SOURCE_DIR}/configure ${CFG_OPTS}")
diff --git i/thirdparty/kpvcrlib/CMakeLists.txt w/thirdparty/kpvcrlib/CMakeLists.txt
index af79afd3..de7a4357 100644
--- i/thirdparty/kpvcrlib/CMakeLists.txt
+++ w/thirdparty/kpvcrlib/CMakeLists.txt
@@ -201,8 +201,8 @@ set (CRENGINE_SOURCES
${CRE_DIR}/src/crconcurrent.cpp
)
add_library(crengine SHARED ${CRENGINE_SOURCES})
-# Make sure we'll get C++11 support
-target_compile_features(crengine PRIVATE cxx_constexpr)
+# Make sure we get full `constexpr` support.
+target_compile_features(crengine PRIVATE cxx_std_17)
target_link_libraries(crengine PRIVATE chmlib antiword)
target_link_libraries(crengine PRIVATE ${THIRDPARTY_LIBS})
diff --git i/thirdparty/libk2pdfopt/CMakeLists.txt w/thirdparty/libk2pdfopt/CMakeLists.txt
index 21df1b5b..dda89b4c 100644
--- i/thirdparty/libk2pdfopt/CMakeLists.txt
+++ w/thirdparty/libk2pdfopt/CMakeLists.txt
@@ -25,6 +25,10 @@ if ($ENV{DARWIN})
set(CFLAGS "${CFLAGS} -Wno-error=implicit-function-declaration")
endif()
+# Fix build error when compiling with -std=gnu++17: ISO
+# C++17 does not allow 'register' storage class specifier.
+set(CXXFLAGS "${CXXFLAGS} -Wno-error=register")
+
ep_get_source_dir(SOURCE_DIR)
set(BUILD_CMD sh -c "${KO_MAKE_RECURSIVE} -j${PARALLEL_JOBS} BUILDMODE=shared HOST=${HOST} CC=\"${CC}\" CFLAGS=\"${CFLAGS} -O3\"") |
|
The build went fine, with gcc-12 x64 on Debian12, and with debian10's arm-linux-gnueabihf-gcc-8 on this same debian12 machine. Not sure why that :/ |
|
Non-prehistoric distro TCs will target much more recent glibc versions than
what we need.
(Note that there's no direct correlation with the gcc version for C, it
mostly has to do with the glibc used by the distro. For C++, we ship the
build TC's STL to avoid a similar hassle).
…On Sun, Jun 25, 2023, 23:57 poire-z ***@***.***> wrote:
The build went fine, with gcc-12 x64 on Debian12, and with debian10's
arm-linux-gnueabihf-gcc-8 on this same debian12 machine.
I just built libcrengine.so libkoreader-cre.so libdjvulibre.so.21
libk2pdfopt.so.2 liblept.so.5 libtesseract.so.3 (too hot today to build the
whole stuff).
Copying them on my Kobo, I could open an EPUB, but not a PDF and neither a
DJVU:
06/25/23-23:46:50 INFO opening file blah.pdf
ffi.load (warning): /lib/libm.so.6: version `GLIBC_2.27' not found (required by libs/liblept.so.5)
06/25/23-23:46:51 WARN cannot open document wblah.pdf ./setupkoenv.lua:30: Not able to load dynamic library: libs/liblept.so.5
06/25/23-23:47:01 WARN cannot open document djvu3spec.djvu error loading module 'libs/libkoreader-djvu' from file './libs/libkoreader-djvu.so':
/lib/libm.so.6: version `GLIBC_2.27' not found (required by /mnt/onboard/.adds/koreader/./libs/libdjvulibre.so.21)
06/25/23-23:47:03 INFO opening file djvu3spec.djvu
06/25/23-23:47:03 WARN cannot open document djvu3spec.djvu error loading module 'libs/libkoreader-djvu' from file './libs/libkoreader-djvu.so':
/lib/libm.so.6: version `GLIBC_2.27' not found (required by /mnt/onboard/.adds/koreader/./libs/libdjvulibre.so.21)
Not sure why that :/
I think (I may be wrong) that one of the reason I had to stay with tha old
gcc-8 and stuff from debian 10 was maybe to get something that works on
that old Kobo system.
—
Reply to this email directly, view it on GitHub
<#1617 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3KZXOHOV4QOPUQ2RERD3XNCX5FANCNFSM6AAAAAAZCPXOL4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
That's the whole point of the koxtoolchain TCs: recent GCC versions
targeting ancient glibc versions/kernels ;).
…On Mon, Jun 26, 2023, 00:56 NiLuJe ***@***.***> wrote:
Non-prehistoric distro TCs will target much more recent glibc versions
than what we need.
(Note that there's no direct correlation with the gcc version for C, it
mostly has to do with the glibc used by the distro. For C++, we ship the
build TC's STL to avoid a similar hassle).
On Sun, Jun 25, 2023, 23:57 poire-z ***@***.***> wrote:
> The build went fine, with gcc-12 x64 on Debian12, and with debian10's
> arm-linux-gnueabihf-gcc-8 on this same debian12 machine.
> I just built libcrengine.so libkoreader-cre.so libdjvulibre.so.21
> libk2pdfopt.so.2 liblept.so.5 libtesseract.so.3 (too hot today to build the
> whole stuff).
> Copying them on my Kobo, I could open an EPUB, but not a PDF and neither
> a DJVU:
>
> 06/25/23-23:46:50 INFO opening file blah.pdf
> ffi.load (warning): /lib/libm.so.6: version `GLIBC_2.27' not found (required by libs/liblept.so.5)
> 06/25/23-23:46:51 WARN cannot open document wblah.pdf ./setupkoenv.lua:30: Not able to load dynamic library: libs/liblept.so.5
> 06/25/23-23:47:01 WARN cannot open document djvu3spec.djvu error loading module 'libs/libkoreader-djvu' from file './libs/libkoreader-djvu.so':
> /lib/libm.so.6: version `GLIBC_2.27' not found (required by /mnt/onboard/.adds/koreader/./libs/libdjvulibre.so.21)
> 06/25/23-23:47:03 INFO opening file djvu3spec.djvu
> 06/25/23-23:47:03 WARN cannot open document djvu3spec.djvu error loading module 'libs/libkoreader-djvu' from file './libs/libkoreader-djvu.so':
> /lib/libm.so.6: version `GLIBC_2.27' not found (required by /mnt/onboard/.adds/koreader/./libs/libdjvulibre.so.21)
>
> Not sure why that :/
> I think (I may be wrong) that one of the reason I had to stay with tha
> old gcc-8 and stuff from debian 10 was maybe to get something that works on
> that old Kobo system.
>
> —
> Reply to this email directly, view it on GitHub
> <#1617 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAA3KZXOHOV4QOPUQ2RERD3XNCX5FANCNFSM6AAAAAAZCPXOL4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Well, dunno them why libcrengine is ok, doesn't it need/use glibc ? Fwiw, my "keep" of arm stuff from debian 10 is just an extraction of these packages in a dedicated directory (exporting some of them via LD_LIBRARY_PATH C_INCLUDE_PATH PATH when I do an ARM build): |
|
It depends on exactly which symbols the binary pulls, glibc symbols are versioned, so new features for existing symbols just create a new variant with a higher version (e.g., security features). |
|
Should we merge this one ? (Still marked as Draft) |
|
I want to fix the issue with the android build on gitlab first. |
|
And to rebase to make sure the (base) CI is passing. |
benoit-pierre
force-pushed
the
pr/fix_cre_teardown
branch
from
b6a8cc4
to
f0251c4
Compare
There was a problem hiding this comment.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @benoit-pierre)
Depends on koreader/crengine#520.
This change is