From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 2909219E0036 for ; Wed, 23 Dec 2015 05:54:24 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 8694AB5D847 for ; Wed, 23 Dec 2015 06:26:44 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 8EF5318CC7AF for ; Wed, 23 Dec 2015 06:26:44 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 03FF412057F; Wed, 23 Dec 2015 06:26:43 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id E89BB120567 for ; Wed, 23 Dec 2015 06:25:55 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=+CRzk9ccyidNOyHlt1/3Qkz79lw=; b=FnJrzayPrEYvKWK40k keV7+HrHypHkY0zgEXaZq5d6Eq0UiE6tgcoL2GgcV2qYBuCY9ObNHXvKq6Xl3L3Z mJJWF9rOLLBadwwh56sOURrff80RSw2eySL42YvNLEjjijHLyMoYROhknV+omJf0 yrEmFTwLMs+UR0D2sjLLQ4YjM= Received: by filter0918p1mdw1.sendgrid.net with SMTP id filter0918p1mdw1.8275.5679BFDC3A 2015-12-22 21:25:48.948697561 +0000 UTC Received: from herokuapp.com (ec2-54-211-206-254.compute-1.amazonaws.com [54.211.206.254]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id FhuyQv-mQ1yAN-_YwXHhbA for ; Tue, 22 Dec 2015 21:25:48.875 +0000 (UTC) Date: Tue, 22 Dec 2015 21:25:48 +0000 From: luizluca@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 47046 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11863 X-Redmine-Issue-Author: luizluca X-Redmine-Sender: luizluca X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6vezDx+MLKDjLdSPfT6zwskLHGBa4atLf3gQ iCmuCsr2p1mn8W5+BnjDaX8utRBZSxR2y/fgO6m+XgYCxMW1sONDxY7D0XdMkavgWi23kFrteqQk3h R4Vpy130Qi6HWBKCDwlrpJtEwNGa9rWRmAwnkybOM3gDd4JQb5XYe6/GPw== X-ML-Name: ruby-core X-Mail-Count: 72444 Subject: [ruby-core:72444] [Ruby trunk - Bug #11863] [Open] configure/makefile needs to follow the standard behavior X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11863 has been reported by Luiz Angelo Daros de Luca. ---------------------------------------- Bug #11863: configure/makefile needs to follow the standard behavior https://bugs.ruby-lang.org/issues/11863 * Author: Luiz Angelo Daros de Luca * Status: Open * Priority: Normal * Assignee: * ruby -v: ruby 2.2.4p230 (2015-12-16 revision 53155) [i486-linux-gnu] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Hello, I'm the current OpenWRT maintainer of ruby packages. However, configure/makefile for ruby has some exotic usages. LDFLAGS is used only for execs DLDFLAGS for libraries XLDFLAGS for extra options for both. Normally, it is expected that LDFLAGS applies to all linked code. If ruby needs something special for each case, I guess the extra ?LDFLAGS should append to what LDFLAGS defines (and in Makefile). DLDFLAGS is a special confusion. It is an accepted configure VAR. However, that really defines DLDFLAGS in Makefile is not DLDFLAGS but LIBRUBY_DLDFLAGS. At first, LIBRUBY_DLDFLAGS uses DLDFLAGS to define its initial value. However, for some targets, it is simply overwritten (i.e.: for linux). XLDFLAGS also has this problem of not respecting what was defined. However, reading the code, this happens only for AIX. I wasn't hit by this bug. I noticed in some places that some configure vars include other vars as value. Ex: darwin*) : ... LIBRUBY_DLDFLAGS="$LIBRUBY_DLDFLAGS "' $(XLDFLAGS)' Normally all vars should include only new arguments. The job of merging VAR values should be done in Makefile. This happens for most of vars, but not for some cases like LIBRUBY_DLDFLAGS. Specially for this example, LIBRUBY_DLDFLAGS is only used to define DLDFLAGS in Makefile and it DOES already include XLDFLAGS there. Appending var values with another var both in configure and makefile makes the build debugging a lot harder, specially if it changes the var names. What would be expected by configure/makefile: 1) standard vars like CFLAGS, LDFLAGS, etc should be respected for all compiled/linked code. 2) all accepted env var defined for configure should not be replaced internally by ./configure but only appended. 3) var XYZ defined in configure should be the one that defines var XYZ in Makefile. Extra opts not appended should come from an extra var. 4) var XYZ should not include the value of another var ABC in configure. Do it in Makefile. -- https://bugs.ruby-lang.org/