OK, I finally figured out how to get 3.1.2 to compile. If I use the
"aclocal.m4" file from 3.1.1 in my 3.1.2 unmodified source, I am able to
compile and run ganglia successfully.
This made me wonder...Isn't this file supposed to be generated? So I
deleted the aclocal.m4 file that is currently distrubted with 3.1.2 and
tried building again...and viola! it works fine. When completed, I
diff'ed the aclocal.m4 file which was created and it is now identical to
the 3.1.1 version.
So if there are any developers out there...you might want to look into
this...
jrd
On Thu, 7 May 2009, Justin R. Davis wrote:
>
> Just for fun, I tried compiling 3.1.2 with the configure file from 3.1.1.
> Still have the same problems.
>
> jrd
>
> PS Here are the diff's in the configure output and config.cache:
>
>
> 5,6c5,6
> < checking build system type... x86_64-unknown-linux-gnu
> < checking host system type... x86_64-unknown-linux-gnu
> ---
>> checking build system type... x86_64-unknown-linux
>> checking host system type... x86_64-unknown-linux
> 73d72
> < checking if gcc static flag works... yes
> 76a76
>> checking if gcc static flag -static works... yes
> 92a93
>> checking if g++ static flag -static works... yes
> 97d97
> < checking whether stripping libraries is possible... yes
> 102c102
> < configure: creating cache /root/build/ganglia/ganglia-3.1.1/config.cache
> ---
>> configure: creating cache /root/build/ganglia/ganglia-3.1.2/config.cache
> 107,108c107,108
> < checking build system type... x86_64-unknown-linux-gnu
> < checking host system type... x86_64-unknown-linux-gnu
> ---
>> checking build system type... x86_64-unknown-linux
>> checking host system type... x86_64-unknown-linux
> 175d174
> < checking if gcc static flag works... yes
> 178a178
>> checking if gcc static flag -static works... yes
> 194a195
>> checking if g++ static flag -static works... yes
> 199d199
> < checking whether stripping libraries is possible... yes
> 308c308
> < updating cache /root/build/ganglia/ganglia-3.1.1/config.cache
> ---
>> updating cache /root/build/ganglia/ganglia-3.1.2/config.cache
> 526,527c526,527
> < Version: 3.1.1 (Wien)
> < Library: Release 3.1.1 0:0:0
> ---
>> Version: 3.1.2 (Langley)
>> Library: Release 3.1.2 0:0:0
>
>
> ==============================================================================================
> 14,15c14,15
> < ac_cv_build=${ac_cv_build=x86_64-unknown-linux-gnu}
> < ac_cv_build_alias=${ac_cv_build_alias=x86_64-unknown-linux-gnu}
> ---
>> ac_cv_build=${ac_cv_build=x86_64-unknown-linux}
>> ac_cv_build_alias=${ac_cv_build_alias=x86_64-unknown-linux}
> 98,99c98,99
> < ac_cv_host=${ac_cv_host=x86_64-unknown-linux-gnu}
> < ac_cv_host_alias=${ac_cv_host_alias=x86_64-unknown-linux-gnu}
> ---
>> ac_cv_host=${ac_cv_host=x86_64-unknown-linux}
>> ac_cv_host_alias=${ac_cv_host_alias=x86_64-unknown-linux}
> 147c147
> < lt_cv_file_magic_test_file=${lt_cv_file_magic_test_file='/lib/libc.so.6
> /lib/libc-2.5.so'}
> ---
>> lt_cv_file_magic_test_file=${lt_cv_file_magic_test_file=}
> 159c159
> < lt_cv_sys_global_symbol_pipe=${lt_cv_sys_global_symbol_pipe='sed -n -e
> '\''s/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][
> ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p'\'''}
> ---
>> lt_cv_sys_global_symbol_pipe=${lt_cv_sys_global_symbol_pipe='sed -n -e
> '\''s/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][
> ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\'''}
> 165c165
> < lt_lt_cv_sys_global_symbol_pipe=${lt_lt_cv_sys_global_symbol_pipe='"sed
> -n -e '\''s/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ ][
> ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'\''"'}
> ---
>> lt_lt_cv_sys_global_symbol_pipe=${lt_lt_cv_sys_global_symbol_pipe='"sed
> -n -e '\''s/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ ][
> ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'\''"'}
>
>
>
>
> On Thu, 7 May 2009, Justin R. Davis wrote:
>
>>
>> Comments below.
>>
>> On Thu, 7 May 2009, Carlo Marcelo Arenas Belon wrote:
>>
>>> On Thu, May 07, 2009 at 10:23:22AM -0400, Justin R. Davis wrote:
>>>>
>>>> When I try and compile 3.1.2 I run into a problem linking with the expat
>>>> library.
>>>
>>> do you have both a 32bit expat (/usr/lib) and 64bit expat (/usr/lib64)?
>>> which distribution/version?
>>
>> Yes
>>
>>>> Ganglia's libtool want to use the version in /usr/lib although
>>>> I believe it should be using the version in /usr/lib64
>>>
>>> that is the problem, ganglia's configure is sadly not that smart as it
>>> was only starting with 3.1.0 that it uses external library dependencies
>>> and for whatever reason your setup is getting it confused.
>>>
>>>> If I try and compile 3.1.1 on the same computer, using the same configure
>>>> arguments, it builds fine:
>>>
>>> this is therefore a regression, at least for your configuration, for that
>>> the output of your config.log might be needed, so feel free to send it
>>> directly (as it might be too big for the list), or attach it to a bug
>>> report with all other relevant information.
>>
>> I tried attaching both, but that was too big so I only attached 3.1.2. For
>> this email, I've attached the "diff"'s between 3.1.1 and 3.1.2.
>>
>> BTW, one thing of interest I saw was that the build type shows up
>> differently. The 3.1.1 version being x86_64-unknown-linux-gnu. So
>> I tried --build=x86_64-unknown-linux-gnu but this results in the same
>> problems.
>>
>>> since there shouldn't had been any changes between 3.1.1 and 3.1.2 that
>>> could trigger this AFAIK, would be also interesting to see what the working
>>> 3.1.1 log shows.
>>>
>>> if you could extract the relevant information for this thread, even better
>>> as that would help other people later that have your same problem.
>>>
>>>> Any idea how this issue can be fixed in the 3.1.2 version?
>>>
>>> as a workaround you might be able to use :
>>>
>>> ./configure --libdir=/usr/lib64
>>
>> Just tried. This does not help. Per the output from "--help" this seems
>> to apply to the installation as opposed to the compilation.
>>
>> I also tried setting the LDFLAGS variable, however, even though this
>> is unset originally, setting it to /usr/lib64 results in a whole host of
>> other problems.
>>
>> jrd
>>
>> PS Also, one more thing. This problem is not unique to the computer I'm
>> providing output for. I've the same problem on atleast 3
>> computers...Granted, they may all be configured similarly, but it's not
>> something specific to just this one computer.
>>
>>> Carlo
>>>
>>
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Ganglia-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>
>
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
