Dear PPL developpers
I am starting to hack the GCC compiler to enhance it with program wide static analysis. Sebastian Pop suggested me to consider using the PPL library. FWIW, We are both working within the GlobalGCC project (ITEA programme) http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html
May I suggest a tiny enhancenment to PPL (I compiled and install PP 0.9 on Linux/Debian/Sid AMD64 using gcc-4.1.2)?
I did a ./configure, make, sudo make install, and also tried with
My suggestion is to update the build process so that dependencies are recorded in the libppl.so and libppl_c.so shared object ELF files.
Currently I've got
% ldd /usr/local/lib/libppl.so /usr/local/lib/libppl_c.so /usr/local/lib/libppl.so: libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00002b87d3802000) libm.so.6 => /lib/libm.so.6 (0x00002b87d3a04000) libc.so.6 => /lib/libc.so.6 (0x00002b87d3b86000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00002b87d3dc3000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) /usr/local/lib/libppl_c.so: libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00002b1daeca6000) libm.so.6 => /lib/libm.so.6 (0x00002b1daeea8000) libc.so.6 => /lib/libc.so.6 (0x00002b1daf02a000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00002b1daf267000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
The dpkg-buildpackage don't give much better results % ldd **/*.so debian/tmp/usr/lib/libppl.so: libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00002b86acc64000) libm.so.6 => /lib/libm.so.6 (0x00002b86ace66000) libc.so.6 => /lib/libc.so.6 (0x00002b86acfe8000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00002b86ad225000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) debian/tmp/usr/lib/libppl_c.so: libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00002ba7b8ee7000) libm.so.6 => /lib/libm.so.6 (0x00002ba7b90e9000) libc.so.6 => /lib/libc.so.6 (0x00002ba7b926b000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00002ba7b94a8000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) debian/tmp/usr/lib/libpwl.so: libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00002b53ef135000) libm.so.6 => /lib/libm.so.6 (0x00002b53ef337000) libc.so.6 => /lib/libc.so.6 (0x00002b53ef4b9000) libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00002b53ef6f6000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
I believe that libppl_c.so should depend upon libppl.so, which should also depend upon libmpfr.so (of course, version numbers are needed in dependencies). For you information on my system, % ldd /usr/lib/libmpfr.so libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00002af215670000) libc.so.6 => /lib/libc.so.6 (0x00002af2157af000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
To achieve such dependencies you might build the shared libraries with appropriate -l and -rpath flags
See also http://www.tldp.org/HOWTO/Program-Library-HOWTO/index.html http://www.gnu.org/software/libtool/manual.html#Inter_002dlibrary-dependenci...
I do agree that the above dependencies issues are minor, and PPL0.9 seems to be a very good software.
I'm not familiar enough with PPL or libtool to propose a patch. (I guess that recent libtool claim to adress such issues).
A big thanks for your library!
PS please reply to me also, as I don't subscribe to the ppl devel list
Dear PPL developpers
I am starting to hack the GCC compiler to enhance it with program wide static analysis. Sebastian Pop suggested me to consider using the PPL library. FWIW, We are both working within the GlobalGCC project (ITEA programme) http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html
Dear Basile,
we are very glad you are considering the PPL for your work. You can count on our collaboration (to the extent allowed by our limited resources, of course).
May I suggest a tiny enhancenment to PPL (I compiled and install PP 0.9 on Linux/Debian/Sid AMD64 using gcc-4.1.2)?
I did a ./configure, make, sudo make install, and also tried with
There seems to be a missing line in your message at this point.
My suggestion is to update the build process so that dependencies are recorded in the libppl.so and libppl_c.so shared object ELF files.
You are absolutely right. Here is what we get now with a configure, make, make install on the CVS HEAD revision of the library:
$ ldd /usr/local/lib/libppl_c.so linux-gate.so.1 => (0x0058e000) libppl.so.7 => /usr/local/lib/libppl.so.7 (0x00294000) libgmpxx.so.3 => /usr/local/lib/libgmpxx.so.3 (0x00708000) libgmp.so.3 => /usr/local/lib/libgmp.so.3 (0x00430000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00110000) libm.so.6 => /lib/libm.so.6 (0x001fc000) libc.so.6 => /lib/libc.so.6 (0x0058f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00529000) /lib/ld-linux.so.2 (0x009e0000) $ ldd /usr/local/lib/libppl.so linux-gate.so.1 => (0x00b26000) libgmpxx.so.3 => /usr/local/lib/libgmpxx.so.3 (0x00f40000) libgmp.so.3 => /usr/local/lib/libgmp.so.3 (0x00137000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0017d000) libm.so.6 => /lib/libm.so.6 (0x00988000) libc.so.6 => /lib/libc.so.6 (0x004db000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f90000) /lib/ld-linux.so.2 (0x009e0000)
I believe that libppl_c.so should depend upon libppl.so, which should also depend upon libmpfr.so (of course, version numbers are needed in dependencies). For you information on my system, % ldd /usr/lib/libmpfr.so libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00002af215670000) libc.so.6 => /lib/libc.so.6 (0x00002af2157af000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
We do not currently use MPFR even though we have plans to use it to instantiate our implementation of checked numbers (which, in turn, are used to instantiate the BD_Shape, Octagonal_Shape and Interval classes).
I do agree that the above dependencies issues are minor, and PPL0.9 seems to be a very good software.
[...]
A big thanks for your library!
Thanks to you for the bug report. And thanks for the nice words! As I said, please let us know if we can help. Independently from that, if you can give up pointers to further information concerning your project, we will gladly take a look. Do you plan to use the PPL via its C interface?
PS please reply to me also, as I don't subscribe to the ppl devel list
OK. I suggest you subscribe to the ppl-announce mailing list (http://www.cs.unipr.it/mailman/listinfo/ppl-announce): you can check on the archives (http://www.cs.unipr.it/pipermail/ppl-announce/) that it is very quite and brings only messages that are of absolute interest to all PPL users.
Keep the feedback coming! All the best,
Roberto on behalf of the whole team
On 11/15/06, Roberto Bagnara bagnara@cs.unipr.it wrote:
Do you plan to use the PPL via its C interface?
Yes, the C interface will be the only usable interface from GCC, although there are some people that think that an optional part of the compiler, like analyzers and optimizers, could be written in C++.
Sebastian
Sebastian Pop wrote:
On 11/15/06, Roberto Bagnara bagnara@cs.unipr.it wrote:
Do you plan to use the PPL via its C interface?
Yes, the C interface will be the only usable interface from GCC, although there are some people that think that an optional part of the compiler, like analyzers and optimizers, could be written in C++.
OK. Then you will be interested in PPL 0.10 (due to be released around January 2007). While in PPL 0.9 the only abstract domains available through the C interface are C_Polyhedron and NNC_Polyhedron, starting from PPL 0.10 all the domains will be available through all the interfaces (this includes BD_Shape, Octagonal_Shape, the powerset construction and so forth). This is already implemented in the CVS HEAD revision, but we can make snapshot releases if/when you need them. All the best,
Roberto
participants (3)
-
Basile STARYNKEVITCH -
Roberto Bagnara -
Sebastian Pop