Bug 87468 - Recent upgrades to glibc cause ld problems for libxml2
Recent upgrades to glibc cause ld problems for libxml2
Status: CLOSED DUPLICATE of bug 86465
Product: Red Hat Linux
Classification: Retired
Component: libxml2 (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-27 02:49 EST by Peter Williams
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Williams 2003-03-27 02:49:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120
Netscape/7.01

Description of problem:
Due to recent uogrades to glibc there are unresolved symbols when linking libxml
during software builds.  This problem can be fixed by rebuilding the libxml2
rpms from the src.rpm and reinstalling.

Version-Release number of selected component (if applicable):
libxml2-2.4.23-1

How reproducible:
Always

Steps to Reproduce:
1.try building a program that uses libxml2
2.
3.
    

Actual Results:  The build failed at the link stage with unresolved symbols in
libxml.

Expected Results:  Successful build.

Additional info:

Caused by recent upgrade to glibc causing the "mangled" names of symbols (e.g.
toupper()) to be changed.  Requires libxml rpm packages to be rebuilt against
the new glibc packages.
Comment 1 Daniel Veillard 2003-03-27 05:05:12 EST
  Hum, I really can't reproduce this, my workstation is a Red Hat 8.0
installation, I downgraded libxml2 and libxslt to the distribution 
versions [*], and ran a test, compiling an linking a small program calling
libxml2 API. This works fine for me, below are all the informations and
logs for the test. I'm also surprized because I would expect, if true
to break for a lot of GNOME developpers and you are the first one to 
report this more than one week after the release. Please make sure 
all your -devel packages are in sync too, run the test below, see if it
fails, if yes please reopen the bug and report back the exact error
message from the linker. If this doesn't fail then that must be something
else, because the test clearly need to link in the XML parser to work
correctly.

Daniel

[*] fetched from an FTP server, i.e. pristine RPMs, not recompiled ones.

[root@paphio tmp]# cat /etc/redhat-release
Red Hat Linux release 8.0 (Psyche)
[root@paphio tmp]# rpm -q glibc
glibc-2.3.2-4.80
[root@paphio tmp]# rpm -q glibc-devel
glibc-devel-2.3.2-4.80
[root@paphio tmp]# rpm -q libxml2
libxml2-2.4.23-1
[root@paphio tmp]# rpm -q libxml2-devel
libxml2-devel-2.4.23-1
[root@paphio tmp]# cat test.c
#include <stdio.h>
#include <string.h>
#include <libxml/tree.h>

const char *xmlstring =
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\
<message direction=\"0\" from=\"UserFrom\" subject=\"\" importance=\"1\"\n\
timestamp=\"11:26:53 am\" >\n\
 <from>\n\
  <contact contactDisplayName=\"UserFrom\" />\n\
 </from>\n\
 <to>\n\
  <contact contactDisplayName=\"UserTo\" />\n\
 </to>\n\
 <body bgcolor=\"#000000\" color=\"#000000\" font=\"Arial\" ><![CDATA[This is an\n\
incoming message]]></body>\n\
</message>\n\
";

int main(void) {
    xmlDocPtr xmlDoc;

    xmlDoc = xmlParseMemory(xmlstring, strlen(xmlstring));
    xmlDocDump( stdout, xmlDoc);
    return(0);
}
[root@paphio tmp]# gcc -o tst `xml2-config --cflags` test.c `xml2-config --libs`
[root@paphio tmp]# ./tst
<?xml version="1.0" encoding="UTF-8"?>
<message direction="0" from="UserFrom" subject="" importance="1"
timestamp="11:26:53 am">
 <from>
  <contact contactDisplayName="UserFrom"/>
 </from>
 <to>
  <contact contactDisplayName="UserTo"/>
 </to>
 <body bgcolor="#000000" color="#000000" font="Arial"><![CDATA[This is an
incoming message]]></body>
</message>
[root@paphio tmp]#
Comment 2 Peter Williams 2003-03-27 09:00:29 EST
This simple test also works for me.  But I get the following error messages from
a program that previously built without problems:

usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(xmlmemory.o): In
function `xmlMemContentShow':
xmlmemory.o(.text+0x4d8): undefined reference to `__ctype_b'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(HTMLparser.o): In
function `htmlParseExternalID':
HTMLparser.o(.text+0x253b): undefined reference to `__ctype_toupper'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(HTMLparser.o): In
function `htmlParseContent':
HTMLparser.o(.text+0x3d80): undefined reference to `__ctype_toupper'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(HTMLparser.o): In
function `htmlParseDocument':
HTMLparser.o(.text+0x43a0): undefined reference to `__ctype_toupper'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(HTMLparser.o): In
function `htmlParseTryOrFinish':
HTMLparser.o(.text+0x4a2f): undefined reference to `__ctype_toupper'
HTMLparser.o(.text+0x4c46): undefined reference to `__ctype_toupper'
/usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../libxml2.a(HTMLparser.o)(.text+0x52e9):
more undefined references to `__ctype_toupper' follow
collect2: ld returned 1 exit status

After I rebuild (using rpmbuild) the libxml packages and reinstall them the
problem goes away.
Comment 3 Daniel Veillard 2003-03-27 10:20:27 EST
Okay, reproduced, the XML parser never uses toupper() but the HTML parser does.
There is 2 ways around the problem:
  1/ either recompile the libraries requiring the __ctype_b symbols like you
     did for libxml2
  2/ or upgrade with the updated version of the glibc fixing that problem
     that you can find at
     ftp://people.redhat.com/jakub/glibc/errata/8.0/

  thanks a lot for the report,

Daniel

*** This bug has been marked as a duplicate of 86465 ***
Comment 4 Peter Williams 2003-03-27 17:58:47 EST
Fix #2 will not work.  This is, in fact, the cause of the problem.  I.e. the
problem did NOT exist until I upgraded to the latest version of glibc.

The way to fix this is for you, Red Hat, to rebuild and reissue rpms for libxml2.
Comment 5 Daniel Veillard 2003-03-27 18:17:31 EST
> Fix #2 will not work.

 Happy to know you know better !

Have you *tried* ? The errata you applied is:
  glibc-2.3.2-4.80
That version fixes the problem in the *errata*:
  glibc-2.3.2-4.80.1

  See "glibc-2.3.2-4.80" != "2.3.2-4.80.1"
and is supposed to exports the symbols missing from the errata.

Don't discard our suggestions. Please do not reopen the
bug without having tried it.

Daniel

*** This bug has been marked as a duplicate of 86465 ***
Comment 6 Peter Williams 2003-03-27 18:32:44 EST
I HAVE installed ALL updates that are available via RHN.

There is no sign of a glibc-2.3.2-4.80.1 on RHN.  Where do I obtain it from?
Comment 7 Daniel Veillard 2003-03-27 19:06:19 EST
  In the answer that you discarded:

>  2/ or upgrade with the updated version of the glibc fixing that problem
>     that you can find at
>     ftp://people.redhat.com/jakub/glibc/errata/8.0/

ftp://people.redhat.com/jakub/glibc/errata/8.0/ lists:

File: glibc-2.3.2-4.80.1.i386.rpm  3162 KB  03/26/2003  04:53:00 PM
File: glibc-2.3.2-4.80.1.i686.rpm  3862 KB  03/26/2003  05:20:00 PM 
File: glibc-2.3.2-4.80.1.src.rpm  12592 KB  03/26/2003  05:20:00 PM  
File: glibc-common-2.3.2-4.80.1.i386.rpm  12020 KB  03/26/2003  04:56:00 PM 
File: glibc-debug-2.3.2-4.80.1.i386.rpm  9194 KB  03/26/2003  04:57:00 PM  
File: glibc-debug-2.3.2-4.80.1.i686.rpm  9087 KB  03/26/2003  05:21:00 PM  
File: glibc-debug-static-2.3.2-4.80.1.i386.rpm  22898 KB  03/26/2003  04:58:00 PM  
File: glibc-devel-2.3.2-4.80.1.i386.rpm  2269 KB  03/26/2003  04:53:00 PM  
File: glibc-profile-2.3.2-4.80.1.i386.rpm  22872 KB  03/26/2003  04:55:00 PM 
File: glibc-utils-2.3.2-4.80.1.i386.rpm  54 KB  03/26/2003  04:58:00 PM

  Is it not on RHN at this point,

Daniel

*** This bug has been marked as a duplicate of 86465 ***
Comment 8 Red Hat Bugzilla 2006-02-21 13:52:23 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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