How are you getting your collection from your PC to the server?
Are you using the GLI applet to build collections directly on the
server? Or building it locally then copying it across?
If you have built a collection locally and want to copy it to another
greenstone installation, you just copy the collect/mypccollection
directory to the collect directory of the other greenstone.
Alain Veylit wrote:
> Hi John,
> Many thanks for this, it is useful to know. Perhaps adding a note to the
> installation WEB page would be useful for otehr people. For me, adding
> soft links in /usr/lib seemed to be the only solution that worked, but
> it may be because of a confusion between the GNU and the SUN ld.
> I have another problem, with the GLI, this time: when I export a
> collection from my pc to the server, the data ends up in a sub-directory
> under the actual target directory, i.e. the collect.cfg file ends up in:
> /gsdl/collect/mypccollection/etc/mypccollection/collect.cfg and the
> imported data ends up in
> /gsdl/collect/mypccollection/import/mypccollection/import. I then get
> error messages from the import.pl script that probably still looks for
> the data in /gsdl/collect/mypccollection/import/
> Anyone came across that particular problem?
> John R. McPherson wrote:
>> On Fri, Oct 28, 2005 at 12:33:06PM -0700, Alain Veylit wrote:
>>> Many thanks to Katherine and Kurt for a prompt response:
>>> I tried Katherine's suggestion and recompiled with gdbm in static
>>> mode. That did not work.
>>> -Is it possible that my problem comes from a confusion between gcc
>>> and the SUN native compiler?
>>> -Should I recompile with the original dynamic gdbm configuration?
>>> -Would Solaris 10 have proved less problematic? I think they tried to
>>> make it LINUX compatible...
>>> The main thing is that I made it passed the installation stage (I
>> This seems to be an ongoing problem for people installing on solaris,
>> but we don't have solaris machines available for testing and noone's
>> given us a solution that seems to work for everyone.
>> As you can see, the problem is that gdbm installs to /usr/local/lib
>> but by default the system only looks for libraries in /lib and /usr/lib.
>> For some people, libstdc++ gets installed in a weird place as well
>> and the linker has problems finding it at link time.
>> One solution is to provide a wrapper script for the cgi executable
>> that sets the LD_LIBRARY_PATH to include /usr/local/lib.
>> A better solution is to compile and link with an option that makes the
>> executable look in /usr/local/lib at run time. GNU's ld takes an
>> "-rpath" option that embeds the names of directories to search. However,
>> the manual page also says that on SunOS, the linker does that
>> for any paths given with the -L at link time. You could try setting
>> "LDFLAGS='-rpath /usr/local/lib'" for your configure command.
>> It might also be a difference between the GNU ld and sun's own ld,
>> I'm not sure what sun's tools do.
>> John McPherson
> greenstone-devel mailing list