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.129.124]) by sourceware.org (Postfix) with ESMTPS id A67223858C27 for ; Mon, 7 Feb 2022 19:31:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A67223858C27 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=1644262265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B2QJ0grRTXaRol3CbmA+sjLXzwOWyh2nvM2VzI/qA8c=; b=NFaFLi7NMTvjs4M4UVWbnnupEiAJJ59SXXLFGsnMSr6dHJ52LSRNziNIxDTdu+8s4VrLK1 gs4e1uGK+qHNq/gt5hcUKf6bja6MVda7lUI1qB2wJCq9NTlj5TStRbP3ynWQcMrOKeot65 yvNN2FxsQw3RX/xGKSx7Q4RXVGCEYr8= Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-519-Jn_Fm4AcOZmZMCNsAaD4mw-1; Mon, 07 Feb 2022 14:31:01 -0500 X-MC-Unique: Jn_Fm4AcOZmZMCNsAaD4mw-1 Received: by mail-yb1-f197.google.com with SMTP id f32-20020a25b0a0000000b0061dad37dcd6so7891271ybj.16 for ; Mon, 07 Feb 2022 11:31:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=B2QJ0grRTXaRol3CbmA+sjLXzwOWyh2nvM2VzI/qA8c=; b=zfl6ivVNB85hcJFiT23IRe0CLvW5X7K2cpj3z01/tOa1EXYLl44bGVY76N3ST1y8tt VKwlFV2xHM1SInk9CVx/G8PdOsKk2wbIMs2Gr/3lEU5WKnoa3JvVk0UiZbQY4XsgK80D ald05PwCxcKNaLS/5cy317alLtwvb1T2fipTGmZhN748W6P1gwyC0t9lSXQJf6yXR7WT LFqv1EqNkMUuhhghFs9whAjZh5+4FW4+AJUfOcnZIxlZ7vCzq4g3ayn4EkcxQv3+L21k QoPhqLLmPdw/9QJPtSWblVXlwqIhHUZaexWWxYrcCDBV2IuCZQ08yegu8L9OnnXV7H9F rJWg== X-Gm-Message-State: AOAM531lwoxJ+V8u29vPHNSAVIPmUZPTitaUAsljMoqrGpXCjOoZizNe r58GzE2lzgvrz+e2VxHSLT4TAlzgYjsQC8gKpXF11S7ycEXcgy+xHy5+HpRQtkg0Rokd6Z2IXUs el3pwFTLzXX7e6txpWKZi7YeWkY3CozM= X-Received: by 2002:a81:b666:: with SMTP id h38mr1423956ywk.321.1644262259043; Mon, 07 Feb 2022 11:30:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJwMa6TwqDyUNR8HV6m5trrH7FxuIVSfxa7k7WRxeGOEC3qcjNfXaMG2nA4uiGcKQu6bi9i3/bRUAB+S9sey90E= X-Received: by 2002:a81:b666:: with SMTP id h38mr1423796ywk.321.1644262257345; Mon, 07 Feb 2022 11:30:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Johnston Date: Mon, 7 Feb 2022 14:30:46 -0500 Message-ID: Subject: Re: can i delete libtool / shared library support ? To: Newlib , Jeff Johnston Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jjohnstn@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 19:31:08 -0000 It was initially requested and implemented by a newlib user. I have seen some requests for x86_64 support, but it hasn't been updated in a while. We can delete it and point any user to a previous branch if they want to resurrect it. -- Jeff J. On Mon, Feb 7, 2022 at 6:48 AM Corinna Vinschen wrote: > 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 > > >