-
Notifications
You must be signed in to change notification settings - Fork 158
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
Can't compile on arch linux #604
Comments
same |
idk seems like it's not compatible with arch's extra/mbedtls 3.4.0-3 package |
File int ext_types; /**< Bit string containing detected and parsed extensions */
int ca_istrue; /**< Optional Basic Constraint extension value: 1 if this certificate belongs to a CA, 0 otherwise. */
int max_pathlen; /**< Optional Basic Constraint extension value: The maximum path length to the root certificate. Path length is 1 higher than RFC 5280 'meaning', so 1+ */
unsigned int key_usage; /**< Optional key usage extension value: See the values in x509.h */
mbedtls_x509_sequence ext_key_usage; /**< Optional list of extended key usage OIDs. */ Rach linuhh: int MBEDTLS_PRIVATE(ext_types); /**< Bit string containing detected and parsed extensions */
int MBEDTLS_PRIVATE(ca_istrue); /**< Optional Basic Constraint extension value: 1 if this certificate belongs to a CA, 0 otherwise. */
int MBEDTLS_PRIVATE(max_pathlen); /**< Optional Basic Constraint extension value: The maximum path length to the root certificate. Path length is 1 higher than RFC 5280 'meaning', so 1+ */
unsigned int MBEDTLS_PRIVATE(key_usage); /**< Optional key usage extension value: See the values in x509.h */
mbedtls_x509_sequence ext_key_usage; /**< Optional list of extended key usage OIDs. */
unsigned char MBEDTLS_PRIVATE(ns_cert_type); /**< Optional Netscape certificate type extension value: See the values in x509.h */ See? |
Oh, I see |
Conclusion: hashlink fix your thing that breaks encapsulation |
@Gigas002 u sure turning on/off didn't work? |
😜 |
Аниме на аве мать в канаве |
Maintainer of the Just an fyi, I won't be removing And if I do remove it from the list:
And assuming I somehow address that, doesn't change the fact that the included mbedtls isn't built under linux, leading to it still being broken. I'm sure there is some fiddling to be had here, in particular convincing hashlink to build a version of its mbedtls under linux, but I'm not about to fight with patches to make that work as is.
|
The simplest solution for the AUR package would be to depend on the mbedtls2 package instead and fiddle with the compiler flags: diff --git a/Makefile b/Makefile
index 52c46e3..1763c8a 100644
--- a/Makefile
+++ b/Makefile
@@ -110,9 +110,11 @@ LIB += ${HL_DEBUG}
else
# Linux
-CFLAGS += -m$(MARCH) -fPIC -pthread -fno-omit-frame-pointer
+CFLAGS += -m$(MARCH) -fPIC -pthread -fno-omit-frame-pointer -I /usr/include/mbedtls2
LFLAGS += -lm -Wl,-rpath,.:'$$ORIGIN':$(INSTALL_LIB_DIR) -Wl,--export-dynamic -Wl,--no-undefined
+LIBFLAGS+=-L/usr/lib/mbedtls2
+
ifeq ($(MARCH),32)
CFLAGS += -I /usr/include/i386-linux-gnu
LIBFLAGS += -L/opt/libjpeg-turbo/lib |
Good news to all, Makefile has been patched, thanks @Apprentice-Alchemist https://aur.archlinux.org/packages/hashlink |
Hey, just a quick comment, that the AUR patch above does not work for CMake scenario. I use CMake to build Hashlink across platforms. The reason is CMake depends on its find_package statement for building, and the system-wise Cmake uses configuration file from package mbedtls v3.4.1, which sets /usr/lib/cmake/MbedTLS/MbedTLSConfigVersion.cmake to 3.4.1. I won't ask for an upgrade to mbedtls 3.x because I know some systems like ubuntu is still on 2.28.x. I work-arounded it by disabling SSL (build command: cmake .. -DWITH_SSL=off). It works for me because I don't use SSL at all, but not a true fix. So my question is: is it possible we just always use the checked-in source code under include/mbedtls/ folder for all platforms? This can completely remove the external dependency, which benefits when we compile hashlink that portable across Linux builds (a typical scenario is to build a Hashlink for Steam runtime), which may be a good idea. Or, is there any reason that we prefer system provided over checked-in dependencies?
|
Using the checked in deps would indeed fix this issue, but I would only recommend that if the checked in version of mbedtls was up to date (at the moment its 5 years out of date). There is a PR to update it, but it hasn't been merged yet: #594 |
Thanks. Yes, it makes sense we should update the code first. Will wait for the PR. |
The text was updated successfully, but these errors were encountered: