>>> On 4/27/2007 at 9:21 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> I'm trying to build RPMs with ganglia trunk on CentOS 4.4 and ran into
> some issues:
>
> You added to the spec file the BuildRequires for libapr1-devel -- this
> is the name of the SuSE package, this will not work for Red Hat/
> Fedora, I have fixed it with the following:
>
> -BuildRequires: libapr1-devel libpng-devel, libart_lgpl-devel, gcc-c++
> +BuildRequires: libpng-devel, libart_lgpl-devel, gcc-c++
> %if %{?suse_version:1}0
> -BuildRequires: rrdtool, freetype2-devel
> +BuildRequires: rrdtool, freetype2-devel, libapr1-devel
> %else
> -BuildRequires: rrdtool-devel, freetype-devel
> +BuildRequires: rrdtool-devel, freetype-devel, apr-devel
>
Cool
> You also added the --with-libapr option for configure in the spec
> file. CentOS 4.4 comes with apr-0.9.4 and did not seem to work. Does
> your code only work with apr 1.2.x? If so we need to impose a version
> dependency to apr(-devel) -- this also means that ganglia 3.0.5 will
> not work with distributions that do not come with a more recent
> version of apr -- do we have a solution for that (eg. by updating the
> version of apr which we ship)?
>
The --with-libapr will only work with APR 1.2.x. In addition to telling the
linker to link with libapr1, it also sets a #define to switch many of the
socket calls to the 1.2.x version of the APIs. I think that the solution going
forward with Ganglia 3.1.x would be to move completely to APR 1.2.x and for
those distros that don't have an updated APR, either leave that up to the
Ganglia package maintainer on that distro or provide an APR 1.2.x RPM for the
distro. The other option would be to update the APR source in scrlib/apr and
continue shipping it, but I would rather see the Ganglia project move away from
shipping it's own version of APR and just allow configure to choose what to
link with through the --with-libapr option.
> I assume that if I link against apr-1.2.x, it will create also
> libexpat.so*...?
>
Yes, the current makefiles will build a libexpat.so and install it in /usr/lib.
This is actually one thing that bothers me. It works for now but I am afraid
of causing a library collision of a libexpat.so already exists. However I
didn't worry about this too much, assuming that we would be moving away from
the Ganglia version of libexpat in favor of the APR-Util version. That would
eliminate libexpat and allow us to treat APR-Util in the same manner that we
decide to treat APR itself.
Brad
> I'd like to release some snapshot RPMs soon via the openSUSE Build
> Service -- so hopefully we can have these issues resolved.
>
> Thanks!
>
> Bernard
>
> On 4/26/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>>
>>
>> >>> On 4/26/2007 at 11:06 AM, in message
>> <[EMAIL PROTECTED]>, "Bernard Li"
>> <[EMAIL PROTECTED]> wrote:
>> > Brad:
>> >
>> > I recommend you take a look at this thread in ganglia-developers:
>> >
>> >
> http://sourceforge.net/mailarchive/message.php?msg_id=36BEEFA2DF192944BF71E0
>> > 72F7A5F465228FE7%40xchange1.phage.bcgsc.ca
>> >
>> > It offers a potential solution to platforms that do not have apr
>> > installed and also opinions of other distribution packagers regarding
>> > this issue :-)
>> >
>> > Thanks,
>> >
>> > Bernard
>> >
>>
>> Yep, the whole reason why I left it so that static linking with the Ganglia
> copy of APR still works. Since I am fairly new to this project, I didn't
> want to step on any toes too hard ;) Going forward I think that I am in
> agreement with the idea of shipping two tarballs or at least providing
> --with-libXXX=<lib_path> configure options so that the packager or user has
> the option of how to build a complete Ganglia system. I really don't care
> what the defaults for the configure options are. They could default to
> dynamically linking the distro's libraries or statically linking the Ganglia
> packaged versions. Configure can also be a little smarter and try to detect
> if the library is already on the system before including and building the
> Ganglia packaged version. Bottomline is that we can certainly make the
> external libraries optional.
>>
>> One issue that needs to be addressed is if Ganglia builds and installs APR
> (or any external library) onto a system that already has Apache or Subversion
> installed, there is the potential for a problem with duplicate versions of
> APR (expat, confuse, etc.). As it stands, Ganglia is not making sure that it
> is not attempting to reinstall an existing library. Of course this was one
> of the arguments for static linking. However the problem with static linking
> at least APR, is that now that we have plugable metrics modules for GMOND, no
> metric module would be able to use APR. Therefore, going forward, we need to
> dynamically link APR. So the way to solve the problem would be to always
> build the external libraries as DSO's if the appropriate library does not
> already exist on the box. Then install the libraries in an /opt/ganglia/lib
> location.
>>
>> Anyway, sounds like there has been some good discussion on this topic in the
> past. So let's solve it and move forward.
>>
>> Brad
>>
>>
>>
>>
>>
