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
