php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #35465 link error "Text relocation remains"
Submitted: 2005-11-29 03:17 UTC Modified: 2005-12-01 02:30 UTC
Votes:18
Avg. Score:3.6 ± 0.9
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:3 (60.0%)
From: rusty at socrates dot berkeley dot edu Assigned: sniper (profile)
Status: Wont fix Package: Compile Failure
PHP Version: 5.1.1 OS: solaris 9
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rusty at socrates dot berkeley dot edu
New email:
PHP Version: OS:

 

 [2005-11-29 03:17 UTC] rusty at socrates dot berkeley dot edu 
Description:
------------
At the final linking stage I get thousands of lines like the following (at the end of this message).  My "configure wrapper" shell script is

configure \
        --prefix=${WWWROOT} \
        --enable-bcmath \
        --enable-inline-optimization \
        --enable-libgcc \
        --enable-track-vars \
        --enable-trans-sid \
        --with-apxs2=/${WWWROOT}/bin/apxs \
        --with-config-file-path=${WWWROOT}/conf \
        --with-gmp \
        --with-ldap=${LOCAL} \
        --with-mysql=${MYSQLROOT} \
        --with-openssl=${LOCAL} \
        --with-tsrm-pthreads

With php 5.0.5 it compiles without a squeek.

Here's the start of the error output; thousands of lines like this (about 94,000) for many/all of the libraries:

Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x570       /local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
<unknown>                           0x574       /local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
<unknown>                           0x578       /local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
<unknown>                           0x57c       /local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
<unknown>                           0x580       /local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-29 09:25 UTC] sniper@php.net 
Does this work:

# rm config.cache
# ./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
# make clean ; make

Also you shouldn't need to use these options because they either don't even exist or configure handles them for you automatically:

--enable-inline-optimization (it's enabled by default)
--enable-libgcc (detected automatically when needed)
--enable-trans-sid (has not existed for years)
--with-tsrm-pthreads (detected automatically)
 [2005-11-29 17:19 UTC] rusty at socrates dot berkeley dot edu 
Yes, it compiles with

./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
 [2005-11-29 22:58 UTC] sniper@php.net 
See also bug #35475
 [2005-11-29 23:35 UTC] rusty at socrates dot berkeley dot edu 
Yes, almost all of my add-on libraries are .a files because long ago I used to have problem with .so ones.  Plus, I like to find out about any missing symbols at compile time, not run time, which was part of the problem I used to have.
 [2005-11-30 09:46 UTC] jorton@php.net 
This is the expected failure from trying to link non-PIC code into a shared library on most platforms.  If you really insist on using a static MySQL library you must rebuild it with -fPIC in CFLAGS.

If it worked previously I'd guess it was only because the static libmysql.a wasn't being found.
 [2005-11-30 10:34 UTC] tony2001@php.net 
Joe, I agree, this is most likely not PHP issue, but I'm still able to reproduce it on Solaris 8 and -fPIC doesn't help.
 [2005-11-30 18:54 UTC] rusty at socrates dot berkeley dot edu 
Would you guys please pull your heads out of your **** and go read bug #35475?  It appears to be a bug in the libtool that you're now using.  It may not be a bug in the PHP code but it certainly is a bug in the PHP *distribution*.

I've wiped and re-extracted the tar files and copied over the libtool.m4 from 5.0.5 to 5.1.1 and am recompiling right now.  I'll add a comment when it finishes.
 [2005-11-30 19:08 UTC] php at fiddaman dot net 
I'm seeing the problem with the IMAP extension which uses the UW IMAP toolkit. Now this toolkit never compiles as a shared object (see http://www.washington.edu/imap/IMAP-FAQs/#6.3)

If Rusty's unusual use of static mysql libraries is a problem, look at the IMAP extension.
 [2005-11-30 20:04 UTC] rusty at socrates dot berkeley dot edu 
5.1.1 compiles if you use the libtool from 5.0.5.  You have to copy over libtool after running configure in the 5.0.5 and 5.1.1 directories.  Do not copy over libtool.m4 from the build directory and then run configure.
 [2005-11-30 20:09 UTC] sniper@php.net 
I would like it if people didn't bogus the reports I've assigned myself..
 [2005-11-30 21:13 UTC] sniper@php.net 
Can you please send me both the one you get with the snapshot I asked you to try and the one you get with 5.0.5.
Send them here: sniper@php.net
 [2005-12-01 02:30 UTC] sniper@php.net 
From GCC manual:

"-mimpure-text suppresses the 'relocations remain against allocatable but non-writable sections' linker error message. 
However, the necessary relocations will trigger copy-on-write, and the shared object is not actually shared across processes. Instead of using -mimpure-text, you should compile all source code with -fpic or -fPIC."

So passing that option in CFLAGS before running configure should eliminate the errors. Libtool is actually FIXED now to do the right thing which it didn't do in e.g. 5.0.5. Best option is to fix your installed libraries PHP links with.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 09:00:01 2025 UTC