From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D5B541F5A0 for ; Tue, 7 Feb 2023 15:22:45 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SRgQ6QTD; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPPns-0003d9-1x; Tue, 07 Feb 2023 10:22:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPPnp-0003b5-On for bug-gnulib@gnu.org; Tue, 07 Feb 2023 10:22:37 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPPnn-0001y2-OV for bug-gnulib@gnu.org; Tue, 07 Feb 2023 10:22:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675783352; h=from:from: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=s2fvW4X0kuOeIE3QgXFJ1qIrgdUVcf8JE4bjepZTmyU=; b=SRgQ6QTDKEAxmXyLzmAF1AZlKFWzo0CFO5uC2akGzP4FJUeakmcQF2LRYw0BJQ84rBX63J gqV8gOBGAhCRZbI4PzOTC8acvOGVS4sBoUW4W2lLm/cNnMjZYQyNFz/0UPtbi3U37Ow3Ck U/F/0mxQbDD3vmb4iWnph0zhy14oqpQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-288-90m3gGlZNUqkigpcyj4VXg-1; Tue, 07 Feb 2023 10:22:29 -0500 X-MC-Unique: 90m3gGlZNUqkigpcyj4VXg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2761129AA3BF; Tue, 7 Feb 2023 15:22:29 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.192.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BB2401121314; Tue, 7 Feb 2023 15:22:28 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id AA97BA80940; Tue, 7 Feb 2023 16:22:25 +0100 (CET) Date: Tue, 7 Feb 2023 16:22:25 +0100 From: Corinna Vinschen To: Reuben Thomas Cc: Bruno Haible , bug-gnulib@gnu.org Subject: Re: [PATCH] Do not decorate symbols as dllexport on Cygwin Message-ID: References: <20230205194344.269174-1-vinschen@redhat.com> <3384697.1Xququ8Bcc@nimes> <3099885.Repjz8aVax@nimes> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="n+PuRMrrCQwXrAVQ" Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=vinschen@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org --n+PuRMrrCQwXrAVQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hi Reuben, On Feb 7 14:22, Corinna Vinschen wrote: > On Feb 6 20:50, Reuben Thomas wrote: > > On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote: > > > > > 1. 'recode' is updated to a current gnulib and publish a corresponding > > > tarball. (Hi Reuben :) ) > > > > > > > I've updated gnulib in recode git; I'd be grateful if I could have a report > > that it's doing what's needed here before I make a release, if possible! > > > > Git at: https://github.com/rrthomas/recode.git > > Working on it, but this may take a while. Stay tuned, please. The new recode gnulib build works as desired, thank you. However, I'm trying to build recode from the Cygwin-specific build script, and running it with default settings I get an error before recode even got built: help2man: can't get `--help' info from ./recode.exe Try `--no-discard-stderr' if option outputs to stderr WARNING: '/usr/bin/help2man' is missing on your system. [...] So even with help2man installed, it doesn't work because recode.exe didn't get build yet. The Cygwin build system prefers parallel make. And that's the problem. I think commit dcdd5d26c0c2 is wrong: -recode.1: main.c $(top_srcdir)/configure.ac recode$(EXEEXT) +recode.1: main.c $(top_srcdir)/configure.ac This means that recode.1 doesn't depend on the built binary anymore even though it *needs* said binary to create the man page from it. This breaks dependency tracking in make and so make happily runs the recode.1: rule before recode has been built, just depending on the existence of main.c and configure.ac. For cross-checking I tried a Linux build with `make -j8' and help2man gets called before recode even got built as well. So the above change breaks parallel make. Not sure how to fix this correctly, but I have another patch, which would be nice to have: In Cygwin projects using libtool, we always have to add -no-undefined iLDFLAGS. This is some old safe-guard in libtool to remind developers that when creating Windows DLLs, all external symbols must be resolved. Fortunately, libtool allows this flags also on other platforms which don't require its usage. Patch is attached. It would be nice if that's ok for inclusion. Thanks, Corinna --n+PuRMrrCQwXrAVQ Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="0001-src-Makefile.am-librecode_la_LDFLAGS-add-no-undefine.patch" >From 9ea601d4615d8420e7cf75659b647728774f65c9 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Tue, 7 Feb 2023 16:09:29 +0100 Subject: [PATCH] src/Makefile.am: librecode_la_LDFLAGS: add -no-undefined -no-undefined is a libtool requirement to build shared libs on Windows-based platforms like Cygwin. --- src/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 93d3ed3634b1..427cc8c97fe7 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -52,7 +52,7 @@ recode_LDADD = librecode.la librecode_la_SOURCES = charname.c combine.c fr-charname.c iconv.c \ names.c outer.c recode.c request.c strip-pool.c task.c $(ALL_STEPS) \ $(include_HEADERS) $(noinst_HEADERS) $(H_STEPS) -librecode_la_LDFLAGS = -version-info $(VERSION_INFO) $(LTLIBINTL) \ +librecode_la_LDFLAGS = -no-undefined -version-info $(VERSION_INFO) $(LTLIBINTL) \ $(LIB_CLOCK_GETTIME) $(LIB_GETRANDOM) $(LIB_HARD_LOCALE) $(LIB_MBRTOWC) $(LIB_SETLOCALE_NULL) librecode_la_LIBADD = ../lib/libgnu.la libmerged.la -- 2.39.1 --n+PuRMrrCQwXrAVQ--