From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id BAC2D3858D20 for ; Mon, 7 Feb 2022 11:48:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAC2D3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644234517; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=7pMXx3qyaoTtonNC2gTmzaQlKZKBC/A5W2BnBqLMBwI=; b=S2k7fmWHA2XUqeuNc9Y1jZkO3OPeP0XWBhpwil4qURygtI+N6CoXcRHE0LayyH7oHGrlyi eBzWovml5gWRfjj7HXeewnddKuo8RwIn+ITB3cj0Bb3gFrxAbOZoqwAFsGXK80/X+em1Fy /YcuOtgLAwa27xlncL5EX6TJiCfBmi0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-148-c6Dn_xfeOSizWqIy3DbVFQ-1; Mon, 07 Feb 2022 06:48:31 -0500 X-MC-Unique: c6Dn_xfeOSizWqIy3DbVFQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ED1FB8143EA for ; Mon, 7 Feb 2022 11:48:30 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-112-15.ams2.redhat.com [10.36.112.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD0DD1057F62; Mon, 7 Feb 2022 11:48:13 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id C3533A80D2F; Mon, 7 Feb 2022 12:48:11 +0100 (CET) Date: Mon, 7 Feb 2022 12:48:11 +0100 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: can i delete libtool / shared library support ? Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org, Jeff Johnston References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 11:48:39 -0000 I was never involved in this part of the project, so I can't say if there's any value in it. Jeff? On Feb 7 04:27, Mike Frysinger wrote: > let's talk about the shared library support in newlib. i want to delete it. > > it was added in 2001. the commit doesn't have any info itself, and i can't > find it in the mailing list archives to try and explain "why". > https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=2e1a71756e754ada402efe9f5e2d6378dc11e496 > > the README has a section on it, but only explains "how", not "why". and that > leads me to a large limitation in the code: it only works when built for a > target that already uses glibc, and only 32-bit x86. i.e. it will produce a > shared libc.so & libm.so, but it doesn't provide its own ld.so, and it will > still be loaded & run in an environment that otherwise is assuming glibc is > used. e.g. when you configure gcc, you tell it you're targeting glibc, and > it bakes assumptions about certain functions & behaviors into it as a result. > > i'll note that the configure.host logic is weird in its tuple selection. it > requires the "vendor" field be set to "pc" even though it's meaningless, and > it seems to accept any C library (i?86-pc-linux-*), but in reality, it only > works with glibc (i.e. *-gnu). > > back in 2016, Jeff noted that he didn't think anyone used it, and that even > then the code had rotted into a state that made it unusable (i.e. does not > compile let alone link). this is because it mixes glibc headers with newlib > headers, and that glibc had made incompatible changes to its internals. and > that newlib depends on those internal behaviors. > https://sourceware.org/legacy-ml/newlib/2016/msg01106.html > > i've taken a 32-bit x86 system and tried to compile newlib, and indeed it > blows up pretty immediately when it starts to mix newlib & glibc headers. > > i'm fairly certain that getting it working again won't be that easy since the > current newlib imported code is based on linuxthreads which was removed from > glibc 2.4 which was released in 2006, and had already been deprecated for a > while by that point. the replacement, NPTL, is drastically different. > > in my autotools build cleanup, keeping this libtool logic has been kind of a > pita to try and make sure i don't break it. but on the otherhand, it's been > broken for at least 5 years (and most likely even longer), no one is using it, > and it's impossible for me to test. if no one is using it, and no one seems > to be asking for it, and actually getting it working again will take a huge > amount of effort, can i just delete all the complicated logic and be done ? > if someone shows up years from now and wants to get it working, i don't think > it will be that much harder. > -mike