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,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 854951F5A0 for ; Sat, 4 Feb 2023 21:58:48 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=sc3d.org header.i=@sc3d.org header.a=rsa-sha256 header.s=google header.b=zz04gWmM; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOQYP-0008JL-Rj; Sat, 04 Feb 2023 16:58:37 -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 1pOQYO-0008Is-MK for bug-gnulib@gnu.org; Sat, 04 Feb 2023 16:58:36 -0500 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOQYM-0003rY-1N for bug-gnulib@gnu.org; Sat, 04 Feb 2023 16:58:36 -0500 Received: by mail-ej1-x632.google.com with SMTP id ud5so24567824ejc.4 for ; Sat, 04 Feb 2023 13:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=r1SCxo6Z/RQvUYgivvBw6j2lNA2hH6KcFAFcHssBX5s=; b=zz04gWmM7w9FTE63TS63ZGH2LwmpAoBE0lc+MGK4DY0ZIcE89XUBspx2mboHswzvW0 b40raXrLJemXjdfwiAcIDuGGnQSkCgSdqdD9LX76NubuYsqcnxkYeIbJTDwIamR5yRKb sPVwvgprbexvYVs1Q3PR6lwlHr/W3slY+ZQHo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=r1SCxo6Z/RQvUYgivvBw6j2lNA2hH6KcFAFcHssBX5s=; b=a6kDYVHBms3Zw+gbMfeV7yzprPAxK2WvbV3YcVncoS609zNUZ+hwcTwMnoZF8VmGGb hRwNSJurFKkLSvDiaP0oJlcXCwrdLtzNKv5VCGhGPEx7zap64FhyjTrFgcaXHMB4VV8b h544Yz6QCF4jTVCTzz5YZMCvvgv74wJkHnb6qtaTTOQ9eby5THDQLciz1i25w8u+lP8o AtqlidQBE64Nw4kvbGTtPiNTTAyr6MBqVlJT+YT27oFO+V0ybkUR590nPY+9D/Cf0RKX HZlgkCvewii8643nNR/X6pJndodJ+v2ng9iQApAWCn/aGim7M6edW5vlmobIib24ndhy Vkmw== X-Gm-Message-State: AO0yUKUnRdz4zuWCVbmae7AqxWRRvZHuGNXz7u4fLRulZi1kWA5li+Mp lVC4ZAQ0ZAQFqqdYp5PqVE8UNT18txoZRtR6x2dKi422D0+5cWRG X-Google-Smtp-Source: AK7set86Tafxc8glZqw6uEQoHBKjdatYkZxx6mGhVhqPFIsoe2ViQH2TZ7CtZ6V4QkEvR2G8jCzma2szxE/yR0GHLSM= X-Received: by 2002:a17:906:af8a:b0:87b:dae9:a1e4 with SMTP id mj10-20020a170906af8a00b0087bdae9a1e4mr4207898ejb.48.1675547910949; Sat, 04 Feb 2023 13:58:30 -0800 (PST) MIME-Version: 1.0 References: <3039310.PgGeRfN6Q1@nimes> In-Reply-To: <3039310.PgGeRfN6Q1@nimes> From: Reuben Thomas Date: Sat, 4 Feb 2023 21:58:19 +0000 Message-ID: Subject: relocatable-prog nits To: bug-gnulib Content-Type: multipart/alternative; boundary="00000000000009607405f3e6e6df" Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=rrt@sc3d.org; helo=mail-ej1-x632.google.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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 --00000000000009607405f3e6e6df Content-Type: text/plain; charset="UTF-8" Bruno has been helping me test https://github.com/rrthomas/libpaper on various systems. (Many thanks, Bruno!) On Wed, 1 Feb 2023 at 12:39, Bruno Haible wrote: > On GNU/Hurd and Cygwin, I see 9 test failures. Such as > > --- expected-fixed.txt 2023-02-01 03:02:44.000000000 +0100 > +++ default-size-no-default-paper-output-fixed.txt 2023-02-01 > 03:02:44.000000000 +0100 > @@ -1 +1 @@ > -paper: no default paper size is set > +/home/bruno/libpaper-2.0.5/build/tests/default-size-no-default-paper.9592/home/bruno/bin/paper: > no default paper size is set > FAIL default-size-no-default-paper.sh (exit status: 1) > > [snip] > > Apparently the program name includes its path here. Probably because on > these platforms, the Gnulib --enable-relocatable support leads to the > creation of 2 installed programs: paper.bin and paper. (The latter is a > trampoline that invokes paper.bin.) > I would like to make the error messages look nice for the user (rather than just fixing the tests). I could use some help here, as I don't understand what's going on! I use the relocatable-prog gnulib module, and specifically the function set_program_name_and_installdir(). Looking at its source in gnulib/lib/progreloc.c, it has code specifically to strip off a ".bin" suffix. I can't see why this isn't happening on Cygwin (I have code in my main.c such that _WIN32 is defined, then the name passed to the function is just "paper", whereas if it isn't, then ".bin" should be stripped out). Then there's the trampoline, in progreloc.c. This sets argv[0] of the program it calls to get_full_program_name () plus the .bin suffix. This seems unfortunate, as progname.c's set_program_name, called by set_program_name_and_installdir from progreloc.c, deliberately doesn't remove an absolute path from the start of the executable name. Should the trampoline not attempt to hide itself, and keep the argv[0] of the process it execv's the same as its own? (I'm conscious that Bruno wrote the code in question, but it seemed more correct to post the question to bug-gnulib than simply reply to him!) -- https://rrt.sc3d.org --00000000000009607405f3e6e6df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bruno has been helping me test https://github.com/rrthomas/libpaper on = various systems. (Many thanks, Bruno!)

On Wed, 1 Feb = 2023 at 12:39, Bruno Haible <bruno@cl= isp.org> wrote:
On GNU/Hurd and Cygwin, I see 9 test failures. Such as

--- expected-fixed.txt=C2=A0 2023-02-01 03:02:44.000000000 +0100
+++ default-size-no-default-paper-output-fixed.txt=C2=A0 =C2=A0 =C2=A0 2023= -02-01 03:02:44.000000000 +0100
@@ -1 +1 @@
-paper: no default paper size is set
+/home/bruno/libpaper-2.0.5/build/tests/default-size-no-default-paper.9592/= home/bruno/bin/paper: no default paper size is set
FAIL default-size-no-default-paper.sh (exit status: 1)

[snip]

Apparently the program name includes its path here. Probably because on
these platforms, the Gnulib --enable-relocatable support leads to the
creation of 2 installed programs: paper.bin and paper. (The latter is a
trampoline that invokes paper.bin.)

I would = like to make the error messages look nice for the user (rather than just fi= xing the tests).

I cou= ld use some help here, as I don't understand what's going on!

I use the relocatable-p= rog gnulib module, and specifically the function set_program_name_and_insta= lldir(). Looking at its source in gnulib/lib/progreloc.c, it has code speci= fically to strip off a ".bin" suffix. I can't see why this is= n't happening on Cygwin (I have code in my main.c such that _WIN32 is d= efined, then the name passed to the function is just "paper", whe= reas if it isn't, then ".bin" should be stripped out).

Then there's the tra= mpoline, in progreloc.c. This sets argv[0] of the program it calls to get_f= ull_program_name () plus the .bin suffix. This seems unfortunate, as progna= me.c's set_program_name, called by set_program_name_and_installdir from= progreloc.c, deliberately doesn't remove an absolute path from the sta= rt of the executable name.

Should the trampoline not attempt to hide itself, and keep the argv[0= ] of the process it execv's the same as its own?

(I'm conscious that Bruno wrote the code in questi= on, but it seemed more correct to post the question to bug-gnulib than simp= ly reply to him!)

--
=
--00000000000009607405f3e6e6df--