Bug 834276 – dev-lua/luasec-1.0.2-r1: Error loading shared library socket/core.so on musl systems (DT_SONAME contains relative path with '/')

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description Wolfgang Müller 2022-02-27 10:30:51 UTC]

It seems that on musl systems luasec SSL is currently broken. This is easiest to reproduce by trying to import the "ssl" module:

	LuaJIT 2.0.5 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/
	JIT: ON CMOV SSE2 SSE3 SSE4.1 AMD fold cse dce fwd dse narrow loop abc sink fuse
	> require "ssl"
	error loading module 'ssl.core' from file '/usr/lib/lua/5.1/ssl.so':
		Error loading shared library socket/core.so: No such file or directory (needed by /usr/lib/lua/5.1/ssl.so)
	stack traceback:
		[C]: at 0x7f4ab41fb558
		[C]: in function 'require'
		/usr/share/lua/5.1/ssl.lua:8: in main chunk
		[C]: in function 'require'
		stdin:1: in main chunk
		[C]: at 0x564833570f58

I have tracked this down to the recent change that unbundles luasocket. The ebuild sets -soname to "socket/core.so" in https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lua/luasec/luasec-1.0.2-r1.ebuild#n57

It is my understanding that musl does not support DT_SONAME searches like this, and therefore fails loading the library. A local fix for me is to patchelf ssl.so and replacing "socket/core.so" with either the full path or a bare "core.so".

[Comment 1 Sam James 2022-06-17 23:37:53 UTC]

Spoke with dalias about this in #musl. The gist is that soname with a / in it is suspicious and is almost certainly relying on documented behaviour.

"like even if we add soname processing i'd be wary of having it take over references to a relative pathname.."

[Comment 2 Conrad Kostecki 2022-08-01 19:29:43 UTC]

(In reply to Sam James from comment #1)
> Spoke with dalias about this in #musl. The gist is that soname with a / in
> it is suspicious and is almost certainly relying on documented behaviour.
> 
> "like even if we add soname processing i'd be wary of having it take over
> references to a relative pathname.."

Any suggestions, what we could alternative do here?

[Comment 3 Sam James 2022-08-31 00:11:14 UTC]

(In reply to Conrad Kostecki from comment #2)
> (In reply to Sam James from comment #1)
> > Spoke with dalias about this in #musl. The gist is that soname with a / in
> > it is suspicious and is almost certainly relying on documented behaviour.
> > 
> > "like even if we add soname processing i'd be wary of having it take over
> > references to a relative pathname.."
> 
> Any suggestions, what we could alternative do here?

I think it needs to be just "core.so", but we'd need to test if that works.

[Comment 4 opal hart 2023-10-26 11:50:48 UTC]

What was the reason to add these specificities to the LDFLAGS and such anyway? Alpine's APKBUILD for main/luasec=1.3.2 doesn't even do any of this.

My naïve guess would be that it's for crossdev or such, but if it doesn't work, shouldn't the simpler "works for most users on musl" solution be fine? I guess ::musl could handle fixing this package if all the extra junk is deemed necessary on glibc systems.

--- gentoo/dev-lua/luasec/luasec-1.3.2.ebuild   2023-09-04 06:32:12.920198075 -0000
+++ wowaname/dev-lua/luasec/luasec-1.3.2.ebuild 2023-10-26 11:19:14.480666400 -0000
@@ -52,11 +52,9 @@
                "CC=$(tc-getCC)"
                "CCLD=$(tc-getCC)"
                "INC_PATH=-I$(lua_get_include_dir)"
-               "LIB_PATH=-L$(lua_get_cmod_dir)/socket"
-               "LIBS=$($(tc-getPKG_CONFIG) --libs openssl) $(lua_get_cmod_dir)/socket/core.so"
-               "MYLDFLAGS=-Wl,-rpath,$(lua_get_cmod_dir)/socket -Wl,-soname=socket/core.so"
-               "EXTRA="
-               "DEFS="
+               "LIB_PATH=$(lua_get_CFLAGS)"
+               "MYCFLAGS=${CFLAGS}"
+               "MYLDFLAGS=${LDFLAGS}"
        )

        emake "${myemakeargs[@]}" linux