From owner-freebsd-hackers@freebsd.org Sun May 6 00:42:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB4DFFC1104; Sun, 6 May 2018 00:42:07 +0000 (UTC) (envelope-from jinmei.tatuya@gmail.com) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67F0C738FF; Sun, 6 May 2018 00:42:07 +0000 (UTC) (envelope-from jinmei.tatuya@gmail.com) Received: by mail-lf0-f49.google.com with SMTP id j193-v6so35793881lfg.6; Sat, 05 May 2018 17:42:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rJYe38PTlfc2Py3GboEFdHpV2NryoPnqFK2htxyXhv0=; b=pIBC0TxgvJjzUrFNnlLmSJ++J1/kThcxjjob1y9SITdnDixdD5X++FS1mTGioyDEnc Ukye7IhLECFOkU/1ndyzTy6aDDy22i2+CirLSqdYPJq4Mimjcx4KqkuDYyNHvzuAB/EZ N9TMkIIKFTeAY1zDbWJNPI0SAyqQ9QsTuW4H/2QvJvcqX2K0E9vLsJfHxonR94EgYeLE l08wt8aBejnJS3OuA80YyiqU3v0gKirpWyi2ZWiHF+8/+nsyNX+PGTJf11mfYaFTIZqL JkTACC8cwWgwz4FlA8xUlHFV4AEZxuIRHs5giytuaFbxFloTFRsXuTm4WjVhPpXY5/eV MAng== X-Gm-Message-State: ALQs6tCd+xqh2uFjFd7n4DFZ5ENOyYaqHbGQywydDu49nkbrTyA3sxCE /0dTyuAMzdo7Rd05VE2DQAesy0C8hRU1qgSfIYjxV4DS X-Google-Smtp-Source: AB8JxZqy+gPs4E3aMTXefPgalNjwvNFFSNKi6MR9zc5TiYAhIjgPGhVsfQzzy9Srm8GAkegwECwG3r5OIj+b4e6ShA4= X-Received: by 2002:a2e:3c04:: with SMTP id j4-v6mr21146960lja.149.1525567319744; Sat, 05 May 2018 17:41:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Sun, 06 May 2018 00:41:49 +0000 Message-ID: Subject: Re: netstat(1) -s -f is broken To: bu7cher@yandex.ru Cc: dieterbsd@gmail.com, FreeBSD Net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sun, 06 May 2018 01:14:25 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 00:42:08 -0000 At Fri, 4 May 2018 13:19:57 +0300, "Andrey V. Elsukov" wrote: > > Doesn't work with -p either. > > netstat -I lo0 -s -p udp > > :udp: no per-interface stats routine > > > > It would be very useful if this actually worked. > Only IPv6 and ICMPv6 have per-interface statistics counters. Other > protocols don't have such support. That's how I remember why per-interface statistics was originally provided only for IPv6, but RFC4293 extended the concept to IPv4 (interestingly RFC4293 also seems to effectively deprecate per-interface ICMPv6 statistics). So it would make sense to make '-I -s -f inet' now works. The UDP case is totally different - as far as I remember there has never been per-interface UDP statistics defined in the form of RFC MIBs, so it's actually reasonable to emit an error against '-I -s -p udp'. -- JINMEI, Tatuya From owner-freebsd-hackers@freebsd.org Wed May 9 23:45:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A63A7FCF1ED; Wed, 9 May 2018 23:45:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DD3572828; Wed, 9 May 2018 23:45:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w49NjqaE039550 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 May 2018 16:45:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w49Njp0F039549; Wed, 9 May 2018 16:45:51 -0700 (PDT) (envelope-from sgk) Date: Wed, 9 May 2018 16:45:51 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Runtime loader issue Message-ID: <20180509234551.GA39526@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 23:45:59 -0000 In review PR 228007, it came to my attention some individuals are mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD issue". See https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html The problem can be summarized by the following % gfortran7 -o z h.f90 % ./z /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ /usr/local/lib/gcc7/libgfortran.so.4 not found gfortran7 is installed from ports/lang/gcc7. This is not a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. Specifically, there is a shared library name clash. % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 % ldd z z: libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x200a17000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) libc.so.7 => /lib/libc.so.7 (0x200ca3000) So, the runtime loader finds 6 instead of 716, tries to link, fails, and issues an error message. There are a number ways to fix this issue. 1) By far, the best solution would be to stop hijacking the libgcc name in libraries installed on FreeBSD that are not related to actual GCC software. % ls -l /lib/libgcc* /usr/lib/libgcc* (trimming lines) /lib/libgcc_s.so.1 /usr/lib/libgcc.a@ -> libcompiler_rt.a /usr/lib/libgcc_eh.a /usr/lib/libgcc_eh_p.a /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm aware that clang does not work on all archs and the ancient gcc lives on. 2) Given the expected push back againt solution 1), this solution proposes bumping the library version for /lib/libgcc_s.so.1 from 1 to some larger value, say, 10. It is unlikely that GCC will bump its shared library number anytime soon. GCC bumped it from 0 to 1 some 16 years ago. https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 This solution, however, papers over the general problem with name clashes. 3) This solution is to actually fix the runtime loader. If an error occurs with loading a shared library, then iterate over the entries in the hints file to check to see if another hint would satisfy the linking. Here, instead of issuing the above error, the loader would find entry 716, and load the correct libgcc_s.so.1. Admittedly, I haven't looked to see how difficult this solution would be. 4) Bump the shared library number of the individual ports. As a proof of concept, I've done this with ports/lang/gcc6. % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 % gfortran6 -o z h.f90 % ./z hello % ldd z z: libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x20096c000) libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) libc.so.7 => /lib/libc.so.7 (0x200df7000) This works for this particular name conflict. Hopefully, FreeBSD never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, however, introduces an incompatibility with what is actually distributed by GCC. Finally, can people stop referring to the above error as "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 07:47:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53CC9FB6A20; Thu, 10 May 2018 07:47:03 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C53E874861; Thu, 10 May 2018 07:47:02 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pg0-x229.google.com with SMTP id z4-v6so588735pgu.13; Thu, 10 May 2018 00:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k/t7kNBOazgBE3FJBSinMgaoORlvKqtQygY335rcIRM=; b=tR32XjXb49tbaQbHwnsLUimw2kcnkWqEET9eRCaKbn82M32ayIcLVyGmTs9rLnCaS9 WhGY6H1ARPVLJi3SIcxevWiCIrYBQ7y/CDzSrtQbrCY/6Ik47evXdFSIbLiruEcSd/Uz krG7msq71D0XVTIY/IHHRKO8dk3o9ixbwbQJFoSxLuxWzLKzDa5rVRPh0n8/afp+RmH+ 5T31LZ9ir+Mdftw/WSphYJH3fjJXHyP2KQvO0ovXUvMno6alT8YYuf+ryPdwFgZ5xDOA Po1ZHQhf0NxGS9CQSONFnGqYNmfMDnSe5dLtjD9VQOEYoL4IOnK+rgjzy05dHpW4xUq8 xgwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k/t7kNBOazgBE3FJBSinMgaoORlvKqtQygY335rcIRM=; b=NREZeXFEXIHLQpKQrjbc8A4zxoaxZMJL3iJ7td5Ttd1FTeMuqyzzeR9193USIraIoS zztSqF2AuMABN/PxJ7h42DOl/fUyFEVOzqeTGu4GNEGt5ixkqbhvzhVmzXECed3+JcR1 2mO/jiZb7Egy5NJfvbCSiTFGVwCIfG73ujrxjTcILwd9sveM3miYLOlMBmUEZq8ltJV3 vY8r3ZQwFvua457jdI9aUbpMLcbqta6RTeQNIC1qMHJn2bgf6n51RvC7wuB0qFjrGtRk Yqv+5DosF9vropc/5v5GnRWpuGeRNSkRsCk9Jr2Y0o3GtvNnYBTV9BRi/W7cVChFal2E XrlA== X-Gm-Message-State: ALKqPwc6fG/hStXLT+eo09UcRvyhHaLz2tcKh/4k9725K5e726vtbrMQ l4NXKy4Rl6qu2pKL5jVtpN8qBNwnA/QKmY6GfdXpQA== X-Google-Smtp-Source: AB8JxZq5UCu+fS3SwzcYxTMD5/vFnOuRyN50VTd+xdTQOcM8BqBrkp4Kn83wW5FY8w3lvFw6wsKMRm8L8/lzZAqNXkI= X-Received: by 2002:a63:b046:: with SMTP id z6-v6mr293063pgo.16.1525938421694; Thu, 10 May 2018 00:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.201 with HTTP; Thu, 10 May 2018 00:46:31 -0700 (PDT) In-Reply-To: <20180509234551.GA39526@troutmask.apl.washington.edu> References: <20180509234551.GA39526@troutmask.apl.washington.edu> From: Gleb Popov <6yearold@gmail.com> Date: Thu, 10 May 2018 10:46:31 +0300 Message-ID: Subject: Re: Runtime loader issue To: sgk@troutmask.apl.washington.edu Cc: FreeBSD Current , freebsd-hackers , FreeBSD ports list Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 07:47:03 -0000 On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > The problem can be summarized by the following > > % gfortran7 -o z h.f90 > % ./z > /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ > /usr/local/lib/gcc7/libgfortran.so.4 not found > > gfortran7 is installed from ports/lang/gcc7. This is not > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > Specifically, there is a shared library name clash. > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > % ldd z > z: > libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x200a17000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) > libc.so.7 => /lib/libc.so.7 (0x200ca3000) > > So, the runtime loader finds 6 instead of 716, tries to link, > fails, and issues an error message. There are a number ways to > fix this issue. > > 1) By far, the best solution would be to stop hijacking the libgcc > name in libraries installed on FreeBSD that are not related to > actual GCC software. > > % ls -l /lib/libgcc* /usr/lib/libgcc* > (trimming lines) > /lib/libgcc_s.so.1 > /usr/lib/libgcc.a@ -> libcompiler_rt.a > /usr/lib/libgcc_eh.a > /usr/lib/libgcc_eh_p.a > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > aware that clang does not work on all archs and the ancient gcc > lives on. > > 2) Given the expected push back againt solution 1), this solution > proposes bumping the library version for /lib/libgcc_s.so.1 from > 1 to some larger value, say, 10. It is unlikely that GCC will > bump its shared library number anytime soon. GCC bumped it from > 0 to 1 some 16 years ago. > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > This solution, however, papers over the general problem with > name clashes. > > 3) This solution is to actually fix the runtime loader. If an error > occurs with loading a shared library, then iterate over the entries > in the hints file to check to see if another hint would satisfy > the linking. Here, instead of issuing the above error, the loader > would find entry 716, and load the correct libgcc_s.so.1. > > Admittedly, I haven't looked to see how difficult this solution > would be. > > 4) Bump the shared library number of the individual ports. As a proof > of concept, I've done this with ports/lang/gcc6. > > % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc > --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 > +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 > @@ -20,7 +20,7 @@ > > SHLIB_EXT = .so > SHLIB_SOLINK = @shlib_base_name@.so > -SHLIB_SOVERSION = 1 > +SHLIB_SOVERSION = 2 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > SHLIB_MAP = @shlib_map_file@ > SHLIB_OBJS = @shlib_objs@ > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 > > % gfortran6 -o z h.f90 > % ./z > hello > % ldd z > z: > libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x20096c000) > libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) > libc.so.7 => /lib/libc.so.7 (0x200df7000) > > This works for this particular name conflict. Hopefully, FreeBSD > never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, > however, introduces an incompatibility with what is actually distributed > by GCC. > > Finally, can people stop referring to the above error as > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. > Our libgcc also lacks some functionality compared to the original one: https://reviews.freebsd.org/D11482 > -- > Steve > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu May 10 14:25:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 938DDFCB0A2; Thu, 10 May 2018 14:25:01 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 334468A077; Thu, 10 May 2018 14:25:00 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by artemis.db.net (Postfix) with ESMTP id 7DB3D1023A; Thu, 10 May 2018 14:24:53 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id C788E39813; Thu, 10 May 2018 10:24:52 -0400 (EDT) Date: Thu, 10 May 2018 10:24:52 -0400 From: Diane Bruce To: Gleb Popov <6yearold@gmail.com> Cc: sgk@troutmask.apl.washington.edu, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue Message-ID: <20180510142452.GA69005@night.db.net> References: <20180509234551.GA39526@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:25:01 -0000 On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > In review PR 228007, it came to my attention some individuals are > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > issue". See Indeed. I've tried to make it clear it is a name conflict with libgcc in my own bug reports on the subject. > > > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > > > The problem can be summarized by the following ... > > gfortran7 is installed from ports/lang/gcc7. This is not > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > > > Specifically, there is a shared library name clash. > > > > % ldconfig -r | grep gcc_ > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 Yep. See https://wiki.freebsd.org/libgcc%20problem > > > > So, the runtime loader finds 6 instead of 716, tries to link, > > fails, and issues an error message. There are a number ways to > > fix this issue. > > > > 1) By far, the best solution would be to stop hijacking the libgcc > > name in libraries installed on FreeBSD that are not related to > > actual GCC software. Agreed, however this has the side effect of meaning conflicts with libraries between clang and gcc libs. Notably gfortran and flang use different conventions for I/O :( See http://people.FreeeBSD.org/~db/fortran_libs.txt > > > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > > aware that clang does not work on all archs and the ancient gcc > > lives on. > > I've argued for this as well and frankly I still think it is the best solution all around. > > 2) Given the expected push back againt solution 1), this solution > > proposes bumping the library version for /lib/libgcc_s.so.1 from > > 1 to some larger value, say, 10. It is unlikely that GCC will > > bump its shared library number anytime soon. GCC bumped it from > > 0 to 1 some 16 years ago. > > > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > > > This solution, however, papers over the general problem with > > name clashes. Yep. I know work is slowly being done to modernise our libgcc already but the toolchain folks are busy... > > > > 3) This solution is to actually fix the runtime loader. If an error > > occurs with loading a shared library, then iterate over the entries > > in the hints file to check to see if another hint would satisfy > > the linking. Here, instead of issuing the above error, the loader > > would find entry 716, and load the correct libgcc_s.so.1. This breaks if the bad libgcc is already linked. We'd have to rip out the original bindings at run time, then re-bind to a new libgcc. I looked at the rtld code months ago. Nasty and silly. > > > > Admittedly, I haven't looked to see how difficult this solution > > would be. Very ;) > > > > 4) Bump the shared library number of the individual ports. As a proof > > of concept, I've done this with ports/lang/gcc6. > > ... > > > > Finally, can people stop referring to the above error as > > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. Yes, please. I tracked it down to libgcc months ago, made my findings generally available and yet people are still calling it a libgfortran problem. > > > > Our libgcc also lacks some functionality compared to the original one: > https://reviews.freebsd.org/D11482 Yes. Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@freebsd.org Thu May 10 15:15:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727C6FCD0C6; Thu, 10 May 2018 15:15:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC3A6EC9A; Thu, 10 May 2018 15:15:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AFFOJF043970 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 08:15:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AFFMHh043969; Thu, 10 May 2018 08:15:22 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 08:15:22 -0700 From: Steve Kargl To: Diane Bruce Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue Message-ID: <20180510151522.GA43677@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510142452.GA69005@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510142452.GA69005@night.db.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 15:15:33 -0000 On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > In review PR 228007, it came to my attention some individuals are > > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > > issue". See > > Indeed. I've tried to make it clear it is a name conflict with libgcc > in my own bug reports on the subject. > > > > > > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > > > > > The problem can be summarized by the following > ... > > > gfortran7 is installed from ports/lang/gcc7. This is not > > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > > > > > Specifically, there is a shared library name clash. > > > > > > % ldconfig -r | grep gcc_ > > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > > > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > Yep. > See https://wiki.freebsd.org/libgcc%20problem > Interesting page. I was aware that in the past you tried working out a solution to the problem. I did not realize you docoumented the issue. A few corrections to your wiki page. 1) The correct spelling of the name of the language is Fortran (with a capital F). It has been the official standard spelling since Fortran 90. 2) You have "... to always support quad math (*8) and ...". Quad precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard). 3) "subsitute" is normally spelled with an extra 't'. :-) > > > So, the runtime loader finds 6 instead of 716, tries to link, > > > fails, and issues an error message. There are a number ways to > > > fix this issue. > > > > > > 1) By far, the best solution would be to stop hijacking the libgcc > > > name in libraries installed on FreeBSD that are not related to > > > actual GCC software. > > Agreed, however this has the side effect of meaning conflicts with libraries > between clang and gcc libs. Notably gfortran and flang use different > conventions for I/O :( > > See http://people.FreeeBSD.org/~db/fortran_libs.txt > Page doesn't appear to exist? If I go to https://people.freebsd.org/homepage.html you're not listed. > > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > > > aware that clang does not work on all archs and the ancient gcc > > > lives on. > > > > > I've argued for this as well and frankly I still think it is the best > solution all around. > > > > 2) Given the expected push back againt solution 1), this solution > > > proposes bumping the library version for /lib/libgcc_s.so.1 from > > > 1 to some larger value, say, 10. It is unlikely that GCC will > > > bump its shared library number anytime soon. GCC bumped it from > > > 0 to 1 some 16 years ago. > > > > > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > > > > > This solution, however, papers over the general problem with > > > name clashes. > > Yep. I know work is slowly being done to modernise our libgcc already > but the toolchain folks are busy... > > > > > > > 3) This solution is to actually fix the runtime loader. If an error > > > occurs with loading a shared library, then iterate over the entries > > > in the hints file to check to see if another hint would satisfy > > > the linking. Here, instead of issuing the above error, the loader > > > would find entry 716, and load the correct libgcc_s.so.1. > > This breaks if the bad libgcc is already linked. We'd have to rip > out the original bindings at run time, then re-bind to a new libgcc. > I looked at the rtld code months ago. Nasty and silly. > > > > > > > Admittedly, I haven't looked to see how difficult this solution > > > would be. > > Very ;) Just started reading the source code. Don't scare the unwary. :-) -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 15:23:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E895DFCD7FE for ; Thu, 10 May 2018 15:23:40 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94CE071D50 for ; Thu, 10 May 2018 15:23:40 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id w4AFNd20007029; Thu, 10 May 2018 11:23:39 -0400 (EDT) (envelope-from lidl@pix.net) Subject: Re: Runtime loader issue To: freebsd-hackers@freebsd.org References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510142452.GA69005@night.db.net> <20180510151522.GA43677@troutmask.apl.washington.edu> From: Kurt Lidl Message-ID: Date: Thu, 10 May 2018 11:23:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180510151522.GA43677@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 15:23:41 -0000 On 5/10/18 11:15 AM, Steve Kargl wrote: > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: >> >> Agreed, however this has the side effect of meaning conflicts with libraries >> between clang and gcc libs. Notably gfortran and flang use different >> conventions for I/O :( >> >> See http://people.FreeeBSD.org/~db/fortran_libs.txt >> > > Page doesn't appear to exist? If I go to > > https://people.freebsd.org/homepage.html > > you're not listed. There's one too many "e" characters in the given URI. Correct URI: http://people.FreeBSD.org/~db/fortran_libs.txt -Kurt From owner-freebsd-hackers@freebsd.org Thu May 10 16:23:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FF5FFCF2E6; Thu, 10 May 2018 16:23:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay118.isp.belgacom.be (mailrelay118.isp.belgacom.be [195.238.20.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 545928056B; Thu, 10 May 2018 16:23:03 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3AMGvo9BRN2zWJRwDIA2poOab9VNpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6zYhCN2/xhgRfzUJnB7Loc0qyK6/umATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSizexfb1/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlS?= =?us-ascii?q?gHLSY0/m/XhMJukaxVoxCupxJwzIHIe4yVMeZycr/HcN8GWWZNQMBcXDFBDIOm?= =?us-ascii?q?aIsPCvIMM/hZr4n/o1sFsAWzBQ6rBOP01DBIg2X53ash0+88FgzGwA0gH9AKsH?= =?us-ascii?q?nPrNv1LrkdXv6owafVwzvPdfRW2S3y6IXRdB0qvP+CXbV1ccXLyEkvERvIjluK?= =?us-ascii?q?qYP7ITyazf8NvHWB4+pnT+KvhHYrqw5trTezx8ogkJXGiZgJylzc+iV5xps1Kc?= =?us-ascii?q?e/SE5hbt6pFoZbuSKCN4ZuQc4uXntktDg1x7Ebo5K3YjQGxIo9yxLCa/GKfY6F?= =?us-ascii?q?6Q/5WumLOzd3nndldaq6hxa17Eev1PXxVtKx0FZWtipFlcTMtmwV2xzT9MeHTv?= =?us-ascii?q?x981+i2TmV0wDT6+RELl4ularcMZIh3r8wlpgXsUjZAiD2n0L2jLSIeUUh4Oeo?= =?us-ascii?q?7f/nbq/hpp+GOI94kgD+MqIwlcyjGek1MRUCU3KF9emzybHv51P1TKlUgvEsj6?= =?us-ascii?q?XUsJ7XKdwepqGjAg9V1ogj6wy4DzejyNkYgXgHLFBBeB+cgYjpIU/BL+7jAvek?= =?us-ascii?q?nlugijBrx+rJPrH5GJXCMmDDkKv9fbZ680NcxhAzws5B6J1PEbEOPev/Wlf2tN?= =?us-ascii?q?zCEh85KBe5w+j9CNpjyIwRQnmPDbKDPKPVq1+I6folI/OQa48NpDb9N/8l6ubg?= =?us-ascii?q?jX8jh1ASY7Km3YAKZ3yhHvRpOVmWYXnyjdcbCmcHpQQ+TPb0h1KcSjFTfGu9U7?= =?us-ascii?q?g75jEhB4KsFZ3DSZy1gLydwCe7GYVbZm5cCl+SD3jnbJ6EVOoVZC2OP89hiCYE?= =?us-ascii?q?WqanS489zhyuuhX6xKR5IeXP4S0XqIjv1N9v5+3cxlkO8mlPE8mD3imuRnt7mi?= =?us-ascii?q?tcXDA19LxlplFhz16Y0u5xm/geCtVI5/JPXRs9M9jRw/EsWP7oXQeUQtaLTB6N?= =?us-ascii?q?RdK9DDQ4SMl5l8MPYUJVNc+vgzr482ytGbBDxO/DP4A97q+Jhyu5HM160XuTjK?= =?us-ascii?q?Q=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BgBQBscfRa/5nK8VFcDg4BAQEEAQEKA?= =?us-ascii?q?QGDQ1MOeyiLdF6MDgEBgXgxAV2TM4F4Iw2BUoJ1AoJ/IjQYAQIBAQEBAQECAWs?= =?us-ascii?q?cDII1IoJSAQEEASYvIxALDgoJJQ8ZER4GExuDCoIDC60tM4hDgjkPijiEGoMRA?= =?us-ascii?q?wEBF4caAoU7hlmEb4cqCYNEgiOCUoI6K4MmaYwHiU6ILRw4gVJNMAhIEYIlCVa?= =?us-ascii?q?KMYUEPD0wAY1xKoIcAQE?= X-IPAS-Result: =?us-ascii?q?A2BgBQBscfRa/5nK8VFcDg4BAQEEAQEKAQGDQ1MOeyiLdF6?= =?us-ascii?q?MDgEBgXgxAV2TM4F4Iw2BUoJ1AoJ/IjQYAQIBAQEBAQECAWscDII1IoJSAQEEA?= =?us-ascii?q?SYvIxALDgoJJQ8ZER4GExuDCoIDC60tM4hDgjkPijiEGoMRAwEBF4caAoU7hlm?= =?us-ascii?q?Eb4cqCYNEgiOCUoI6K4MmaYwHiU6ILRw4gVJNMAhIEYIlCVaKMYUEPD0wAY1xK?= =?us-ascii?q?oIcAQE?= Received: from 153.202-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.202.153]) by relay.skynet.be with ESMTP; 10 May 2018 18:21:53 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id w4AGLpjR078852; Thu, 10 May 2018 18:21:53 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Thu, 10 May 2018 18:21:51 +0200 From: Tijl Coosemans To: Steve Kargl Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510182151.409b7fb8@kalimero.tijl.coosemans.org> In-Reply-To: <20180509234551.GA39526@troutmask.apl.washington.edu> References: <20180509234551.GA39526@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/nD2m3FmfImDp2u+ur0Mr4sg" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:23:05 -0000 --MP_/nD2m3FmfImDp2u+ur0Mr4sg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > The problem can be summarized by the following > > % gfortran7 -o z h.f90 > % ./z > /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ > /usr/local/lib/gcc7/libgfortran.so.4 not found > > gfortran7 is installed from ports/lang/gcc7. This is not > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > Specifically, there is a shared library name clash. > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > % ldd z > z: > libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x200a17000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) > libc.so.7 => /lib/libc.so.7 (0x200ca3000) > > So, the runtime loader finds 6 instead of 716, tries to link, > fails, and issues an error message. There are a number ways to > fix this issue. > > 1) By far, the best solution would be to stop hijacking the libgcc > name in libraries installed on FreeBSD that are not related to > actual GCC software. > > % ls -l /lib/libgcc* /usr/lib/libgcc* > (trimming lines) > /lib/libgcc_s.so.1 > /usr/lib/libgcc.a@ -> libcompiler_rt.a > /usr/lib/libgcc_eh.a > /usr/lib/libgcc_eh_p.a > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > aware that clang does not work on all archs and the ancient gcc > lives on. > > 2) Given the expected push back againt solution 1), this solution > proposes bumping the library version for /lib/libgcc_s.so.1 from > 1 to some larger value, say, 10. It is unlikely that GCC will > bump its shared library number anytime soon. GCC bumped it from > 0 to 1 some 16 years ago. > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > This solution, however, papers over the general problem with > name clashes. > > 3) This solution is to actually fix the runtime loader. If an error > occurs with loading a shared library, then iterate over the entries > in the hints file to check to see if another hint would satisfy > the linking. Here, instead of issuing the above error, the loader > would find entry 716, and load the correct libgcc_s.so.1. > > Admittedly, I haven't looked to see how difficult this solution > would be. > > 4) Bump the shared library number of the individual ports. As a proof > of concept, I've done this with ports/lang/gcc6. > > % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc > --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 > +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 > @@ -20,7 +20,7 @@ > > SHLIB_EXT = .so > SHLIB_SOLINK = @shlib_base_name@.so > -SHLIB_SOVERSION = 1 > +SHLIB_SOVERSION = 2 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > SHLIB_MAP = @shlib_map_file@ > SHLIB_OBJS = @shlib_objs@ > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 > > % gfortran6 -o z h.f90 > % ./z > hello > % ldd z > z: > libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) > libm.so.5 => /lib/libm.so.5 (0x20096c000) > libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) > libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) > libc.so.7 => /lib/libc.so.7 (0x200df7000) > > This works for this particular name conflict. Hopefully, FreeBSD > never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, > however, introduces an incompatibility with what is actually distributed > by GCC. > > Finally, can people stop referring to the above error as > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. libgcc_s.so implements the _Unwind_* API to handle stack unwinding. This code is shared between all compilers and languages because the stack can contain frames from different compilers and languages. So, you cannot change the name or version of the library. I've been testing the attached patch in combination with the ports tree patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046. The patch makes three changes to /etc/rc.d/ldconfig: 1) Use 'sort -r' so /usr/local/lib/gcc7 appears before /usr/local/lib/gcc6. 2) Move hardcoded paths like /lib and /usr/lib to /etc/defaults/rc.conf so the order relative to other paths can be configured. 3) Change the order of ldconfig_local_dirs and ldconfig_paths so /lib and /usr/lib appear last. This brings rc.d/ldconfig in line with compilers and rtld(1) which also search /lib and /usr/lib last. --MP_/nD2m3FmfImDp2u+ur0Mr4sg Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=ldconfig.patch Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 333461) +++ etc/defaults/rc.conf (working copy) @@ -629,14 +629,14 @@ linux_enable="NO" # Linux binary compatibility loaded clear_tmp_enable="NO" # Clear /tmp at startup. clear_tmp_X="YES" # Clear and recreate X11-related directories in /tmp ldconfig_insecure="NO" # Set to YES to disable ldconfig security checks -ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg" +ldconfig_paths="/usr/local/lib /usr/local/lib/compat/pkg /usr/lib /usr/lib/compat /lib" # shared library search paths ldconfig32_paths="/usr/lib32 /usr/lib32/compat" # 32-bit compatibility shared library search paths -ldconfigsoft_paths="/usr/libsoft /usr/libsoft/compat /usr/local/libsoft" +ldconfigsoft_paths="/usr/local/libsoft /usr/libsoft /usr/libsoft/compat" # soft float compatibility shared library search paths # Note: temporarily with extra stuff for transition -ldconfig_paths_aout="/usr/lib/compat/aout /usr/local/lib/aout" +ldconfig_paths_aout="/usr/local/lib/aout /usr/lib/aout /usr/lib/compat/aout" # a.out shared library search paths ldconfig_local_dirs="/usr/local/libdata/ldconfig" # Local directories with ldconfig configuration files. Index: etc/rc.d/ldconfig =================================================================== --- etc/rc.d/ldconfig (revision 333461) +++ etc/rc.d/ldconfig (working copy) @@ -17,22 +17,23 @@ stop_cmd=":" ldconfig_start() { - local _files _ins + local _files _ins _paths _LDC _ins= ldconfig=${ldconfig_command} checkyesno ldconfig_insecure && _ins="-i" if [ -x "${ldconfig_command}" ]; then - _LDC="/lib /usr/lib" + _paths="" for i in ${ldconfig_local_dirs}; do if [ -d "${i}" ]; then _files=`find ${i} -type f` if [ -n "${_files}" ]; then - ldconfig_paths="${ldconfig_paths} `cat ${_files} | sort -u`" + _paths="${_paths} `cat ${_files} | sort -ru`" fi fi done - for i in ${ldconfig_paths} /etc/ld-elf.so.conf; do + _LDC="" + for i in ${_paths} ${ldconfig_paths} /etc/ld-elf.so.conf; do if [ -r "${i}" ]; then _LDC="${_LDC} ${i}" fi @@ -42,16 +43,17 @@ ldconfig_start() case `sysctl -n hw.machine_arch` in amd64|powerpc64) + _paths="" for i in ${ldconfig_local32_dirs}; do if [ -d "${i}" ]; then _files=`find ${i} -type f` if [ -n "${_files}" ]; then - ldconfig32_paths="${ldconfig32_paths} `cat ${_files} | sort -u`" + _paths="${_paths} `cat ${_files} | sort -ru`" fi fi done _LDC="" - for i in ${ldconfig32_paths}; do + for i in ${_paths} ${ldconfig32_paths}; do if [ -r "${i}" ]; then _LDC="${_LDC} ${i}" fi @@ -64,16 +66,17 @@ ldconfig_start() case `sysctl -n hw.machine_arch` in armv[67]) + _paths="" for i in ${ldconfig_localsoft_dirs}; do if [ -d "${i}" ]; then _files=`find ${i} -type f` if [ -n "${_files}" ]; then - ldconfigsoft_paths="${ldconfigsoft_paths} `cat ${_files} | sort -u`" + _paths="${_paths} `cat ${_files} | sort -ru`" fi fi done _LDC="" - for i in ${ldconfigsoft_paths}; do + for i in ${_paths} ${ldconfigsoft_paths}; do if [ -r "${i}" ]; then _LDC="${_LDC} ${i}" fi @@ -87,10 +90,8 @@ ldconfig_start() # Legacy aout support for i386 only case `sysctl -n hw.machine_arch` in i386) - # Default the a.out ldconfig path. - : ${ldconfig_paths_aout=${ldconfig_paths}} _LDC="" - for i in /usr/lib/aout ${ldconfig_paths_aout} /etc/ld.so.conf; do + for i in ${ldconfig_paths_aout} /etc/ld.so.conf; do if [ -r "${i}" ]; then _LDC="${_LDC} ${i}" fi --MP_/nD2m3FmfImDp2u+ur0Mr4sg-- From owner-freebsd-hackers@freebsd.org Thu May 10 16:47:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68D08FCFEEF; Thu, 10 May 2018 16:47:13 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB8E8472B; Thu, 10 May 2018 16:47:12 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by artemis.db.net (Postfix) with ESMTP id 6619F101BD; Thu, 10 May 2018 16:47:09 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id D298739813; Thu, 10 May 2018 12:47:08 -0400 (EDT) Date: Thu, 10 May 2018 12:47:08 -0400 From: Diane Bruce To: Steve Kargl Cc: Diane Bruce , Gleb Popov <6yearold@gmail.com>, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue Message-ID: <20180510164708.GA76611@night.db.net> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510142452.GA69005@night.db.net> <20180510151522.GA43677@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510151522.GA43677@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:47:13 -0000 On Thu, May 10, 2018 at 08:15:22AM -0700, Steve Kargl wrote: > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > > > sgk@troutmask.apl.washington.edu> wrote: > > > ... > > > > Yep. > > See https://wiki.freebsd.org/libgcc%20problem > > > > Interesting page. I was aware that in the past you tried working > out a solution to the problem. I did not realize you docoumented > the issue. A few corrections to your wiki page. > > 1) The correct spelling of the name of the language is Fortran (with a > capital F). It has been the official standard spelling since Fortran > 90. Fixed > > 2) You have "... to always support quad math (*8) and ...". Quad > precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard). I think I got it right this time... > > 3) "subsitute" is normally spelled with an extra 't'. :-) OOOps ;) fixed > > Very ;) > > Just started reading the source code. Don't scare the unwary. :-) ;) > > -- > Steve Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@freebsd.org Thu May 10 17:22:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1267EFD0DB1; Thu, 10 May 2018 17:22:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A36B36F021; Thu, 10 May 2018 17:22:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AHLxra046778 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 10:21:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AHLxef046777; Thu, 10 May 2018 10:21:59 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 10:21:59 -0700 From: Steve Kargl To: Tijl Coosemans Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510172159.GA46553@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510182151.409b7fb8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510182151.409b7fb8@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:22:01 -0000 On Thu, May 10, 2018 at 06:21:51PM +0200, Tijl Coosemans wrote: > On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl wrote: > > > > So, the runtime loader finds 6 instead of 716, tries to link, > > fails, and issues an error message. There are a number ways to > > fix this issue. > > > > 1) By far, the best solution would be to stop hijacking the libgcc > > name in libraries installed on FreeBSD that are not related to > > actual GCC software. > > > > % ls -l /lib/libgcc* /usr/lib/libgcc* > > (trimming lines) > > /lib/libgcc_s.so.1 > > /usr/lib/libgcc.a@ -> libcompiler_rt.a > > /usr/lib/libgcc_eh.a > > /usr/lib/libgcc_eh_p.a > > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > > aware that clang does not work on all archs and the ancient gcc > > lives on. > > > > 2) Given the expected push back againt solution 1), this solution > > proposes bumping the library version for /lib/libgcc_s.so.1 from > > 1 to some larger value, say, 10. It is unlikely that GCC will > > bump its shared library number anytime soon. GCC bumped it from > > 0 to 1 some 16 years ago. > > > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > > > This solution, however, papers over the general problem with > > name clashes. > > > > libgcc_s.so implements the _Unwind_* API to handle stack unwinding. This > code is shared between all compilers and languages because the stack can > contain frames from different compilers and languages. So, you cannot > change the name or version of the library. Well, yes one could change the name and/or shared library number. All those other tools would then need to be adapted to look for a renamed or number-bumped library. Yes, painful. > I've been testing the attached patch in combination with the ports tree > patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046. > > The patch makes three changes to /etc/rc.d/ldconfig: > 1) Use 'sort -r' so /usr/local/lib/gcc7 appears before /usr/local/lib/gcc6. > 2) Move hardcoded paths like /lib and /usr/lib to /etc/defaults/rc.conf > so the order relative to other paths can be configured. > 3) Change the order of ldconfig_local_dirs and ldconfig_paths so /lib and > /usr/lib appear last. This brings rc.d/ldconfig in line with compilers > and rtld(1) which also search /lib and /usr/lib last. This appears to work around the problem with libgcc_s.so.1. It would be a welcomed solution to so-called "gfortran's FreeBSD issue", but is does not solve the problem with name clashes. It is possible to have two independent libraries for independent projects where no shuffling of order in hints will work. -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 17:38:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14EF4FD17F6 for ; Thu, 10 May 2018 17:38:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88C2171397 for ; Thu, 10 May 2018 17:38:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AHcG5Q046902 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 10:38:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AHcGMC046901; Thu, 10 May 2018 10:38:16 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 10:38:16 -0700 From: Steve Kargl To: Kurt Lidl Cc: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510173816.GB46553@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510142452.GA69005@night.db.net> <20180510151522.GA43677@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:38:19 -0000 On Thu, May 10, 2018 at 11:23:39AM -0400, Kurt Lidl wrote: > On 5/10/18 11:15 AM, Steve Kargl wrote: > > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > >> > >> Agreed, however this has the side effect of meaning conflicts with libraries > >> between clang and gcc libs. Notably gfortran and flang use different > >> conventions for I/O :( > >> > >> See http://people.FreeeBSD.org/~db/fortran_libs.txt > > > > Page doesn't appear to exist? If I go to > > > > https://people.freebsd.org/homepage.html > > > > you're not listed. > > There's one too many "e" characters in the given URI. > > Correct URI: http://people.FreeBSD.org/~db/fortran_libs.txt > Ah, thanks! I simply copy-n-pasted the link, then went to the homepage.html via a bookmark. The incompatibility in IO runtimes between gfortran and flang is a minor issue for anyone using actual modern Fortran, and in particular, Fortran's MODULE feature. % cat m.f90 module foo implicit none real :: pi = 3.14 contains function real_pi() result(p) real p p = atan(1.) end function real_pi end module foo % gfortran6 -c m.f90 % nm m.o 0000000000000000 D __foo_MOD_pi 0000000000000000 T __foo_MOD_real_pi % file foo.mod foo.mod: gzip compressed data, from Unix % flang -c m.f90 % nm m.o 0000000000000000 r .C288_foo_real_pi_ 0000000000000000 r .LCPI1_0 0000000000000000 D _foo_8_ 0000000000000000 T foo_ 0000000000000010 T foo_real_pi_ % file foo.mod foo.mod: ASCII text foo.mod can be thought of as a pre-compile header. It will encode the named constant pi and a signature for the function real_pi. The object files contain name-mangled entry points for the function. The Fortran Standard(s) do not specify implementation detail, so there is an incompatibility between not only gfortran and flang, but all Fortran compiler vendors. -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 19:05:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC76EFD3A04 for ; Thu, 10 May 2018 19:05:59 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67ABE841F4 for ; Thu, 10 May 2018 19:05:58 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.197.147 Received: from britannica.bec.de (p5799C593.dip0.t-ipconnect.de [87.153.197.147]) (Authenticated sender: joerg@bec.de) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 11F0F1C0006 for ; Thu, 10 May 2018 21:05:53 +0200 (CEST) Date: Thu, 10 May 2018 21:05:49 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510190549.GB14916@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20180509234551.GA39526@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180509234551.GA39526@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Level: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 19:06:00 -0000 On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". I don't get why you are blaming the FreeBSD loader. In fact, this is a pretty common issue and the fault is and has always been that the GCC ecosystem is extremely bad about mixing different GCC versions in the runtime environment. It tends to somewhat work as long as you make sure that the main binary is using the newest GCC version, but it can still fail even then. Joerg From owner-freebsd-hackers@freebsd.org Thu May 10 19:22:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74164FD417D; Thu, 10 May 2018 19:22:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD63B878A3; Thu, 10 May 2018 19:22:56 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w4AJDiPB064759 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 21:13:44 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w4AJDdFm064756; Thu, 10 May 2018 21:13:39 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 10 May 2018 21:13:39 +0200 (CEST) From: Wojciech Puchar To: Gleb Popov <6yearold@gmail.com> cc: sgk@troutmask.apl.washington.edu, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue In-Reply-To: Message-ID: References: <20180509234551.GA39526@troutmask.apl.washington.edu> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 19:22:57 -0000 just another - out of thousands - example that shared libraries are one of the worst thing invented in computing. Maybe except of single system wide shared library with constant interface. On Thu, 10 May 2018, Gleb Popov wrote: > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > >> In review PR 228007, it came to my attention some individuals are >> mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD >> issue". See >> >> https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html >> >> The problem can be summarized by the following >> >> % gfortran7 -o z h.f90 >> % ./z >> /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ >> /usr/local/lib/gcc7/libgfortran.so.4 not found >> >> gfortran7 is installed from ports/lang/gcc7. This is not >> a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. >> >> Specifically, there is a shared library name clash. >> >> % ldconfig -r | grep gcc_ >> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >> 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 >> >> % ldd z >> z: >> libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) >> libm.so.5 => /lib/libm.so.5 (0x200a17000) >> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) >> libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) >> libc.so.7 => /lib/libc.so.7 (0x200ca3000) >> >> So, the runtime loader finds 6 instead of 716, tries to link, >> fails, and issues an error message. There are a number ways to >> fix this issue. >> >> 1) By far, the best solution would be to stop hijacking the libgcc >> name in libraries installed on FreeBSD that are not related to >> actual GCC software. >> >> % ls -l /lib/libgcc* /usr/lib/libgcc* >> (trimming lines) >> /lib/libgcc_s.so.1 >> /usr/lib/libgcc.a@ -> libcompiler_rt.a >> /usr/lib/libgcc_eh.a >> /usr/lib/libgcc_eh_p.a >> /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a >> /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 >> >> Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm >> aware that clang does not work on all archs and the ancient gcc >> lives on. >> >> 2) Given the expected push back againt solution 1), this solution >> proposes bumping the library version for /lib/libgcc_s.so.1 from >> 1 to some larger value, say, 10. It is unlikely that GCC will >> bump its shared library number anytime soon. GCC bumped it from >> 0 to 1 some 16 years ago. >> >> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 >> >> This solution, however, papers over the general problem with >> name clashes. >> >> 3) This solution is to actually fix the runtime loader. If an error >> occurs with loading a shared library, then iterate over the entries >> in the hints file to check to see if another hint would satisfy >> the linking. Here, instead of issuing the above error, the loader >> would find entry 716, and load the correct libgcc_s.so.1. >> >> Admittedly, I haven't looked to see how difficult this solution >> would be. >> >> 4) Bump the shared library number of the individual ports. As a proof >> of concept, I've done this with ports/lang/gcc6. >> >> % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc >> --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 >> +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 >> @@ -20,7 +20,7 @@ >> >> SHLIB_EXT = .so >> SHLIB_SOLINK = @shlib_base_name@.so >> -SHLIB_SOVERSION = 1 >> +SHLIB_SOVERSION = 2 >> SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) >> SHLIB_MAP = @shlib_map_file@ >> SHLIB_OBJS = @shlib_objs@ >> >> % ldconfig -r | grep gcc_ >> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >> 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 >> 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 >> >> % gfortran6 -o z h.f90 >> % ./z >> hello >> % ldd z >> z: >> libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) >> libm.so.5 => /lib/libm.so.5 (0x20096c000) >> libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) >> libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) >> libc.so.7 => /lib/libc.so.7 (0x200df7000) >> >> This works for this particular name conflict. Hopefully, FreeBSD >> never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, >> however, introduces an incompatibility with what is actually distributed >> by GCC. >> >> Finally, can people stop referring to the above error as >> "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. >> > > Our libgcc also lacks some functionality compared to the original one: > https://reviews.freebsd.org/D11482 > > >> -- >> Steve >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Thu May 10 19:48:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A59ABFD4C12 for ; Thu, 10 May 2018 19:48:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AE8F6D423 for ; Thu, 10 May 2018 19:48:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AJmNil095994 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 May 2018 12:48:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AJmNcB095993 for freebsd-hackers@freebsd.org; Thu, 10 May 2018 12:48:23 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 12:48:23 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510194823.GA60567@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510190549.GB14916@britannica.bec.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 19:48:25 -0000 On Thu, May 10, 2018 at 09:05:49PM +0200, Joerg Sonnenberger wrote: > On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > > In review PR 228007, it came to my attention some individuals are > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > issue". > > I don't get why you are blaming the FreeBSD loader. In fact, this is a > pretty common issue and the fault is and has always been that the GCC > ecosystem is extremely bad about mixing different GCC versions in the > runtime environment. It tends to somewhat work as long as you make sure > that the main binary is using the newest GCC version, but it can still > fail even then. > It is a runtime loader issue in that the loader cannot not deal with a name clash. Suppose project Ajax has libfoo.so.1 and project Nub has libfoo.so.1. You install Ajax first, ldconfig will find 42:-lfoo.1 => /usr/local/lib/ajax/libfoo.so.1 while project Nub's libfoo.so.1 is 666:-lfoo.1 => /usr/local/lib/nub/libfoo.so.1 You build your Nub project bar and go to execute bar where upon the runtime loader finds 42 instead of 666. Tijl's suggested fix of re-ordering the list of hints so gcc7's libgcc_s.so.1 is found before /lib/libgcc_s.so.1 works around the issue of executables compiled by gfortran7 getting the correct libgcc_s.so.1. It does not solve the above problem, because once re-ordered, anything compiled by the ajax project finds the wrong libfoo.so.1 library. As to your comment "the fault is and has always been that the GCC ecosystem is extremely bad about mixing different GCC version". libgcc_s.so.1 is a symbol versioned shared library. As long as the ABI of symbols are not changed, one can add new symbols without bumping the library version number. GCC has added symbols to libgcc_s.so.1 since gcc 4.2.1, and FreeBSD has not stayed in-sync. If you want to get snarky about different projects, don't you think that "the fault is and has always been that the FreeBSD ecosystem" (mis)appropriated the name libgcc when clang came into the tree [1] because clang didn't have a runtime library [2] and it was expedient to simply use libgcc_s.so.1. [1] llvm+clang Added Tue Jun 2 17:58:47 2009 UTC (8 years, 11 months ago) by ed https://svnweb.freebsd.org/base?view=revision&revision=193326 [2] compiler-rt. Added Thu Oct 21 19:02:02 2010 UTC (7 years, 6 months ago) by ed https://svnweb.freebsd.org/base?view=revision&revision=214152 -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 20:22:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61070FD5CD7 for ; Thu, 10 May 2018 20:22:39 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E159E763D1 for ; Thu, 10 May 2018 20:22:38 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.197.147 Received: from britannica.bec.de (p5799C593.dip0.t-ipconnect.de [87.153.197.147]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E6ACFE0007; Thu, 10 May 2018 22:22:30 +0200 (CEST) Date: Thu, 10 May 2018 22:22:27 +0200 From: Joerg Sonnenberger To: Steve Kargl Cc: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510202227.GA6592@britannica.bec.de> Mail-Followup-To: Steve Kargl , freebsd-hackers@freebsd.org References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510194823.GA60567@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Level: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 20:22:39 -0000 On Thu, May 10, 2018 at 12:48:23PM -0700, Steve Kargl wrote: > On Thu, May 10, 2018 at 09:05:49PM +0200, Joerg Sonnenberger wrote: > > On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > > > In review PR 228007, it came to my attention some individuals are > > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > > issue". > > > > I don't get why you are blaming the FreeBSD loader. In fact, this is a > > pretty common issue and the fault is and has always been that the GCC > > ecosystem is extremely bad about mixing different GCC versions in the > > runtime environment. It tends to somewhat work as long as you make sure > > that the main binary is using the newest GCC version, but it can still > > fail even then. > > > > It is a runtime loader issue in that the loader cannot not > deal with a name clash. It is not supposed to. The soname identifies the object. If you end up with multiple different objects with the same soname, it is your fault. It's not something the loader can magically fix. > Tijl's suggested fix of re-ordering the list of hints so > gcc7's libgcc_s.so.1 is found before /lib/libgcc_s.so.1 > works around the issue of executables compiled by gfortran7 > getting the correct libgcc_s.so.1. It doesn't solve the problem because it assumes that gfortran7's libgcc_so.so.1 is a superset of /lib/libgcc_s.so.1. This is a very popular assumption in GCCland and it turns out to be false surprisingly often. > As to your comment "the fault is and has always been that > the GCC ecosystem is extremely bad about mixing different > GCC version". libgcc_s.so.1 is a symbol versioned shared > library. As long as the ABI of symbols are not changed, > one can add new symbols without bumping the library version > number. GCC has added symbols to libgcc_s.so.1 since gcc > 4.2.1, and FreeBSD has not stayed in-sync. This is missing the point. GCC assumes that it always gets its own version of libgcc_s.so, because of course you are always going to compile things with the newest GCC in your system. Ironically, symbol versioning makes this situation *worse*, because symbol lookup no longer falls through consistently. > If you want to get snarky about different projects, don't > you think that "the fault is and has always been that the > FreeBSD ecosystem" (mis)appropriated the name libgcc when > clang came into the tree [1] because clang didn't have a > runtime library [2] and it was expedient to simply use > libgcc_s.so.1. Again, you are missing that the situation would happen just the same if the base compiler is GCC 4.2.1 and not Clang. Joerg From owner-freebsd-hackers@freebsd.org Thu May 10 20:25:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB4A3FD5FC0 for ; Thu, 10 May 2018 20:25:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6885176741 for ; Thu, 10 May 2018 20:25:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AKPahj074253 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 May 2018 13:25:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AKPaiO074252 for freebsd-hackers@freebsd.org; Thu, 10 May 2018 13:25:36 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 13:25:36 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510202536.GA74173@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> <20180510202227.GA6592@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510202227.GA6592@britannica.bec.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 20:25:38 -0000 On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote: > > Again, you are missing that the situation would happen just the same if > the base compiler is GCC 4.2.1 and not Clang. > FreeBSD could have stayed in-step with the times. -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 21:02:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 399F3FD70EB for ; Thu, 10 May 2018 21:02:08 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B899A7F4F7 for ; Thu, 10 May 2018 21:02:07 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p5799C593.dip0.t-ipconnect.de [87.153.197.147]) (Authenticated sender: joerg@bec.de) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 400A720000F for ; Thu, 10 May 2018 23:02:00 +0200 (CEST) Date: Thu, 10 May 2018 23:01:57 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510210157.GA17726@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> <20180510202227.GA6592@britannica.bec.de> <20180510202536.GA74173@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510202536.GA74173@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Level: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:02:08 -0000 On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote: > On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote: > > > > Again, you are missing that the situation would happen just the same if > > the base compiler is GCC 4.2.1 and not Clang. > > > > FreeBSD could have stayed in-step with the times. FreeBSD or any other system could be updated the GCC version for every release and there would still appear a newer GCC version that requires an even newer libgcc_s.so in the release life time. Heck, the very same problem happens in the other direction as well, i.e. if you are forced to use an *older* GCC and pick up its libgcc_s.so. Joerg From owner-freebsd-hackers@freebsd.org Thu May 10 22:09:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05D6FFD87DD for ; Thu, 10 May 2018 22:09:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A156DB07 for ; Thu, 10 May 2018 22:09:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AM9nl2075802 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 May 2018 15:09:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AM9nBR075801 for freebsd-hackers@freebsd.org; Thu, 10 May 2018 15:09:49 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 15:09:49 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510220949.GA74424@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> <20180510202227.GA6592@britannica.bec.de> <20180510202536.GA74173@troutmask.apl.washington.edu> <20180510210157.GA17726@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510210157.GA17726@britannica.bec.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 22:09:52 -0000 On Thu, May 10, 2018 at 11:01:57PM +0200, Joerg Sonnenberger wrote: > On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote: > > On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote: > > > > > > Again, you are missing that the situation would happen just the same if > > > the base compiler is GCC 4.2.1 and not Clang. > > > > > > > FreeBSD could have stayed in-step with the times. > > FreeBSD or any other system could be updated the GCC version for every > release and there would still appear a newer GCC version that requires > an even newer libgcc_s.so in the release life time. Heck, the very same > problem happens in the other direction as well, i.e. if you are forced > to use an *older* GCC and pick up its libgcc_s.so. > If, as you assert, FreeBSD's runtime loader isn't meant to deal with name clashes, then why does ldconfig place conflicting names into the list of hints? % ldconfig -r | grep libgcc_s 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 Shouldn't ldconfig refuse to add 716 and complain bitterly to the user to fix the conflict? Shouldn't the documentation that comes with FreeBSD explain that conflicting names are disallowed. In looking at an objdump of lib/gcc7/libgfortran.so.4, one finds Dynamic Section: NEEDED libquadmath.so.0 NEEDED libm.so.5 NEEDED libgcc_s.so.1 NEEDED libc.so.7 SONAME libgfortran.so.4 RPATH /usr/local/lib/gcc7 Why isn't the runtime loader looking in RPATH for the libraries and then falling back to looking in the list of hints. I find your arguments to be somewhat diminished by the fact FreeBSD re-uses a filename from a well-known and (much) older software project, and somehow its the other project's fault for the problem with a name clash. -- Steve From owner-freebsd-hackers@freebsd.org Thu May 10 23:36:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DBADFDAF0C; Thu, 10 May 2018 23:36:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 232C482F73; Thu, 10 May 2018 23:36:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4ANapgG055326 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 16:36:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4ANap8V055325; Thu, 10 May 2018 16:36:51 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 16:36:51 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510233651.GA54955@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180509234551.GA39526@troutmask.apl.washington.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 23:36:53 -0000 On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See It seems we've had the same discussion 2 years ago. My time flies. ttps://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104384.html -- Steve From owner-freebsd-hackers@freebsd.org Fri May 11 02:04:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A4F2FAFDF3; Fri, 11 May 2018 02:04:38 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 994368703E; Fri, 11 May 2018 02:04:37 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-it0-x242.google.com with SMTP id n202-v6so371264ita.1; Thu, 10 May 2018 19:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/uJFpaEp2Oq1CBUINjp9tKROg/rZgE1i304fj5C5rtI=; b=Jj6WsTot233bJglP7FtA6mmkksUg9yX994QUvA6nFFPHN/TLlRkEm7R1oj9xPCW3BF P3aQdu52NTnoqIKQ717K535+iKQb3QrGup3qsUsdJ2zesdz5dueIeNfTuiJMU9Tavzb5 YuFOxFrrM1cFv97CyQiNj9P5vRkcS2tT91zLzo045w7ULlL9KhW6/RQKr6sjAiGxAgNm Sppj8etJKxfcbM2y5Lyt3oADUe17UaOF7OvdrgTZIK9as1qE22fgRdMD021gwzCaKNWu cJNVvZaBgXBPhvI549Vxa2KwP49XWiQ7VYHmPtz8bensdtPURIdH6hJSbsXzTy3AVWfe Lseg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/uJFpaEp2Oq1CBUINjp9tKROg/rZgE1i304fj5C5rtI=; b=O+oGqSLNoEkIxXc3tQw9w27jCiSeHbkqsULU95Bz08aj/lUKhdYrAHeOWeBM1n9BUw wYWSJQxSuLSpos0MNTZ7ywDiHIsPOKyKhGqgYdoDRLJfIHtkltMkGKJBkNldVTyx5jbM Hs4iVnhYg3YbZCf3gMq8cKH8sGmYZgOfRRtdb9l/MQTZxQH43SC6Q8fd/iJoTZyvnszC e+TvsrxlwT3ymYo9KJhYl0yztl47yp2RH+9Lx9UXG7fZizcJva36Oe31or3NQyaBn5dH W+WpDPkrKIhzrArp3YJmAMMonHcPzzXt041YKUppOoJGvG5gB72lXFHsv80dF47rFgwz GSfQ== X-Gm-Message-State: ALKqPweBZYG2/zVXfYRc2FyQzM5WQUsdEE8c9BtASaGiaJePDfuComxC lKfZi1Ek8QfjJvBzAEtEclWt3iYk84nBscPSdyc= X-Google-Smtp-Source: AB8JxZqZM3Xv5cazBaCVh2DJ81oWObgqLxZ+rm51z6rqmvSqHxL/U1kFdB27kB8mCk5e/xiL3VhZyyMr2ucnKzzNHIw= X-Received: by 2002:a24:4c55:: with SMTP id a82-v6mr1336086itb.1.1526004277018; Thu, 10 May 2018 19:04:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.132.228 with HTTP; Thu, 10 May 2018 19:04:36 -0700 (PDT) From: Dieter BSD Date: Thu, 10 May 2018 19:04:36 -0700 Message-ID: Subject: PCIe multipliers, how do they work? To: freebsd-hardware@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 02:04:38 -0000 Looking into ways to get additional expansion slots, since board designers cannot count past 7 and often not even that high. :-( There are PCIe riser cards that split a wide slot into 2 or more narrower slots, for example 1 x8 slot becomes 2 x4 slots. These would be very useful, except it appears that they require "bifurcation" support in the mainboard's firmware. Which most boards do not provide. And most boards are not supported by FLOSS firmware, so adding bifurcation support would be rather difficult. There are also PCIe cards which provide multiple slots, typically connected with a usb cable. These tend to convert 1 PCIe_x1 slot into multiple PCIe_x1 slots. I get the impression that these do not require bifurcation support. They seem to be aimed at "miners" for attaching multiple gpu cards. I'm not interested in mining or in attaching multiple gpu cards. I'm interesting in adding additional sata cards, Ethernet cards, and such. Unlike the bifurcation type riser splitter cards, which seem to conserve PCIe lanes, these are more like a sata port multiplier, with the same type of bandwidth limitation. I'm wondering how these things work. The wikipedia PCIe page [1] says: "PCI Express switches can create multiple endpoints out of one endpoint to allow sharing one endpoint with multiple devices." So maybe they use a PCIe switch? Poking around wikipedia and google has thus far uncovered very little info about PCIe switches. Wikipedia is less helpful than usual, and they keep making google less and less useful for no apparent reason. I don't see any other obvious keywords to google for. It isn't obvious how slot id/address is handled. How do commands and data get routed to/from the correct card? Is any firmware or OS support required? Is there some other solution that I haven't stumbled across? I'd really like to split an x8 slot into 4 x2 slots, which doesn't seem to be an off-the-shelf option either way. [1] en.wikipedia.org/wiki/PCI_Express From owner-freebsd-hackers@freebsd.org Fri May 11 06:04:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8074FB873A for ; Fri, 11 May 2018 06:04:51 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 638D87C34D for ; Fri, 11 May 2018 06:04:51 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id p12-v6so2202374pff.13 for ; Thu, 10 May 2018 23:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:message-id:subject :in-reply-to:references:to; bh=+aoQRmj22lRw2pvJI41bNEHZRG3WxEsDK8nmBG0oRkk=; b=NqeHrKs2Ko5WSubKipLX+o5GIDRPYhsqzUpvItofWDiW0qxz50O/uYPjB3bGEPz+Ah EAa+H0Sv6GeGyHCt4ufyHW3IQ2H4100kZFo03Bm6f+YZiNNyNa0Aa5pdezc6YgrnDFkm LUXai2aGKtmaR4n0ogwvctgilFV7AuAJkwhpW6VzF8QrCcidaBxKqoA5OycJVmGj+WOC fONsSlAyyslokpLkrBlkRj5xaBKIe7s1YABapC5n0l2IaD5RlrXuv8ANuWTcBk4fiqo6 pP7hTGwzpHrFC/8JK3OWzROZZuz6c92fp6iC6N2lML7Mshd6uQ1u36YNc1WezoHm43Yb ZE1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:in-reply-to:references:to; bh=+aoQRmj22lRw2pvJI41bNEHZRG3WxEsDK8nmBG0oRkk=; b=mXwxrFiDSbbD4q1GVJq3isxyDlTaHs1VsgPF/SdALgDLsIXGyfpVlIlJAVomkG06Mg p1NUomOssoL/2ptQ7ODXqT0wdrq3gVFPpF9FDkOYNIZh5tQ2zKmG1udZ/pAL5e4g7N+w uJN1X3N2eVPc9HZhAtGRT8s8c5Eo+VJ2jaqjdb/3H2UIB6pgfVjZ+BCwGYlExEF6axIb 6sf5dDoR+TEFQInPBFURq+pC6SuPFbIxAlKbYvBJanIqvC9xpRT3UnqdoGKmWbt+y06U DjvRYtZn2HoZ9O5Lra7xQPgQrNUW0yh4tghdSZvoAONMaBjFTIMq4aycL/ubl45IagJb ccJw== X-Gm-Message-State: ALKqPwdwigjvvPycbv9pyTKlxW6v1s7jvWoJOxv9JqNGEFwHrteN/3C6 e41DstBVmWshe05eMkLF5ZYHYQqk X-Google-Smtp-Source: AB8JxZqMd9VjRH0JlmGcFpy5SyBz54UtS6Q6Fdn1MJOBC2/dzAh946paHznoS3JUPgIXxMxYYO6H8A== X-Received: by 2002:a63:8ac4:: with SMTP id y187-v6mr3387086pgd.64.1526018690069; Thu, 10 May 2018 23:04:50 -0700 (PDT) Received: from ?IPv6:2601:602:9701:71cb:3972:c74e:759c:7871? ([2601:602:9701:71cb:3972:c74e:759c:7871]) by smtp.gmail.com with ESMTPSA id a23-v6sm4214689pfi.176.2018.05.10.23.04.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 23:04:49 -0700 (PDT) From: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= Mime-Version: 1.0 (1.0) Date: Thu, 10 May 2018 23:04:48 -0700 Message-Id: <73A0769A-AAE0-4B23-83CA-206FA7EF0B5E@gmail.com> Subject: Re: Runtime loader issue In-Reply-To: <20180510210157.GA17726@britannica.bec.de> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu> <20180510202227.GA6592@britannica.bec.de> <20180510202536.GA74173@troutmask.apl.washington.edu> <20180510210157.GA17726@britannica.bec.de> To: freebsd-hackers@freebsd.org X-Mailer: iPhone Mail (15E302) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 06:04:52 -0000 > On May 10, 2018, at 2:01 PM, Joerg Sonnenberger wrote: >=20 >> On Thu, May 10, 2018 at 01:25:36PM -0700, Steve Kargl wrote: >>> On Thu, May 10, 2018 at 10:22:27PM +0200, Joerg Sonnenberger wrote: >>>=20 >>> Again, you are missing that the situation would happen just the same if >>> the base compiler is GCC 4.2.1 and not Clang.=20 >>=20 >> FreeBSD could have stayed in-step with the times. >=20 > FreeBSD or any other system could be updated the GCC version for every > release and there would still appear a newer GCC version that requires > an even newer libgcc_s.so in the release life time. Heck, the very same > problem happens in the other direction as well, i.e. if you are forced > to use an *older* GCC and pick up its libgcc_s.so. Hi. This libgcc issue is a little recurrent here in FreeBSD. I remember other em= ail threads talking about it. The summary I remember is that we must go the w= ay Linux does it, I think. It was thoroughly explained in past threads. As GCC was/is omnipresent in Unix like systems most of the other projects ha= ve standard ways to use the libgcc. I used to think in new libgcc as a drop i= n replacement for older ones. I know this is a bit simplistic. I remember Li= nux usually uses just one libgcc at a time, too. This is the winning answer u= sually here, too. In fact I remember that new libgcc versions triggers syste= ms recompilations for safety reasons. The use of libgcc in FreeBSD makes the procedure unusually complex many time= s here. It's a source of many problems. This one is one more to add to the l= ist. This just occurred to me now. Please, keep in mind that the case here i= s caused by the odd use given to this library here. Lc --=20 rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@gmail.com =F0=9F=93=A7 rollin= gbits@terra.com.br =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbi= ts@globo.com =F0=9F=93=A7 rollingbits@icloud.com From owner-freebsd-hackers@freebsd.org Fri May 11 19:03:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDC99FC66F5; Fri, 11 May 2018 19:03:30 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 629CF75840; Fri, 11 May 2018 19:03:30 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w4BJ3a1M049989 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 May 2018 21:03:36 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w4BJ3VUC049986; Fri, 11 May 2018 21:03:31 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 11 May 2018 21:03:31 +0200 (CEST) From: Wojciech Puchar To: Dieter BSD cc: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PCIe multipliers, how do they work? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 19:03:31 -0000 > There are also PCIe cards which provide multiple slots, typically > connected with a usb cable. These tend to convert 1 PCIe_x1 slot > into multiple PCIe_x1 slots. I get the impression that these do > not require bifurcation support. They seem to be aimed at "miners" these cards consist of PCIe switch which is supported out of the box. former ones require BIOS to reconfigure CPUs PCI lanes so instead of eg one 16x lane there will be 4 4x lanes. From owner-freebsd-hackers@freebsd.org Fri May 11 20:11:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CBDDFC9F5C for ; Fri, 11 May 2018 20:11:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 845B2842DE for ; Fri, 11 May 2018 20:11:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id d11-v6so8355708iof.11 for ; Fri, 11 May 2018 13:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=U8no60hfNY+daL4DSJBxkV3lr8BfXzTHbm4NBjiMHkk=; b=uE3cWzegEDj6jiuI9FQP0ehglCtTFb1vWxfXRKdhMEJ/AszI5cR/SNV63RzYQaHXNH wL+H+Smlo22f2O2LvDbhqNsGPX7Y22b/4w6eVBJz+yQ7P+pIs0+TxsJi+Exk7zFgxh9Z vYPqKdTDd5ASGKjM1RHPJMtzu0tW9x3WxiuQvfvuHkISed9X06lwuRIPOUBSk2b+uDP5 a4q0h4VbPNRtbR/Rq+iPtvNxf8REA7MM7AEqhz+nuQgRWGWldmPlz0upx+URkUvzRwKi sTIfwxHuKLGSg+XLkqMkIWQSJ+/Mm1eKEUJ2g/IvQ3zFb/E1VNyqOcAI3v04nrztaEZp PzkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=U8no60hfNY+daL4DSJBxkV3lr8BfXzTHbm4NBjiMHkk=; b=TtWFvghaWMIcaZ3MFu9HKmylK3a+EUUVvEgCeqi6uHukBbKIXKIUJoOUmuRPTipAyD EnHNbasZp2V+cLTRmcYOSdKUfHsekptHNT2yZZwiusrowTW8wMq/lZ+alCVkqYBJk5+d /PRuUem9qemCRmdkVH44Vu1hNaBykBD9jVrJcT/GGsI59WKGMIUkrO2FC2kCKAkovI7E ny9mJ8853nUrDd12drNExddGdIoNuBABqNVdVN1Kmk/NVOyBRV/iuK94Ceox5HUsdjH8 vXE3pb/UNbo0NLYPZ6acfYCPsP/UsY57jjtQm0cC3oLPX0DLEZgZo42+jQH/D2jRyL2b P2+Q== X-Gm-Message-State: ALKqPwcLS+4K/1qKMo1640VXXZQ046Xz7r/+kX1LXG/otrS5xsNRx6+D +J60Kv41/VvzhtnVQ8ssOuALucRC/3w0YFHh8naAvA== X-Google-Smtp-Source: AB8JxZrjYzQ1dKVAHx3CmIUGhHF2zKnKwgpkUk8xeWTDL49/11hsK9J7vA1npMM6Xo9N9ykpJcC2UZ168bmbZSSkEh8= X-Received: by 2002:a6b:12a3:: with SMTP id 35-v6mr7424683ios.168.1526069482761; Fri, 11 May 2018 13:11:22 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a649:0:0:0:0:0 with HTTP; Fri, 11 May 2018 13:11:22 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Fri, 11 May 2018 14:11:22 -0600 X-Google-Sender-Auth: SIwOxazy3NP0l9wFHuzCOWHBDvU Message-ID: Subject: Re: PCIe multipliers, how do they work? To: Wojciech Puchar Cc: Dieter BSD , "freebsd-hackers@freebsd.org" , freebsd-hardware@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 20:11:24 -0000 On Fri, May 11, 2018 at 1:03 PM, Wojciech Puchar wrote: > There are also PCIe cards which provide multiple slots, typically >> connected with a usb cable. These tend to convert 1 PCIe_x1 slot >> into multiple PCIe_x1 slots. I get the impression that these do >> not require bifurcation support. They seem to be aimed at "miners" >> > > these cards consist of PCIe switch which is supported out of the box. > former ones require BIOS to reconfigure CPUs PCI lanes so instead of eg > one 16x lane there will be 4 4x lanes. > Usually they require a driver for management functions, like if you want to turn off one of the ports (because you know there's a bad card in it, for example). But for normal probe / attach they are usually drop in. Some mobos can require some BIOS adjustment, though to properly setup lane bifurcation and such... The ones that are true switches, and not just signal retimers, usually don't: they take the full 8 or 16 lanes and multiplex it amongst the 16-32 downstream lanes they typically provide. We're looking at one that does x4 lanes and expands to 4 cards at x4 lanes. The devices on the other side fill just over a lane each, but we'd run out of lanes if we did x2 fan-out. This the cards we're looking at, we can get x4 combined rates form the 4 cards that on their own are kinda crappy. Warner