On 24.02.2012 18:53, Pedro Giffuni wrote:
Hi;
Just FYI
______
...
... analyzing files ...
ERROR: The following files could not be found:
ERROR: File not found: libapr-1.so.0.4.5
ERROR: File not found: libaprutil-1.so.0.4.1
ERROR: File not found: libserf-1.so.0.0.0
... cleaning the output tree ...
... removing directory /tmp/ooopackaging/i_713701330104152 ...
...
___________
The naming scheme is completely inappropriate for FreeBSD:
Yes, and it does not work so well on Mac either. It does not even
follow the Linux naming scheme (see the 0 in libapr-1.so.0.4.5? I do not
know where that does come from.) And on Windows we have a special
makefile which uses yet another naming scheme.
Welcome in multi-platform-world.
Apr (and apr-util and serf) are external libraries. Our means to
control the names of the libraries are limited. If anyone knows how to
change that, please let me know.
If that leads to problems with pre-installed libs on any platform then
we should look for a solution that works on all platforms. The problem,
as I understand it, is this:
A - The modules apr, apr-util, and serf (and possibly coinmp) use their
original (mostly) configure scripts to generate the library name.
B - This name is used in scp2/ to a) include the actual library into the
pack set and b) create some symbolic links that strip away the micro and
minor version numbers.
C - This name is not the same as the one of libraries that are already
installed on the system. The system libraries are therefore not found
at run-time.
I would attempt a solution somewhere between A and B. We already have
{library}_version.mk files in apr,apr-util, and serf that communicate
the major, minor, and micro version numbers to scp2. Maybe we can
rename the libraries to whatever name is appropriate on a platform at
the time when the libraries are delivered into solver/ and then use the
{library}_version.mk file to get the new name into scp2? For this we
have to append the new name to the makefile before it is also delivered.
This should be relatively simple and would require platform specific
knowledge only in apr, apr-util, and serf.
-Andre
ls /usr/local/lib/libapr*
/usr/local/lib/libapr-1.a /usr/local/lib/libaprutil-1.a
/usr/local/lib/libapr-1.la /usr/local/lib/libaprutil-1.la
/usr/local/lib/libapr-1.so /usr/local/lib/libaprutil-1.so
/usr/local/lib/libapr-1.so.4 /usr/local/lib/libaprutil-1.so.3
cheers,
Pedro.
