|
|
Blitz Support : |
From: Julian C. Cummings (cummings_at_[hidden])
Date: 2003-09-09 15:58:49
Hi Theo,
> cummings_at_[hidden] said:
> > Not really because of the other problems I mentioned regarding
> > libtool. It doesn't handle passing linker options to the
> C++ compiler
> > correctly, which causes trouble especially when using a
> compiler such
> > as KCC that acts as the linker also. And it replaces standard
> > executables such as the testsuite programs with little
> scripts to run
> > the executables. These scripts don't seem to work on all
> platforms.
> > (I had trouble on AIX.)
>
> The scripts are there so that the application can be executed
> whatever is the place of the libraries (build or install place) and
> executables. This is indeed somewhat troublesome, specially for
> debugging, but these should not be generated when building static
> versions of the stuff. You told us you use -disable-shared to solve
> your problems, so why making it the default (at least until libtool
> is safe enough) is not a proper solution.
I verified that indeed the application scripts are not generated when
support for shared libraries is disabled. So that leaves proper passage of
linker options by libtool to the chosen C++ compiler as the only other
potential problem. I get annoying warnings from libtool when using the SGI
CC compiler, but everything does compile. I need to retest with KCC and see
what the issues are there.
>
> > Besides, you don't need libtool to build
> > blitz as a shared library. It is trivial to add support
> for building
> > a shared version of libblitz to the configure script without using
> > libtool, if anyone actually cares about this.
>
> Believe me, that is not true. Generating the proper combination of
> flags to generate a shared library is non trivial (and non portable
> across various architectures).
>
> Compiling shared libraries is non-trivial and that is why
> libtool has been created (I used to modify automake for that with
> numerous variants for each system). Reporting the bugs to the libtool
> community and having them fixed is IMHO the best solution.
Based upon the large number of e-mails I have seen on the list reporting
problems and hassles with using libtool, I'm not sure I would agree. It
seems like most folks using libtool are also only using gcc, so problems
with using other compilers are not reported. I wonder if they are even
aware of the KCC compiler, for example.
>
> Also, I do not quite remember correctly, but I'm not totally sure
> that I was not obliged to create a dynamic library (independently of
> the CVS repo and it was a good surprise for me when shared lib
> support was added) just because I'm using blitz within some
> other dynamic libraries (I do not recall the details, but if
> I remember correctly some architecture do not allow linking
> static libraries within dynamic ones).
That may well be the case, and for that reason alone, it makes sense not to
abandon support for building blitz as a shared library completely.
I have taken the liberty of updating the blitz configure.in file to disable
shared library support by default, following your suggestion. It can still
be enabled with the --enable-shared option as before. Hopefully, this will
alleviate a large fraction of the pain associated with the relatively new
usage of libtool to support the configure/build of blitz. I did some other
cleanup of this file as well, and some SGI-specific mods. We can revisit
this issue if it seems that libtool is still inhibiting rather than aiding
code portability of blitz.
Regards, Julian C.
Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings_at_[hidden]