From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (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 A49C01F454 for ; Thu, 7 Nov 2019 22:32:00 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject:content-type :content-transfer-encoding; q=dns; s=default; b=kwFrZ+XbmzzbI4DA a0ZCIvu2EY9Ri7AEwoGR3FoX25EME1HEMZpK7WukTZJ9Z9dxt11LtArDLV63TkJn K8y+nviwRA4UYLsYhT4MKAaK33i1pr7wcOfEs2uZvTCF0/GnUlOV7a22FOsWnMBi Y4KQzeWRZPQYz/nstAbVVFCv5QE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject:content-type :content-transfer-encoding; s=default; bh=yeCO85+G07K3j/XF46fs3h tRAWg=; b=G2g67jSH0SGpbdtK6+/SAMv8GCq7zpZRUvkykmOR1Pp267jg6j6NWc SdMTbR8FffN5hs4BeoBAW9D/c9+wjWr2gKiGUMvJjhn61FJhSPLbNwy7oOpU3luH fWKTiCwz892uLYmPAPErA6uLlzkpE2MW/rQDFyjispYxLWEWb9gwM= Received: (qmail 45335 invoked by alias); 7 Nov 2019 22:31:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 45323 invoked by uid 89); 7 Nov 2019 22:31:57 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573165914; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Da3+CHtCE/fIjDrtidbyqwV1Un6azZNqBvCmRhwl71U=; b=A/z7/wL/aUSliLqvmwUWX7RIcbIzXFlVFSd2R4/M/b3DkVbOZy1yuN8xRmmmgzfFa/cqv2 3t+Doxz3YD+VOO+GWyBsstOIAlRHtZoS5HM604LxkMK+ErXTngc88iNN6f2vCeI0LDVwys Mj4/He2p7hrvU0GrnbU+bv4dgDIh3EY= Date: Thu, 07 Nov 2019 17:31:50 -0500 Message-Id: From: DJ Delorie To: libc-alpha@sourceware.org Subject: RFC: test-in-container vs ld.so X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable The glibc test infrastructure goes to great lengths to run test programs in the just-built environment, running env and ld.so with lots of arguments to get things "just right". The test-in-container infrastructure goes to... well, less great lengths to provide a "correct native" environment for the test programs, yet it still runs env and ld.so within the container. There are a few of our tests that sometimes fail due to kernel address space randomization when run under ld.so yet work correctly all the time when run directly. So... should we run containerized tests without ld.so? I see two discussion points... 1. Are there tests that *need* the env/ld.so handling within the container? (not counting test-specific environment variables, I mean the environment variables we pass to *every* test) 2. how complicated would it be to remove those from the makefile rules? Alternatively, I suppose test-container itself could remove them, but better not to hide that logic.