Bug 149038 - pl fails build on x86_64
pl fails build on x86_64
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pl (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-17 23:11 EST by Warren Togami
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-06 07:55:29 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 Warren Togami 2005-02-17 23:11:45 EST
Description of problem:
pl fails to build on x86_64 because the Makefile installs into /usr/lib instead
of /usr/lib64.  Makefile probably needs patching to work on both archs.

NOTE: This may be the only blocking issue on this package, unless pl is totally
unusable on x86-64 despite being possible to build.  Please be sure to also
increment the Release number of the package with every CVS checkin, especially
when change intervals are not within minutes.

Version-Release number of selected component (if applicable):
pl-5.4.6-4
Comment 1 Gérard Milmeister 2005-02-18 10:48:00 EST
I would prefer to build it for i386 now. I have no means and no experience for
building on x86_64. Maybe someone else can do this? Any idea why there is no
progress in the build requests on
http://www.fedoraproject.org/wiki/Extras_2fFC3Status? I prefer to submit
packages for building when I see the list shrinking.
Comment 2 Michael Schwendt 2005-02-18 11:39:59 EST
Assumably, Seth Vidal is busy at LWCE and FUDCon: http://fedoraproject.org/fudcon/
Comment 3 Thorsten Leemhuis 2005-02-18 14:03:45 EST
(In reply to comment #1)
> I would prefer to build it for i386 now.

That should be no problem. ATM it's possible to simply build for one arch. Later
we maybe need to set ExcludeArch: x86_64 to save time on the build system

> I have no means and no experience for
> building on x86_64. Maybe someone else can do this?

I will when I find time. I looked shortly into it. Seems mandrake is able to
build it for x86_64 so we should also ;-)
Comment 4 Warren Togami 2005-02-18 22:22:20 EST
> That should be no problem. ATM it's possible to simply build for one arch. Later
> we maybe need to set ExcludeArch: x86_64 to save time on the build system

This is not good for the long term.  In order to avoid duplication of SRPMS and
force all packages to be fixed for all archs, we should build all packages from
a common SRPM revision just like it is done for Core.  Seth Vidal has been doing
it this way for now because it is a manual process and easier that way, but this
must change in the future.

In the case of pl, this is supposed to be an easy fix, so if you are unable to
fix it yourself, find someone with x86_64 to do it.  This one should be very
straightforward.
Comment 5 Thorsten Leemhuis 2005-02-20 09:48:47 EST
(In reply to comment #4)
> This is not good for the long term.[...]  Seth Vidal has been doing
> it this way for now because it is a manual process and easier that way, but this
> must change in the future.

++
 
> In the case of pl, this is supposed to be an easy fix, so if you are unable to
> fix it yourself, find someone with x86_64 to do it.  This one should be very
> straightforward.

I'm giving up on this for now. It is no easy fix afaict. At least with my
knowledge I did not manage to fix it -- maybe I'm blind and overlook something. 

Of course we could do an easy fix and put parts ( those from the src/ in the
source) into /usr/lib and the other partrs (those from packages/ in the sourse)
into /usr/lib64 -- but I don't thinks that is the way to go.  
Comment 6 Michael Schwendt 2005-02-20 15:34:27 EST
> In the case of pl, this is supposed to be an easy fix

So far, I don't think this is easy to fix. Unless you happen to know why exactly
it fails here (the object files are compiled as PIC as far as where I verified
them):

plld -shared -L/usr/X11R6/lib64 -export-dynamic  -O3 -pthread
../../src/pl/so-interface.o ../../src/pl/pcecall.o  -L../../src \
-lXPCE /usr/lib/gcc/x86_64-redhat-linux/3.4.2/libgcc.a -L/usr/X11R6/lib64 -lXpm
-ljpeg -lXt -lX11 -lSM -lICE  -o ../../src/pl2xpce.so;
/usr/bin/ld: ../../src/libXPCE.a(object.o): relocation R_X86_64_PC32 against
`lockConstraint' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gcc returned code 256
Comment 7 Michael Schwendt 2005-02-20 15:40:42 EST
Btw, since pl uses an arch-specific sub-directory below /usr/lib/pl-5.4.6/lib,
everything could be installed into /usr/lib instead of %_libdir. There are no
shared libs installed which would need to go into /usr/lib64. So maybe the
libdir patch I checked in is not even needed when the linking problem is fixed.
Comment 8 Michael Schwendt 2005-02-20 15:50:30 EST
possibly related: http://sources.redhat.com/bugzilla/show_bug.cgi?id=679
Comment 9 Michael Schwendt 2005-02-20 16:02:12 EST
(Re: comment 8 -> In pl it's STV_HIDDEN visibility, in the linked bug it's
STV_PROTECTED.)
Comment 10 Gérard Milmeister 2005-02-20 18:31:25 EST
So, instead of %{_libdir} use %{_prefix}%{_lib} throughout. It would be good if
there was a list of the definitions of the rpm macros for i386 and x86_64,
possibly side by side.
Comment 11 Michael Schwendt 2005-02-20 18:35:04 EST
%_lib expands to lib64 on x64_64 arch
Comment 12 Warren Togami 2005-02-21 02:56:24 EST
Did anybody look at Mandrake's reported successful x86-64 SRPM?

In response to Comment #6, when I last tried a build on x86-64 FC3, it built
everything successfully except /usr/lib (installed by make) was not in the list
of %files due to %{libdir} being lib64.  You haven't seen it built successfully?

Beyond this I will go with whatever Michael recommends.  I don't have the time
to work on this anymore.  If Michael recommends just ExclusiveArch: i386 then we
will do that.
Comment 13 Michael Schwendt 2005-02-21 03:05:57 EST
> when I last tried a build on x86-64 FC3, it built
> everything successfully except /usr/lib (installed by make)

Been there, done that. I assume you didn't skim over the build log to see the
earlier error.
Comment 14 Michael Schwendt 2005-02-21 03:07:16 EST
Oh, and "ExcludeArch: x86_64" for the beginning, since it _did_ built on ppc for
dwmw2 already.
Comment 15 Warren Togami 2005-02-21 03:11:14 EST
Crap, I forgot that pl doesn't fail the build when part of it fails.  This is
bad.  Okay "ExcludeArch: x86_64" for now, and keep this bug open.  Investigate
the reported Mandrake package for later.
Comment 16 Michael Schwendt 2005-02-21 03:44:40 EST
Found swi-prolog-5.4.6-1mdk.src.rpm, but they don't build anything
within the 'packages' directory. So, no XPCE and stuff. Took a look at
their i586 rpm, and it's just 1 MB small. Tried to locate an x86_64
rpm, but only found an old swi-prolog-5.2.11-1mdk.x86_64.rpm (built
Fri 17 Sep 2004) where they didn't build anything from 'packages'
directory either. And in there they install into /usr/lib/pl-5.2.11/
which backs up my theory in comment 7.
Comment 17 Thorsten Leemhuis 2005-02-21 03:52:40 EST
Guys, please wait 24h with "ExcludeArch: x86_64"; I'll look into it
this evening. Maybe I can find a way so everything installs to
/usr/lib -- if that's okay for you. 
Comment 18 Thorsten Leemhuis 2005-02-21 13:02:12 EST
Well, I thought I had a new, fresh idea but it also did not work :-( I think we
should follow Warrens suggestion: "ExcludeArch: x86_64" for now, and keep this
bug open. 
Comment 19 Gérard Milmeister 2005-02-21 16:55:37 EST
Should I set "ExcludeArch" in the spec file and disable Michael's patch for now?
Comment 20 Michael Schwendt 2005-02-21 17:14:40 EST
The patch does no harm and does not change the binaries on i386. It just makes
sure that libdir can be set from the outside (which is how I started to try
fixing the reported symptoms before I noticed that it breaks elsewhere ;).
Comment 21 Thorsten Leemhuis 2005-02-23 13:04:28 EST
Well, I got it compiled with the help of dwmw2.

He first suggested to change 
 /* /staff/jan/src/pl/packages/xpce/src/rel/constraint.c */
-COMMON(status) lockConstraint(Constraint c, Any obj);
-COMMON(status) unlockConstraint(Constraint c, Any obj);
+status lockConstraint(Constraint c, Any obj);
+status unlockConstraint(Constraint c, Any obj);
 COMMON(status) executeConstraint(Constraint c, Any obj);

in pl-5.4.6/packages/xpce/src/rel/proto.h ; That helped, now the ld problem (see
comment #6) failed on executeConstraint :-( Changed that, failed elsewhere.
Change five others also and give up.

Then we tried a brute force attack:
sed -i 's!#define COMMON(type) type SO_LOCAL!#define COMMON(type) type!g' \
 pl-5.4.6/packages/xpce/src/*/proto.h

That helps, it compiles fine.

That info just FYI. I don't think it is worth fixing ATM . When I find time and
have nothing other importand things to do I'll try the fix refered in comment #8 
Comment 22 Thorsten Leemhuis 2006-08-06 07:55:29 EDT
Seems this was fixed some time ago -- closing

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