Description of problem: The libpl.so* files are not packaged. However, they are needed to use the foreign language interface. Version-Release number of selected component (if applicable): pl-5.6.35-1.* How reproducible: Always. Steps to Reproduce: $ rpm -q pl pl-5.6.35-1.fc6 $ rpm -ql pl | fgrep libpl /usr/lib64/pl-5.6.35/lib/x86_64-linux-gnu/libpl.a /usr/share/doc/pl-5.6.35/Manual/libpl.html /usr/share/doc/pl-5.6.35/UserGuide/libplot.html $
The following is from INSTALL.notes: "Doing this causes the Prolog sources to be compiled with -fPIC (position independent code). On some platform this can lead to significant performance degradation. The approach has some advantages and disadvantages: - `stand-alone' executables need the shared object - less performance for most processors + Easier linking, especially for complicated embedded systems" Can you give an example for a module that must be linked against libpl.so?
BTW, the calc.c example from the manual worked without a problem.
Well, there are very good reasons to link libpl dynamically. However, I think there is a misunderstanding: the libpl.so* file are produced by `make' and installed by `make install' anyway, it is just a matter of packaging them. For example, with a /usr/local prefix: $ ls /usr/local/lib/pl-5.6.35/lib/x86_64-linux/ libpl.a libpl.so libpl.so.5.6.35 Perhaps I am misunderstanding you: sorry if that is the case.
The libpl.so* files are only built if --enable-shared is given to configure. The pl executable is then also linked against libpl.so rather than libpl.a. The difference is that libpl.so uses -fPIC and libpl.a does not (-fPIC results in a small performance loss). Also I don't know how well this works on non-i386 platforms.
> The libpl.so* files are only built if --enable-shared is given > to configure. This is not what I observe here: the libpl.so* files are created even if you call `configure' without any option. In other words, the default seems to be `--enable-shared'. > The pl executable is then also linked against libpl.so > rather than libpl.a. The difference is that libpl.so uses -fPIC and > libpl.a does not (-fPIC results in a small performance loss). Also > I don't know how well this works on non-i386 platforms. As far as I know, it works on all the platforms supported by SWI-Prolog. Moreover, the slowdown is negligible. I will ask Jan Wielemaker to enlighten us on this subject.
(In reply to comment #5) > > The libpl.so* files are only built if --enable-shared is given > > to configure. > > This is not what I observe here: the libpl.so* files are created even > if you call `configure' without any option. In other words, the > default seems to be `--enable-shared'. Well, not here. However on x86_64 this seems to be the case. From configure.in: *x86_64*linux) if test "x$MKSHARED" = "x"; then MKSHARED=yes fi In any case, only those files are packaged that are installed by "make install", and libpl.so obviously is not.
>>> The libpl.so* files are only built if --enable-shared is given >>> to configure. >> This is not what I observe here: the libpl.so* files are created even >> if you call `configure' without any option. In other words, the >> default seems to be `--enable-shared'. > Well, not here. However on x86_64 this seems to be the case. >>From configure.in: > *x86_64*linux) > if test "x$MKSHARED" = "x"; then > MKSHARED=yes > fi You are right. > In any case, only those files are packaged that are installed > by "make install", and libpl.so obviously is not. Well, it is on x86_64. So I think we should package libpl.so* conditional to %ifarch x86_64?
(In reply to comment #7) > Well, it is on x86_64. So I think we should package libpl.so* > conditional to %ifarch x86_64? The problem is, why are libpl.so* not installed by "make install"? If the option "--enable-shared" is given, then libpl.so* ARE automatically installed. I am not opposed to build using "--enable-shared", but we should make sure that it is needed and does not have averse effects.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.