|Bill Allombert on Fri, 21 May 2004 13:43:16 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: gp: anal.c more bugs|
On Wed, May 19, 2004 at 10:26:26AM +0200, Karim Belabas wrote: > My tentative patch aimed at implementing easy redistribution of object > files between gp (who needs graphical libraries!) and the libpari. When > I noticed the complications with the -l / -L flags, I stopped halfway, still > hoping to find a good solution. So that the libpari built from CVS was > effectively unusable (2.2.7 is OK). > > I have uninstalled the patch completely for the time being. It's not only a > matter of graphical routines, install() from highlvl.c might need -ldl on a > few systems for instance. -ldl is a corner case, since it is more or less a part of libc. I propose we keep highlevel.o in gp but start moving some functions to libpari. This way we will catch immediately if we break interface barrier (by compiling libpari code with GP specific headers or specific libraries). > P.S: I guess the only sensible solution is to have > > * a "minimal" libpari.so (as it stood in 2.2.7. Not exactly minimal since > more than 50% is specialized algebraic number theory which many users won't > need...). Full backward compatibility for existing programs is a priority, > at least with default Configure settings (--with-gmp is different). We should make sure that if two people compile libpari with two different graphic libary on the same platform they can still run binaries build by the other. It does not seems important today because PARI is seldom used as a real library, but if we want people start to use it that way, we need to give them that sort of warranty. Cheers, Bill.