Bug 444317 - xsltLibxmlVersion not present on ppc?
xsltLibxmlVersion not present on ppc?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libxslt (Show other bugs)
rawhide
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
http://koji.fedoraproject.org/koji/ta...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-26 21:21 EDT by Tom Lane
Modified: 2013-07-02 23:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-28 18:32:01 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 Tom Lane 2008-04-26 21:21:53 EDT
Say, have you got any idea about the reason for this build failure?

http://koji.fedoraproject.org/koji/taskinfo?taskID=584409

It's dying on an AC_CHECK_LIB(xslt, xsltLibxmlVersion) configure check, which is odd
because the other three platforms got past that just fine before ppc choked.

I last built postgresql in rawhide on 25-March; all was well then, and the changes
in the postgresql SRPM since then are utterly trivial/unrelated, so it seems this has
to be due to some recent change in libxslt.

If necessary I'll crank up a ppc test system and poke into the details, but I thought
you might have a clue where to look.
Comment 1 Daniel Veillard 2008-04-27 04:41:57 EDT
Hum, no. Are you sure it's not just a problem on the build root.
Are you explicitely BuildRequire libxslt (-devel) ?


http://koji.fedoraproject.org/koji/buildinfo?buildID=46679
libxslt-1.1.23-2.fc10 seems to have built fine, ppc included

So I'm inclined to blame either a missing require from the spec (by why
would that work on other arches ?) or a PPC build root problem (which
happen from time to time ...)

Daniel
Comment 2 Daniel Veillard 2008-04-28 11:42:38 EDT
Hum, I'm afraid it's related to a problem in libxslt-1.1.23-2 key patch
it kills the python bindings... Pushing a libxslt-1.1.23-3, hopefully it
will solve this problem

Daniel

*** This bug has been marked as a duplicate of 444455 ***
Comment 3 Tom Lane 2008-04-28 15:21:15 EDT
Unfortunately the fix for 444455 didn't fix this one, so it's not a duplicate.

I've reproduced this on a personal ppc machine, and what I'm seeing in the config.log is

configure:8002: checking for xsltLibxmlVersion in -lxslt
configure:8037: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -Wall -Wmissing-
prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv  -D_GNU_SOURCE -I/usr/include/libxml2    conftest.c -
lxslt  -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm  >&5
/usr/bin/ld: /tmp/ccrnnP3S.o(.text+0xc): unresolvable R_PPC_REL24 relocation against symbol `xsltLibxmlVersion'
/tmp/ccrnnP3S.o: In function `main':
/home/tgl/rpmwork/BUILD/postgresql-8.3.1/conftest.c:41: relocation truncated to fit: R_PPC_REL24 against symbol `xsltLibxmlVersion' defined in .sdata section in 
/usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/libxslt.so
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
configure:8043: $? = 1
configure: failed program was:
| #ifdef __cplusplus
| extern "C"
| #endif
| char xsltLibxmlVersion ();
| int
| main ()
| {
| return xsltLibxmlVersion ();
|   ;
|   return 0;
| }
configure:8061: result: no
configure:8071: error: library 'xslt' is required for XSLT support

Comment 4 Tom Lane 2008-04-28 18:32:01 EDT
Oh ...

[tgl@g3 libxslt-1.1.23]$ grep -r xsltLibxmlVersion .
./libxslt/xslt.c:const int xsltLibxmlVersion = LIBXML_VERSION;

xsltLibxmlVersion is a variable, not a function.  So the question is not so much why it failed as why it ever 
worked.  Obviously this is a bug in the Postgres configure script, not in libxslt --- I suppose some recent 
change in gcc is what exposed it.
Comment 5 Daniel Veillard 2008-04-29 02:58:24 EDT
yes the test is wrong.
In general for portable detection of libxslt use the xslt-config script,
If you want to do a linking based test either declare the item
properly or link against 
  void xsltInit(void)

exported from libxslt/xslt.h

Daniel

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