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 09ED51B00063 for ; Fri, 21 Oct 2016 21:16:53 +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 464DBB5D8DD for ; Fri, 21 Oct 2016 21:48:04 +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 CFC9818CC819 for ; Fri, 21 Oct 2016 21:48:04 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 3A4A412047D; Fri, 21 Oct 2016 21:48:05 +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 86AC5120455 for ; Fri, 21 Oct 2016 21:48:00 +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=wwh603r62OJs01hKxeUodqB+xbM=; b=oWXAv1RpmwDyb3Sls7 Ey1Wt+Hi4PYfR/xulq8GnWj4/zqJhgH8kdcz9k8/jX0jFK9UwfnEHASTcvbQnpyy bRP7XL4XHBxLX/EDFLkLpbXI3KG0yQTMz9RwaspwdIRq8U273cefLKHtorh43Z+t rpa4BGj1eyUCjxRq+e5ws374I= Received: by filter0825p1mdw1.sendgrid.net with SMTP id filter0825p1mdw1-22021-580A0E7B-5A 2016-10-21 12:47:55.859126757 +0000 UTC Received: from herokuapp.com (ec2-54-242-49-179.compute-1.amazonaws.com [54.242.49.179]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id 6cUy7ISeQQyaE79n65xPag for ; Fri, 21 Oct 2016 12:47:55.813 +0000 (UTC) Date: Fri, 21 Oct 2016 12:47:55 +0000 From: v.ondruch@tiscali.cz To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 52552 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11863 X-Redmine-Issue-Author: luizluca X-Redmine-Issue-Assignee: nobu X-Redmine-Sender: vo.x 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6bKxLzzH7w1tj7Ni/4MhyMoEBf6DLnhURKU3 pyiCOtUKRtDzEzXQFvexLV663c2v5Pywur0lzmBi08AK6WX/l4pLS2fylHQUejNNyKoiO7mT7GSKU3 zFvqqLCIFRHcRgf+GEkX5YxtT/uPSTqdymrlegZo0cBpC7fo1uYCCNNoDA== X-ML-Name: ruby-core X-Mail-Count: 77699 Subject: [ruby-core:77699] [Ruby trunk Bug#11863] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11863 has been updated by Vit Ondruch. Assignee set to Nobuyoshi Nakada ---------------------------------------- Bug #11863: configure/makefile needs to follow the standard behavior https://bugs.ruby-lang.org/issues/11863#change-60981 * Author: Luiz Angelo Daros de Luca * Status: Open * Priority: Normal * Assignee: Nobuyoshi Nakada * 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/