Summary: | dev-lua/luasec-1.0.2-r1: Error loading shared library socket/core.so on musl systems (DT_SONAME contains relative path with '/') | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Wolfgang Müller <wolf+gentoo> |
Component: | Current packages | Assignee: | Azamat H. Hackimov <azamat.hackimov> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | conikost, jstein, musl, opal, proxy-maint, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 430702 |
Description
Wolfgang Müller
2022-02-27 10:30:51 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.." (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? (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. 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 |