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.

Assumably, Seth Vidal is busy at LWCE and FUDCon: http://fedoraproject.org/fudcon/

(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 ;-)

> 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.

(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.  

> 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

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.

possibly related: http://sources.redhat.com/bugzilla/show_bug.cgi?id=679

(Re: comment 8 -> In pl it's STV_HIDDEN visibility, in the linked bug it's
STV_PROTECTED.)

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.

%_lib expands to lib64 on x64_64 arch

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.

> 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.

Oh, and "ExcludeArch: x86_64" for the beginning, since it _did_ built on ppc for
dwmw2 already.

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.

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.

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. 

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. 

Should I set "ExcludeArch" in the spec file and disable Michael's patch for now?

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 ;).

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 

Seems this was fixed some time ago -- closing