From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 19:14:28 2023 Received: (at submit) by debbugs.gnu.org; 12 Mar 2023 00:14:28 +0000 Received: from localhost ([127.0.0.1]:58825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb9M4-0004lq-8V for submit@debbugs.gnu.org; Sat, 11 Mar 2023 19:14:28 -0500 Received: from lists.gnu.org ([209.51.188.17]:58144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pb9M2-0004li-O0 for submit@debbugs.gnu.org; Sat, 11 Mar 2023 19:14:27 -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 1pb9M2-000283-H9 for bug-sed@gnu.org; Sat, 11 Mar 2023 19:14:26 -0500 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pb9M0-0002qm-Sm; Sat, 11 Mar 2023 19:14:26 -0500 Received: by mail-pj1-x1029.google.com with SMTP id x20-20020a17090a8a9400b00233ba727724so10362825pjn.1; Sat, 11 Mar 2023 16:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678580062; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cDy/Cv8iXX3BqjY9QSGO3QApXtdFhV2jNLjkFnEixmc=; b=O0nMd412xA8CYE5MgSPmXUt3jgRQWCaQmHi6EqvX4EsEd6i8RoV0+lLC8sWOcGzYwj synsbK7qEZxlL3h1HtZw229XLq8AAp6yAv5vp767EzSY1eWyUSsXTv0LyL+airtGQBWX YmjOjA0aYxvH8ClvGTD96gzAzH6vAZvo7L9toTR0vFfDU9Upd7JLv5X9ayun/+RxIBkp 7n/iMYz+3gwSDa0TOODqkvp1PfQKikLTQYLtho6sl05ng4+nZ+L12SvwhrtxTq1FbZCx veHs6zmmw4tlYJopQPpPKOqywHZ3jLPUQJOqk7MeYLSZtGbDS5hJFTrcFW22rzRZ3hQp n+Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678580062; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cDy/Cv8iXX3BqjY9QSGO3QApXtdFhV2jNLjkFnEixmc=; b=wbieo+euW9qjdTcpsh8YX4BR54aWNeIF7WhXWrmiS7PjWi09S0kKHwMbAcjzonM1Kq udIBRcQu904J+6G1xQWGou5GqofYhCZzmpQp1y/eUMa26isWqqiVK/NS8ELRwCzQ0KEM 7MMyJOHO+eGHqTCaUW3xkhRU2lQk3O/fHyuO1aQa3lVs8MkQXSkxsEpoo1OjB8nilxw9 luoEqOaAaN7AmnDBbyJ4paMqp2l/HMNgpV+OQNaXrDMZqZ4g7mmzOOj0UnqzUrUBuQ+x evvhKQjtKYcQOTSAeQd/+xEWF9Psii2RxsRHKlsCqOlmBUk9XzfNV2rXquRwbEyX+kTp kqkw== X-Gm-Message-State: AO0yUKVURwDDSsZPGtfLSpXrg97txbPhoL2Fy4nCvkbViLl6ty2IJaOu +slWOnwBzupCIKV0cqOAROD8Q1AKEyuVHMmIevXxJPgWf5c= X-Google-Smtp-Source: AK7set9l5d8zgJFSMZiGaiVehJXOk+EhSE/sl2tLTfewivEqpjrjPlehNuvHS1puW1l5LIIiEhTRnERxVI+aB07HvyQ= X-Received: by 2002:a17:903:281:b0:19a:fdca:e3f1 with SMTP id j1-20020a170903028100b0019afdcae3f1mr11740117plr.3.1678580061741; Sat, 11 Mar 2023 16:14:21 -0800 (PST) MIME-Version: 1.0 From: Eike Dierks Date: Sun, 12 Mar 2023 01:14:10 +0100 Message-ID: Subject: regression on compling sed-4.9 on SunOS 5.10 To: bug-sed@gnu.org, rms@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=foonlyboy@gmail.com; helo=mail-pj1-x1029.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, FREEMAIL_FROM=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-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hello at the sed team I encountered a problem when compiling sed-4.9 on SunOS 5.10 I then tried again with sed-4.8, which compiles just fine. The problem is with clock_gettime This api does not exists in legacy operating systems This is now one of the most common problems, when trying to compile the newest gnu code on older systems. I suggest to add to autoconf: HAS_CLOCK_GETTIME I fully understand the reason behind the new clock_gettime, but it really breaks the code with all the leagcy oses. I understand that this api was invented to help with the cloud. Because they had problems with the leap second. But now it turns out, this is a desastorous change to the api, that makes me fail to even compile sed from scratch. I know, we can have some shim for this. But why does sed 4.9 not compile out of the box for me? We should really fix that. Best regards, Eike Dierks