Bug 247237 - The libpl.so* files are not packaged.
The libpl.so* files are not packaged.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pl (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-06 04:20 EDT by Roberto Bagnara
Modified: 2008-06-16 21:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:48:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roberto Bagnara 2007-07-06 04:20:51 EDT
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
$
Comment 1 Gérard Milmeister 2007-07-06 10:43:11 EDT
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?
Comment 2 Gérard Milmeister 2007-07-06 10:49:20 EDT
BTW, the calc.c example from the manual worked without a problem.
Comment 3 Roberto Bagnara 2007-07-06 11:05:51 EDT
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.
Comment 4 Gérard Milmeister 2007-07-06 11:19:24 EDT
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.
Comment 5 Roberto Bagnara 2007-07-06 11:32:17 EDT
> 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.
Comment 6 Gérard Milmeister 2007-07-06 11:44:56 EDT
(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.
Comment 7 Roberto Bagnara 2007-07-06 13:30:36 EDT
>>> 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?
Comment 8 Gérard Milmeister 2007-07-10 04:14:15 EDT
(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.

Comment 9 Bug Zapper 2008-05-14 09:25:55 EDT
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
Comment 10 Bug Zapper 2008-06-16 21:48:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.