Issues building on Ubuntu-24.04 - build-without-openssl.bash: error: compiled binary is not static

[uli-heller]

I'm trying to build gocryptfs on Ubuntu-22.04 and on 24.04. I realized that "ldd" seems to operate quite differently for both of these. This leads to a failure within "build-without-openssl.bash". I don't think there is a good solution for this!

Ubuntu-22.04

Statically linked

$ ldd ./gocryptfs
	not a dynamic executable
$ echo $?
1

Dynamically linked

$ ldd /usr/bin/ls
	linux-vdso.so.1 (0x00007ffc8cbfd000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f8fe540b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8fe51e2000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f8fe514b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8fe546c000)
$ echo $?
0

Ubuntu-24.04

Statically linked

$ ldd ./gocryptfs
	statically linked
$ echo $?
0

Dynamically linked

$ ldd /usr/bin/ls
	linux-vdso.so.1 (0x00007ffed6fe0000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f187f668000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f187f456000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f187f3bc000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f187f6c6000)
$ echo $?
0

[rfjakob]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs
echo $?

for both static and dynamic builds?

[uli-heller]

Yes, no problem:

@.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify ./gocryptfs ; echo $? 0 @.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify /usr/bin/ls ; echo $? 0

​

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs echo $?

for both static and dynamic builds?

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2945509551 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZUEGECWITL6LBUHCA33CCAPZAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBVGUYDSNJVGE --=_eb2f380a19b7f9ed221340c34f281013 Content-Type: multipart/related; boundary="=_4f06a116d2eb017ca9c5744a17dc6ad0"

--=_4f06a116d2eb017ca9c5744a17dc6ad0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Yes, no problem:

=E2=80=8B

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

Hi, can you, on Ubuntu 24.04, do

ld.so --verify .=
/gocryptfs
echo $?

for both static and dynamic builds?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_4f06a116d2eb017ca9c5744a17dc6ad0 Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_4f06a116d2eb017ca9c5744a17dc6ad0--

--=_eb2f380a19b7f9ed221340c34f281013--

[uli-heller]

I did some additional experiments:

* file (binary) doesn't differentiate the two binaries
* readelf -d (binary)|grep NEEDED produces output for dynamic linked 

binaries only (… but is ugly)

I can do some more experiments tomorrow, it is 11pm localtime here…

​

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

@.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify ./gocryptfs ; echo $? 0 @.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify /usr/bin/ls ; echo $? 0

​

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs echo $?

for both static and dynamic builds?

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2945509551 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZUEGECWITL6LBUHCA33CCAPZAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBVGUYDSNJVGE --=_65057d71fd0c3747f4d562cb912a1a9b Content-Type: multipart/related; boundary="=_24f2bf5bd5a315906022b9ac6c322717"

--=_24f2bf5bd5a315906022b9ac6c322717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I did some additional experi= ments:

• file (binary) d= oesn’t differentiate the two binaries
• readelf -d (binary)|gr= ep NEEDED produces output for dynamic linked binaries only (…= but is ugly)

I can do some more experimen= ts tomorrow, it is 11pm localtime here…

=E2=80=8B

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

=E2=80=8B

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

Hi, can you, on Ubuntu 24.04, do

ld.so --veri=
fy ./gocryptfs
echo $?

for both static and dynamic builds?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_24f2bf5bd5a315906022b9ac6c322717 Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_24f2bf5bd5a315906022b9ac6c322717--

--=_65057d71fd0c3747f4d562cb912a1a9b--

[uli-heller]

According to https://www.baeldung.com/linux/show-shared-libraries-executables, "objdump" might be the way to do the check:

$ objdump -p ./gocryptfs|grep NEEDED $ objdump -p /usr/bin/ls|grep NEEDED NEEDED libselinux.so.1 NEEDED libc.so.6

So:

if [ -z "$(objdump -p gocryptfs|grep NEEDED)" ]; then echo "build-without-openssl.bash: error: compiled binary is not static" exit 1 fi

​

Am 2025-06-05 22:55, schrieb Uli Heller:

I did some additional experiments:

• file (binary) doesn't differentiate the two binaries
• readelf -d (binary)|grep NEEDED produces output for dynamic linked binaries only (… but is ugly)

I can do some more experiments tomorrow, it is 11pm localtime here…

​

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

@.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify ./gocryptfs ; echo $? 0 @.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify /usr/bin/ls ; echo $? 0

​

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs echo $?

for both static and dynamic builds?

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2945509551 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZUEGECWITL6LBUHCA33CCAPZAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBVGUYDSNJVGE --=_7585709e72e763d47f62639d3b1c8f53 Content-Type: multipart/related; boundary="=_7b8a35d1a984500a26ec39e6eb23552d"

--=_7b8a35d1a984500a26ec39e6eb23552d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

According to https://www.b= aeldung.com/linux/show-shared-libraries-executables,
“objdum= p” might be the way to do the check:

$ objdump -p ./gocryptfs|grep NEEDED
$ objdump -p /usr/bin/ls|grep NEEDED
  NEEDED               libselinux.so.1
  NEEDED               libc.so.6

So:

if [ -z "$(objdump -p gocryptfs|grep NEEDED)" ]; then
        echo "build-without-openssl.bash: error: compiled binary is not sta=
tic"
        exit 1
fi

=E2=80=8B

Am 2025-06-05 22:55, schrieb Uli Heller:

I did some additional experi= ments:

• file (binary) d= oesn’t differentiate the two binaries
• readelf -d (binary)|gr= ep NEEDED produces output for dynamic linked binaries only (…= but is ugly)

I can do some more experimen= ts tomorrow, it is 11pm localtime here…

=E2=80=8B

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

=E2=80=8B

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

Hi, can you, on Ubuntu 24.04, do

ld.so --=
verify ./gocryptfs
echo $?

for both static and dynamic builds?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_7b8a35d1a984500a26ec39e6eb23552d Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_7b8a35d1a984500a26ec39e6eb23552d--

--=_7585709e72e763d47f62639d3b1c8f53--

[uli-heller]

According to https://www.baeldung.com/linux/show-shared-libraries-executables, "objdump" might be the way to do the check:

$ objdump -p ./gocryptfs|grep NEEDED $ objdump -p /usr/bin/ls|grep NEEDED NEEDED libselinux.so.1 NEEDED libc.so.6

So: (2nd try - fixed condition)

if [ -n "$(objdump -p gocryptfs|grep NEEDED)" ]; then echo "build-without-openssl.bash: error: compiled binary is not static" exit 1 fi

​

Am 2025-06-05 22:55, schrieb Uli Heller:

I did some additional experiments:

• file (binary) doesn't differentiate the two binaries
• readelf -d (binary)|grep NEEDED produces output for dynamic linked binaries only (… but is ugly)

I can do some more experiments tomorrow, it is 11pm localtime here…

​

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

@.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify ./gocryptfs ; echo $? 0 @.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify /usr/bin/ls ; echo $? 0

​

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs echo $?

for both static and dynamic builds?

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2945509551 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZUEGECWITL6LBUHCA33CCAPZAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBVGUYDSNJVGE --=_003afeb65e0ae4165d913da753456917 Content-Type: multipart/related; boundary="=_0105bc75cde35ad6a71b8de27fc5b69f"

--=_0105bc75cde35ad6a71b8de27fc5b69f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

According to https://www.baeldung.com/linux/show-shared= -libraries-executables,
“objdump” might be the way to = do the check:

$ objdump -p ./gocryptfs|grep NEEDED
$ objdump -p /usr/bin/ls|grep NEEDED
  NEEDED               libselinux.so.1
  NEEDED               libc.so.6

So: (2nd try - fixed conditi= on)

if [ -n "$(objdump -p gocryptfs|grep NEEDED)" ]; then
        echo "build-without-openssl.bash: error: compiled binary is not sta=
tic"
        exit 1
fi

=E2=80=8B

Am 2025-06-05 22:55, schrieb Uli Heller:

I did some additional experi= ments:

• file (binary) d= oesn’t differentiate the two binaries
• readelf -d (binary)|gr= ep NEEDED produces output for dynamic linked binaries only (…= but is ugly)

I can do some more experimen= ts tomorrow, it is 11pm localtime here…

=E2=80=8B

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

=E2=80=8B

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

Hi, can you, on Ubuntu 24.04, do

ld.s=
o --verify ./gocryptfs
echo $?

for both static and dynamic builds?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_0105bc75cde35ad6a71b8de27fc5b69f Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_0105bc75cde35ad6a71b8de27fc5b69f--

--=_003afeb65e0ae4165d913da753456917--

[uli-heller]

... or maybe better:

$ objdump -T gocryptfs >/dev/null; echo $? objdump: gocryptfs: Kein dynamisches Objekt 1 $ objdump -T /usr/bin/ls >/dev/null; echo $? 0

​

Am 2025-06-05 23:55, schrieb Uli Heller:

According to https://www.baeldung.com/linux/show-shared-libraries-executables, "objdump" might be the way to do the check:

$ objdump -p ./gocryptfs|grep NEEDED $ objdump -p /usr/bin/ls|grep NEEDED NEEDED libselinux.so.1 NEEDED libc.so.6

So: (2nd try - fixed condition)

if [ -n "$(objdump -p gocryptfs|grep NEEDED)" ]; then echo "build-without-openssl.bash: error: compiled binary is not static" exit 1 fi

​

Am 2025-06-05 22:55, schrieb Uli Heller:

I did some additional experiments:

• file (binary) doesn't differentiate the two binaries
• readelf -d (binary)|grep NEEDED produces output for dynamic linked binaries only (… but is ugly)

I can do some more experiments tomorrow, it is 11pm localtime here…

​

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

@.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify ./gocryptfs ; echo $? 0 @.:~/build/gocryptfs/gocryptfs-2.5.4.15$ ld.so --verify /usr/bin/ls ; echo $? 0

​

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

Hi, can you, on Ubuntu 24.04, do

ld.so --verify ./gocryptfs echo $?

for both static and dynamic builds?

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2945509551 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZUEGECWITL6LBUHCA33CCAPZAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBVGUYDSNJVGE --=_5c449bd9aa4f9711dd93504fa513d6d9 Content-Type: multipart/related; boundary="=_21494a4612c0a9954c1502aec1086c1d"

--=_21494a4612c0a9954c1502aec1086c1d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

... or maybe better:

$ objdump -T gocryptfs >/dev/null; echo $?
objdump: gocryptfs: Kein dynamisches Objekt
1
$ objdump -T /usr/bin/ls >/dev/null; echo $?
0

=E2=80=8B

Am 2025-06-05 23:55, schrieb Uli Heller:

I did some additional experi= ments:

• file (binary) d= oesn’t differentiate the two binaries
• readelf -d (binary)|gr= ep NEEDED produces output for dynamic linked binaries only (…= but is ugly)

I can do some more experimen= ts tomorrow, it is 11pm localtime here…

=E2=80=8B

Am 2025-06-05 22:47, schrieb Uli Heller:

Yes, no problem:

=E2=80=8B

So no difference between the two unforunately

Am 2025-06-05 19:59, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

Hi, can you, on Ubuntu 24.04, do

=
ld.so --verify ./gocryptfs
echo $?

for both static and dynamic builds?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_21494a4612c0a9954c1502aec1086c1d Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_21494a4612c0a9954c1502aec1086c1d--

--=_5c449bd9aa4f9711dd93504fa513d6d9--

[rfjakob]

objdump -f shows DYNAMIC (or not if static). Problem is that objdump is not installed per default AFAIR

$ objdump -f gocryptfs

gocryptfs:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000000000047d4e0

[rfjakob]

That ld.so --verify accepts the static binary is so strange! The ld.so man page literally says

       --verify
              Verify that program is dynamically linked and this dynamic
              linker can handle it.

[uli-heller]

Yes, you're right with that. "objdump" is part of "binutils" which is not installed by default (https://releases.ubuntu.com/noble/ubuntu-24.04.2-desktop-amd64.manifest). Too bad!

Am 2025-06-06 08:14, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

objdump -f shows DYNAMIC (or not if static). Problem is that objdump is not installed per default AFAIR

$ objdump -f gocryptfs

gocryptfs: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x000000000047d4e0

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2948213809 [2] https://github.com/notifications/unsubscribe-auth/AAMZQZTMN6HV7VS6AEYDL5T3CEWTVAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBYGIYTGOBQHE

[uli-heller]

Yes, it is an ugly beast!

    --list List all dependencies and how they are resolved.

... could be quite helpful, but:

$ ld.so --list ./gocryptfs-dynamic linux-vdso.so.1 (0x00007fffcb707000) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f7602ab0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f760289e000) /lib64/ld-linux-x86-64.so.2 => ld.so (0x00007f7603542000) $ ld.so --list ./gocryptfs-static statically linked

​

So: It lists all dependencies or "statically linked".

Am 2025-06-06 08:16, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926) [1]

That ld.so --verify accepts the static binary is so strange! The ld.so [2] man page literally says

--verify Verify that program is dynamically linked and this dynamic linker can handle it.

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [3]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/rfjakob/gocryptfs/issues/926#issuecomment-2948217453 [2] https://man7.org/linux/man-pages/man8/ld.so.8.html [3] https://github.com/notifications/unsubscribe-auth/AAMZQZVQOBSXSID5J4C5C4L3CEW5JAVCNFSM6AAAAAB6V2N2WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBYGIYTONBVGM --=_fea27543577e7fb32a57146b2e6844c9 Content-Type: multipart/related; boundary="=_e9cd5d8866916abbdbad12de67810807"

--=_e9cd5d8866916abbdbad12de67810807 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Yes, it is an ugly beast!

       --list L= ist all dependencies and how they are resolved.

... could be quite helpful, but:

$ ld.so --list ./gocryptfs-dynamic=20
    linux-vdso.so.1 (0x00007fffcb707000)
    libcrypto.so.3 =3D> /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f76=
02ab0000)
    libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007f760289e000)
    /lib64/ld-linux-x86-64.so.2 =3D> ld.so (0x00007f7603542000)
$ ld.so --list ./gocryptfs-static
    statically linked

= =E2=80=8B

So: It lists all dependencies or "statically linked".

Am 2025-06-06 08:16, schrieb rfjakob:

rfjakob left a comment (rfjakob/gocryptfs#926)

That ld.so --verify ac= cepts the static binary is so strange! The --verify Verify that program is dynamically linked and this dynamic linker can handle it.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are rece= iving this because you authored the thread.

--=_e9cd5d8866916abbdbad12de67810807 Content-Transfer-Encoding: base64 Content-ID: @.***> Content-Type: image/gif; name=blocked.gif Content-Disposition: inline; filename=blocked.gif; size=118

R0lGODlhZAAyAIAAAPrOzgAAACH5BAAAAAAALAAAAABkADIAAAJNhI+py+0Po5y02ouz3rz7D4bi SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvls KwAAOw== --=_e9cd5d8866916abbdbad12de67810807--

--=_fea27543577e7fb32a57146b2e6844c9--

[rfjakob]

I deleted the check. It's more trouble than it's worth.

Thanks again for the report!