From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 17079 invoked from network); 1 Jan 2022 09:33:07 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2022 09:33:07 -0000
Received: (qmail 11571 invoked by uid 550); 1 Jan 2022 09:33:03 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 11536 invoked from network); 1 Jan 2022 09:33:03 -0000
Message-ID: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk>
Date: Sat, 1 Jan 2022 17:32:46 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.0
Content-Language: en-US
To: musl@lists.openwall.com
From: Sebastien Bourdeauducq <sb@m-labs.hk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [musl] building statically linked DSOs with musl

Dear musl libc developers,

I'm trying to build a shared library that is itself statically linked.
The reason for doing that is building a Python plug-in, which contains 
complex dependencies such as LLVM, and which should use a custom malloc 
everywhere. Dynamic linking doesn't work in my case as the malloc & co 
symbols are already resolved by Python when my plugin is loaded, and 
replacing all malloc & co calls in LLVM, libstdc++, etc. with a 
differently named function seems pretty difficult.

Naturally I've come to musl libc, since glibc comes with a bunch of 
nonsense when attempting to link against it statically.

For simple code this goes reasonably well:
$ nix-shell -p pkgsMusl.clang_13
$ cat staticlib.c
#include <stdio.h>

void test_func() {
	puts("hello world");
}

$ clang -o libstaticlib.so -shared staticlib.c -fPIC -Wl,-Bstatic -lc
$ ldd libstaticlib.so
	statically linked

The "test" program below is built with and linked against glibc, as 
would be the case in my Python plugin situation.

$ nix-shell -p clang_13
$ cat test.c
#include <stdio.h>

void test_func();

int main() {
	test_func();
	return 0;
}
$ clang -o test -L. -lstaticlib test.c
$ ldd test
	linux-vdso.so.1 (0x00007ffd4db5a000)
	libstaticlib.so => not found
	libc.so.6 => 
/nix/store/vjq3q7dq8vmc13c3py97v27qwizvq7fd-glibc-2.33-59/lib/libc.so.6 
(0x00007fbb29746000)
	/nix/store/vjq3q7dq8vmc13c3py97v27qwizvq7fd-glibc-2.33-59/lib/ld-linux-x86-64.so.2 => /nix/store/vjq3q7dq8vmc13c3py97v27qwizvq7fd-glibc-2.33-59/lib64/ld-linux-x86-64.so.2 (0x00007fbb2990d000)
$ LD_LIBRARY_PATH=. ./test
hello world

So far, so good. But trouble begins when calling certain musl functions 
from the library:
$ cat staticlib.c
#include <stdio.h>
#include <sys/time.h>

void test_func() {
	struct timeval tv;
	gettimeofday(&tv, NULL);
	printf("%ld", tv.tv_sec);
}
$ clang -o libstaticlib.so -shared staticlib.c -fPIC -Wl,-Bstatic -lc
$ LD_LIBRARY_PATH=. ./test
Segmentation fault (core dumped)

(gdb) backtrace
#0  0x00007ffff7fbf527 in __vdsosym () from ./libstaticlib.so
#1  0x00007ffff7fbf439 in cgt_init () from ./libstaticlib.so
#2  0x00007ffff7fbf47d in clock_gettime () from ./libstaticlib.so
#3  0x00007ffff7fbedba in gettimeofday () from ./libstaticlib.so
#4  0x00007ffff7fbd2c5 in test_func () from ./libstaticlib.so
#5  0x0000000000401138 in main ()

Has anyone encountered this and would have an explanation or fix?

Thanks,
Sébastien