From owner-freebsd-questions@freebsd.org Wed Oct 16 11:15:55 2019 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7D4A162269 for ; Wed, 16 Oct 2019 11:15:55 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from sapphire.magnetkern.de (sapphire.magnetkern.de [185.228.139.199]) by mx1.freebsd.org (Postfix) with ESMTP id 46tV8p69Cxz4bJg for ; Wed, 16 Oct 2019 11:15:54 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from titanium (p57A35420.dip0.t-ipconnect.de [87.163.84.32]) by sapphire.magnetkern.de (Postfix) with ESMTPSA id 0A5849BF1 for ; Wed, 16 Oct 2019 11:15:52 +0000 (UTC) Date: Wed, 16 Oct 2019 13:15:52 +0200 From: Jan Behrens To: freebsd-questions@freebsd.org Subject: Re: Problems with ld, libc, and "struct stat" Message-Id: <20191016131552.6fda34292987e22ae78072cc@magnetkern.de> In-Reply-To: <47c27361-4e74-05d1-3343-e39526730d85@malikania.fr> References: <20191015204400.e33c8f62af711e829288ddae@magnetkern.de> <47c27361-4e74-05d1-3343-e39526730d85@malikania.fr> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46tV8p69Cxz4bJg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jbe-mlist@magnetkern.de designates 185.228.139.199 as permitted sender) smtp.mailfrom=jbe-mlist@magnetkern.de X-Spamd-Result: default: False [-1.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[32.84.163.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992,0]; DMARC_NA(0.00)[magnetkern.de]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.937,0]; IP_SCORE(-0.13)[asn: 197540(-0.62), country: DE(-0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197540, ipnet:185.228.136.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 11:15:55 -0000 On Wed, 16 Oct 2019 09:18:52 +0200 David Demelier wrote: > Le 15/10/2019 à 20:44, Jan Behrens a écrit : > > I stumbled across a weird problem related stat() that (according to my > > research) seems to be related to an update of the "struct stat" > > C-structure in recent Kernel versions. > > > > [...] > > > > stat("testlib.c", &sb); > > Please test the result of stat otherwise sb is left untouched (so all > member undefined). You are right, of course (this was just a quick and dirty demonstration). > > But when I make a shared library like this, I get a different result: > > > > % ld -shared -o testlib.so testlib.o > > Hmm, we usually never call the linker itself when creating shared libraries. > > Try instead: cc -shared -o testlib.so testlib.o > > HTH > -- > David Thank you very much; I tried that, and it works properly: % cc -Wall -c -fPIC -o testlib.o testlib.c % cc -shared -o testlib.so testlib.o % cc -Wall -o testprog `pwd`/testlib.so testprog.c % ./testprog Size of testlib.c is 168 bytes. I will from now on use cc instead of ld to create shared libraries. I still wonder though if there is any documentation on this behavior (and where to find it), whether it's FreeBSD related or LLVM related. It feels a bit scary that using "ld" to make a shared library can result in weird runtime behavior without even raising a warning. Do you know any link where I find a more detailed explanation about why I need to use "cc" instead of "ld" to create shared libraries? I assume that "cc" adds the necessary options to "ld" that are otherwise missing. But I don't see where this is documented. When I search the man page for "cc" (clang - the Clang C, C++, and Objective-C compiler), I even do not find any "-shared" option at all. Only in the "ld" manpage (ld.lld – ELF linker from the LLVM project), there is an entry about the "-shared" option: --shared Build a shared object. Following the man pages, I would naïvely use "ld", which leads to the bad and unexpected results as described in my original post. Thanks again Jan P.S.: My setup is: % freebsd-version 12.0-RELEASE-p10 % uname -i -K -m -p -r -s -U -v FreeBSD 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC amd64 amd64 GENERIC 1200086 1200086 % cc --version FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin % ld --version LLD 6.0.1 (FreeBSD 335540-1200005) (compatible with GNU linkers)