Hi Bernard,
You already have my feelings on this lib64 problem (see below), and the outcome of the queries I sent on the autoconf mailing list. However, I can't personally commit to making the proposed changes, so I have no objection if you choose which direction to take the matter. Backing out the change should not be terribly difficult, but if I remember correctly, I was playing with lib64 related stuff in both configure.in and also in the spec file. Let me know if it is something you prefer to have a go at, or if you would like me to untangle it. Regards, Daniel Bernard Li wrote: > Hi all: > > It's been almost 4 months and there hasn't been any further discussions on > this. > > Trunk is still broken because of the syntax issue described. I think > I'm just going to go ahead and revert the behaviour of LIB_SUFFIX > assignment back to the original method. > > On my Debian system, /usr/lib64 is symlinked to /usr/lib, so I don't > really think this is an issue (at least on Debian). > > If I don't hear any strong opposition, I'll go ahead and revert this change. > > Thanks, > > Bernard > > On Sat, Mar 6, 2010 at 2:23 AM, Daniel Pocock <dan...@pocock.com.au> wrote: > >>> <d4c731da1003031254x3dd50a1ao9625f79329366...@mail.gmail.com>, Bernard Li >>> <bern...@vanhpc.org> wrote: >>> >>> >>>> Hi Brad: >>>> >>>> Thanks for the confirmation. >>>> >>>> However, I have another issue related to the first problem. Basically >>>> my x86_64 CentOS is detected as "x86_64-unknown-linux-gnu" and thus it >>>> is setting LIB_SUFFIX to "lib" instead of "lib64". >>>> >>>> Do RHEL hosts really identify themselves as x86_64-redhat-linux*? How >>>> about Fedora? I do confirm that this works as expected on an openSUSE >>>> box. >>>> >>>> Perhaps we should reverse the logic and make a special case for Debian >>>> instead? >>>> >>>> >>>> >> The reason I didn't finish this change is because it also became obvious >> to me that Debian was the odd one out >> >> I then went off to the autoconf mailing list to discuss the use of lib >> and lib64 in library paths. Here is the thread: >> >> http://www.mail-archive.com/autoc...@gnu.org/msg19474.html >> >> The outcome of the discussion: >> >> - having configure append lib or lib64 is never going to get perfect >> results, and will sometimes prevent a successful cross compile >> >> - therefore, it was recommended that we should remove all logic that >> attempts to build libraries paths, and users should manually set LDFLAGS >> and CFLAGS to get the result they want >> >> I didn't act on the advice immediately as: >> >> a) I wanted to contemplate the consequences of this new approach >> >> b) configure needs an overhaul anyway, possibly combining >> libmetrics/configure.in and configure.in into a single configure.in >> >> c) I felt the overhaul of configure could come after 3.1.7 gets out >> successfully >> >> Personally, I feel a top-down approach is needed - overhaul configure - >> how do other people feel about this? >> >> >> >> ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
