cross compile error

[predators46]

xrdp version

0.9.25.1

Detailed xrdp version, build options

Operating system & version

OpenWrt aarch64

Installation method

other

Which backend do you use?

No response

What desktop environment do you use?

OpenWrt

Environment xrdp running on

No response

What's your client?

No response

Area(s) with issue?

Other

Steps to reproduce

CONFIGURE_ARGS += \
	--prefix=/usr \
	--disable-pam \
	--enable-tjpeg

✔️ Expected Behavior

No response

❌ Actual Behavior

2024-05-06T23:00:39.0737006Z verify_user.c:221:9: error: implicit declaration of function 'putpwent'; did you mean 'getpwent'? [-Werror=implicit-function-declaration]
2024-05-06T23:00:39.0738444Z 221 | putpwent(spw, fd);
2024-05-06T23:00:39.0738972Z | ^~~~~~~~
2024-05-06T23:00:39.0739399Z | getpwent
2024-05-06T23:00:39.1114725Z cc1: all warnings being treated as errors

Anything else?

No response

[matt335672]

Thanks for this @predators46

putpwent() is an interesting one. It's not in POSIX, and I can't find where it actually comes from.

Regarding your problem, I don't believe the function calling putpwent() is currently used. Can you try this patch against v0.9.25.1? That should let us find any other compile issues at least.

--- a/sesman/verify_user.c
+++ b/sesman/verify_user.c
@@ -42,8 +42,10 @@
 #define SECS_PER_DAY (24L*3600L)
 #endif
 
+#if 0
 static int
 auth_crypt_pwd(const char *pwd, const char *pln, char *crp);
+#endif
 
 static int
 auth_account_disabled(struct spwd *stp);
@@ -184,6 +186,7 @@ auth_check_pwd_chg(const char *user)
     return AUTH_PWD_CHG_OK;
 }
 
+#if 0
 int
 auth_change_pwd(const char *user, const char *newpwd)
 {
@@ -292,6 +295,7 @@ auth_crypt_pwd(const char *pwd, const char *pln, char *crp)
 
     return 0;
 }
+#endif
 
 /**
  *

[predators46]

@matt335672

there is another problem if doing cross compilation I don't find CC_FOR_BUILD in configure. keygen must cross-compile.

#1292

xrdp/keygen/Makefile.am

Line 23 in 33670ae

./xrdp-keygen xrdp $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini; \

[predators46]

Thanks for this @predators46

putpwent() is an interesting one. It's not in POSIX, and I can't find where it actually comes from.

Regarding your problem, I don't believe the function calling putpwent() is currently used. Can you try this patch against v0.9.25.1? That should let us find any other compile issues at least.

--- a/sesman/verify_user.c
+++ b/sesman/verify_user.c
@@ -42,8 +42,10 @@
 #define SECS_PER_DAY (24L*3600L)
 #endif
 
+#if 0
 static int
 auth_crypt_pwd(const char *pwd, const char *pln, char *crp);
+#endif
 
 static int
 auth_account_disabled(struct spwd *stp);
@@ -184,6 +186,7 @@ auth_check_pwd_chg(const char *user)
     return AUTH_PWD_CHG_OK;
 }
 
+#if 0
 int
 auth_change_pwd(const char *user, const char *newpwd)
 {
@@ -292,6 +295,7 @@ auth_crypt_pwd(const char *pwd, const char *pln, char *crp)
 
     return 0;
 }
+#endif
 
 /**
  *

alpine has patches

Upstream: Not applicable but they are doing it wrong
Reason: Upstream is enabling Werror for non-debug builds

diff --git a/configure.ac b/configure.ac
index 8a2d230..7c9fdc2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -156,8 +156,6 @@ AX_TYPE_SOCKLEN_T
 AX_CFLAGS_WARN_ALL
 AX_APPEND_COMPILE_FLAGS([-Wwrite-strings])
 
-AM_COND_IF([LINUX],
-  [AX_APPEND_COMPILE_FLAGS([-Werror])]) # bsd has warnings that have not been fixed yet
 
 AM_COND_IF([XRDP_DEBUG],
   [AX_APPEND_COMPILE_FLAGS([-g -O0])],

[matt335672]

xrdp-keygen is a tricky one.

It's used by make install, but also needs to be available on the target system itself.

I'm wondering if a way round this is to ignore fails if xrdp-keygen during install, but to run it when the xrdp service is started if the file doesn't exist.

Presumably you're having to write a service script for OpenWRT to handle xrdp?

[matt335672]

This patch should let the build run through without an rsakeys.ini being generated:-

--- a/keygen/Makefile.am
+++ b/keygen/Makefile.am
@@ -20,7 +20,7 @@ xrdpsysconfdir = $(sysconfdir)/xrdp
 install-data-hook:
        umask 077 && \
        if [ ! -f $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini ]; then \
-         ./xrdp-keygen xrdp $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini; \
+         ./xrdp-keygen xrdp $(DESTDIR)$(xrdpsysconfdir)/rsakeys.ini || : ; \
        fi && \
        if [ ! -f $(DESTDIR)$(xrdpsysconfdir)/cert.pem ]; then \
          $(OPENSSL) req -x509 -newkey rsa:2048 -sha256 -nodes \

[predators46]

@matt335672

thank you I understand now

[matt335672]

Let me know how you get on - this definitely falls into the 'interesting' category of PRs!

We might want to add a way to disable the compile-time generation of rsakeys.ini and the TLS files. These are only useful if you're running make install on the local machine. They're pointless if you're building a package as they need to be regenerated for each machine that the package is installed on.

[predators46]

Let me know how you get on - this definitely falls into the 'interesting' category of PRs!

We might want to add a way to disable the compile-time generation of rsakeys.ini and the TLS files. These are only useful if you're running make install on the local machine. They're pointless if you're building a package as they need to be regenerated for each machine that the package is installed on.

in openwrt to cross compile you have to build the host first.

i can cross compile but xrdp needs openssl host while building xrdp as host but OpenWrt doesn't add host package in openssl

so for the time being, I created rsakeys.ini on my local machine.

is there a way to disable openssl in xrdp while building? i can cross compile if xrdp doesn't need openssl

currently I managed to build xrdp without rsakeys.ini when building xrdp.

[matt335672]

I think that openssl is only used on make install. Is that what you are seeing?

[predators46]

I think that openssl is only used on make install. Is that what you are seeing?

I see openssl is required when building xrdp

[matt335672]

Yes - the libraries are. You'll need those in your build environment.

We've looked into using other ssl libraries when all the fuss started over openssl maintenance, but in the end we didn't implement any changes apart from the migration to the EVP interface for OpenSSL 3.0.