From owner-freebsd-ports@freebsd.org Fri Feb 22 15:57:03 2019 Return-Path: Delivered-To: freebsd-ports@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 6D77514F1227 for ; Fri, 22 Feb 2019 15:57:03 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E6B372AA6; Fri, 22 Feb 2019 15:57:01 +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 x1MFuuTj032957 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Feb 2019 07:56:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1MFusju032956; Fri, 22 Feb 2019 07:56:54 -0800 (PST) (envelope-from sgk) Date: Fri, 22 Feb 2019 07:56:54 -0800 From: Steve Kargl To: Ed Maste Cc: Diane Bruce , =?utf-8?Q?T=C4=B3l?= Coosemans , FreeBSD Ports ML , Eugene Grosbein Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222155654.GA32886@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <20190221183040.GA42303@night.db.net> <20190221214646.GA86448@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.11.2 (2019-01-07) X-Rspamd-Queue-Id: 9E6B372AA6 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.56 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.86)[0.864,0]; NEURAL_SPAM_MEDIUM(0.75)[0.745,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_LONG(0.20)[0.197,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.06)[ip: (0.12), ipnet: 128.95.0.0/16(0.18), asn: 73(0.09), country: US(-0.07)] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:57:03 -0000 On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote: > On Thu, 21 Feb 2019 at 16:47, Steve Kargl > wrote: > > > > The missing symbols are > > > > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort > > Thank you for collecting these. > > > It looks like we may be able to grab some of these from libc/softfloat: > > getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c. > > > > It looks like we might be able to grab a few more from NetBSD: > > eqtf2.c and unordtf2.c > > All seven of these are available in compiler-rt, I believe they just > need to be built and added to the version map. > > That leaves: __addtf3 __divtf3 __floatditf __floatsitf __floatunditf > __multf3 __subtf3 > > compiler-rt also has these, but provided only in this case: > #if defined(CRT_HAS_128BIT) && defined(CRT_LDBL_128BIT) gfortran provides a REAL(16) type, which is an implementation of IEEE 754 binary128. If the architecture has a 128-bit float type such as sparc64, there isn't a problem. If the 128-bit is available from the architecture such as i386, then it uses GCC __float128 software implementation. If compiler-rt has these functions, are they compatiable with GCC's __float128. -- Steve