Print

Print


On Thu, 30 Jul 2009, Peter W. Draper wrote:

> On Thu, 30 Jul 2009, Rodney Smith wrote:
>
>> Just having a bit of a 'play' with nanahope on a 64-bit Scientific Linux 
>> 5.2 machine and when I start gaia I get a window with
>> 
>> 'Failed to load GAIAVO:couldn't load file "/star/lib/libgaiavo4.3.0.so": 
>> libcurl.so.4:cannot open shared object file: No such file or directory'
>> 
>> Clicking OK starts gaia apparently OK.
>> 
>> As far as I can see, we only have libcurl.so.3 (through 
>> curl-7.15.5-2.1.el5_3.4.x86_64.rpm) and this is the standard for SL 5.3 
>> too.
>
> Hi Rodney,
>
> thanks, seems JAC have a locally built version of libcurl installed 
> (libcurl-7.18.2-9.el5.JAC), which has been picked up in the build.
>
> Brad & Tim,
>
> this affects the following binaries:
>
>   $GAIA_DIR/gaiavo_tcl
>   $GAIA_DIR/listvot
>   $GAIA_DIR/tab2vot
>   $GAIA_DIR/vot2tab
>
> as well as:
>
>    libgaiavo4.3.0.so
>    libxerces-c-3.0.so
>
> in $STARLINK_DIR/lib. GAIA will continue to work without this but the VO 
> features will be disabled.
>
> I'll transfer this discussion to the developer list as we need to 
> discuss the possible options.

So continuing from myself.

Obviously you can just remove the offending libcurl (but I assume your sys 
admins put that in place for a reason, security update, some other binary 
requirement) and rebuild GAIA.

I tried picking up the "libcurl.so.4" file from JAC and using that on my 
machine, but it seems to have a lot of additional dependendent libraries, 
maybe that will work out better for SL5.2, but I don't have access to one 
of those to check.

Finally, we could stop XERCES from using libcurl and fallback to one of 
the other net accessors it uses. Not sure what the downside of that would 
be, maybe reduced functionality, but as long as HTTP is supported I don't 
think we care.

Opinions?

Peter.