Bug 8867 - exports.c generation fails when using a symlink to the source
Summary: exports.c generation fails when using a symlink to the source
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Build (show other bugs)
Version: 2.0.46
Hardware: Sun Solaris
: P3 critical with 5 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
: 9490 18635 20401 20793 20861 20914 23225 23577 26458 28166 29994 (view as bug list)
Depends on:
Reported: 2002-05-07 13:10 UTC by Jeff Stavsky
Modified: 2019-02-11 16:34 UTC (History)
16 users (show)

Attached it exports.c for Apache 2.0.36 - Same problem found with Apache 2.0.39 (114.48 KB, text/plain)
2002-06-23 15:42 UTC, Diana
Proposed workaround for duplicate definitions in exports.c (528 bytes, patch)
2004-01-26 17:08 UTC, Joe Orton
Details | Diff
Proposed change to INSTALL file. (519 bytes, patch)
2004-08-18 18:58 UTC, David Eisner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Stavsky 2002-05-07 13:10:08 UTC
I am successful doing configure (without any additional modules) and make with 
httpd 2.0.36. The problem occurs when doing make install. Here is part of the 

exports.c:900: `ap_hack_apr_xml_quote_string' previously defined here
exports.c:2097: redefinition of `ap_hack_apr_xml_quote_elem'
exports.c:901: `ap_hack_apr_xml_quote_elem' previously defined here
exports.c:2098: redefinition of `ap_hack_apr_xml_insert_uri'
exports.c:902: `ap_hack_apr_xml_insert_uri' previously defined here
make: Fatal error: Command failed for target `exports.lo'
Current working directory /aleph1/product/httpd-2.0.36/server
make: Fatal error: Command failed for target `install-recursive'
Current working directory /aleph1/product/httpd-2.0.36/server
make: Fatal error: Command failed for target `install-recursive'

This output is from the gcc command that follows the nawk command:

nawk -f /aleph1/product/httpd-2.0.36/build/make_exports.awk /aleph1/product/http
d-2.0.36/include/*.h  /aleph1/product/httpd-2.0.36/os/unix/*.h  /aleph1/product/
httpd-2.0.36/srclib/apr/include/*.h  /aleph1/product/httpd-2.0.36/srclib/apr-uti
l/include/*.h  /aleph1/product/httpd-2.0.36/modules/http/*.h > exports.c
/bin/bash /aleph1/product/httpd-2.0.36/srclib/apr/libtool --silent --mode=compil
-DAP_HAVE_DESIGNATED_INITIALIZER   -I. -I/aleph1/product/httpd-2.0.36/os/unix -I
/aleph1/product/httpd-2.0.36/server/mpm/prefork -I/aleph1/product/httpd-2.0.36/m
odules/http -I/aleph1/product/httpd-2.0.36/modules/proxy -I/aleph1/product/httpd
-2.0.36/include -I/aleph1/product/httpd-2.0.36/srclib/apr/include -I/aleph1/prod
uct/httpd-2.0.36/srclib/apr-util/include -I/aleph1/product/httpd-2.0.36/modules/
dav/main -I/aleph1/product/httpd-2.0.36/srclib/apr-util/xml/expat/lib -prefer-no
n-pic -static -c exports.c && touch exports.lo

Following is some info on the relevant machine:

ram12=M505>>gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs
gcc version 2.95.2 19991024 (release)
ram12=M505>>uname -a
SunOS ram12 5.8 Generic_108528-03 sun4u sparc SUNW,UltraSPARC-IIi-Engine

Thanks for your coop,
Comment 1 Jeff Trawick 2002-05-14 20:57:52 UTC
Could you please attach your copy of exports.c?

Comment 2 Ryan Bloom 2002-06-14 23:57:16 UTC
*** Bug 9490 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Trawick 2002-06-21 11:41:08 UTC
Could you please attach the broken exports.c?

Comment 4 Diana 2002-06-23 15:42:56 UTC
Created attachment 2159 [details]
Attached it exports.c for Apache 2.0.36 - Same problem found with Apache 2.0.39
Comment 5 Gary Farley 2002-08-23 09:38:48 UTC
I am having a similar problem building 2.0.40 under SGI IRIX 6.5.

My make process does not get as far, and reports the following :

Making all in prefork                                                           
        /bin/sh /data1/local/apache3/srclib/apr/libtool --silent --mode=compile 
cc  -g    -D_POSIX_THREAD_SAFE_FUNCTIONS    -I/data1/local/apache3/srclib/apr/in
clude -I/data1/local/apache3/srclib/apr-util/include -I/data1/local/apache3/srcl
ib/apr-util/xml/expat/lib -I. -I/data1/local/apache3/os/unix -I/data1/local/apac
he3/server/mpm/prefork -I/data1/local/apache3/modules/http -I/data1/local/apache
3/modules/filters -I/data1/local/apache3/modules/proxy -I/data1/local/apache3/in
clude -I/data1/local/apache3/modules/dav/main -prefer-non-pic -static -c exports
.c && touch exports.lo                                                          
cc-1144 cc: ERROR File = exports.c, Line = 1473                                 
  The variable "ap_hack_apr_allocator_create" has already been initialized.     
  const void *ap_hack_apr_allocator_create = (const void *)apr_allocator_create;

MANY MORE ERRORS ALONG THE SAME LINES "already been initialised"....


cc-3452 cc: ERROR File = exports.c, Line = 1635            
  The compilation is aborted due to the number of errors.  
101 errors detected in the compilation of "exports.c".     
*** Error code 1 (bu21)                                    
*** Error code 1 (bu21)                                    
*** Error code 1 (bu21)                                    

It appears that make_exports.awk pulls in a number of header files, some from 
the apr and some from the server subsystems, that have the same objects defined.

I don't know enough about these inclusions to attempt changing them - Please 


Gary Farley

Comment 6 Joshua Slive 2002-10-17 02:35:32 UTC
[This is a mass bug update.]
This bug reports a problem in an older version of Apache 2.
Could you please update to the most recent version and see
if you can reproduce this problem.  If the bug still exists,
please update the bug with the latest version number.  If 
the bug no longer exists, please close the bug report.

Sorry for this impersonal response, but we get many more bug
reports than our volunteers can keep up with.
Thanks for using Apache!
Comment 7 David Clancy 2002-10-24 10:18:29 UTC
Not applicable anymore.
Have a later version installed.
Comment 8 Sulka Haro 2003-04-02 13:05:30 UTC
I'm trying to upgrade to 2.0.45 as per the instructions to do so before 8th and
having the error messages appear under Solaris 8. I'm having no problems
compiling 2.0.39, 2.0.43 and 2.0.44 on the same machine using the exact same
settings so this is new to 2.0.45. I read the changelog and it said there's a
new apr included with the .45, is this related?
Comment 9 Sulka Haro 2003-04-02 13:06:40 UTC
Sorry, didn't change the version to target 2.0.45 in the previous submit.
Comment 10 Sulka Haro 2003-04-07 10:06:49 UTC
Ok I found the cause of the problem.

If the path to Apache source has a symlink, the code that generates exports.c
uses both the absolute path (symlink parsed out) and the path with the symlink
during the generation process. The end result is that some files (namely apr
stuff) is included twice into exports.c.

You can replicate this by downloading the source, decompress the source, then
symlink the source "ln -s httpd-2.0.45 httpd", "cd http", "./configure", "make".
The make fill fail and complain about duplicate apr symbols in exports.c. If you
look at exports.c, you'll see all apr-related files have been included using
both the "httpd-2.0.45" and the "httpd" paths.

It's probably just a line or two that needs to be changed to fix this.
Comment 11 Jeff Trawick 2003-04-08 11:45:07 UTC
*** Bug 18635 has been marked as a duplicate of this bug. ***
Comment 12 Laurent Goujon 2003-04-13 16:23:52 UTC
I've also some problems with Apache 2.0.45. I am trying to build in my home
directory and after some investigations, i've noticed that APR_INCLUDEDIR and
APU_INCLUDEDIR include my home directory twice with two different pathname
(because the users directory are in /users and are also symlinked in /home)
Comment 13 Edin Zulic 2003-04-22 21:20:30 UTC
This problem may also occur when building on NFS. (See bug report #19229).
Comment 14 Beat Mueller 2003-05-23 11:18:45 UTC
On my box the problem is the same. Here my system:
SunOS ife.ee.ethz.ch 5.9 Generic_112233-04 sun4u sparc
gcc 3.2.2 and Forte cc 7.0

I wrote a little perl script that converts the defect exports.c. After applying
this script httpd compiled fine:

#!/usr/bin/perl -w
use strict;
# httpd 2.0.45/server/exports.c
my %hash;       # Zeile -> Nummer
print "/* $0: ", scalar(localtime), " */\n";

 if (/^const/)
  if (defined $hash{$_})
   print "/* $hash{$_}: $_ */\n";
   $hash{$_} = $.;
   print "$_\n";
Comment 15 Robert Dahlem 2003-05-30 09:40:56 UTC
With 2.0.46 this is even messier: Up to 2.0.45 a workaround was
    cd `/bin/pwd -P`
(cd to the physical path) before running configure. This does no longer help.
Comment 16 Jeff Trawick 2003-06-02 13:04:48 UTC
*** Bug 20401 has been marked as a duplicate of this bug. ***
Comment 17 Jeff Trawick 2003-06-16 13:46:15 UTC
*** Bug 20793 has been marked as a duplicate of this bug. ***
Comment 18 Dustin Mitchell 2003-06-17 14:09:01 UTC
This bug still occurs on Solaris 8 with httpd-2.0.46.  It seems that the /bin/sh
builtin version of 'pwd' automatically resolves symlinks.  I do *not* have
'realpath' installed, as indicated might help in apr-config:
# If we have the realpath program, use it to resolve symlinks
# Otherwise, being in a symlinked dir may result in incorrect output.
if test -x "`which realpath 2>/dev/null`"; then
What seems to be happening to cause *both* paths to get included is this:
() $thispath gets set to the symlink-resolved path
() $thispath is compared with $APR_SOURCE_DIR, which is set by configure and is
not symlink-resolved.  While they should match, they do not.
() because of the mismatch, $location is set to 'build' while it should be 'source'.
() checking under the --includes case in the command-line switch, we see that
this choice of $location is interpreted to be a VPATH build, so both
$thisdir/include and $APR_SOURCE_DIR/include are returned, giving duplicate headers.

This is fairly easy to work around by just compiling in /tmp or something.  If
there are issues (beyond this one) with compiling in a symlinked directory,
perhaps a warning in INSTALL or during configure would be enough to resolve this
Comment 19 Joshua Slive 2003-06-18 15:37:33 UTC
*** Bug 20861 has been marked as a duplicate of this bug. ***
Comment 20 Jeff Trawick 2003-06-19 15:04:49 UTC
*** Bug 20914 has been marked as a duplicate of this bug. ***
Comment 21 Andrea Prunic 2003-06-25 23:00:51 UTC
I found out that the problem is also if httpd source dir is in a symlinked 
dir: on Solaris, by default /usr/src is a symlink to /usr/share/src.
So, exports.c makes a problem with duplicate definitiopns, as said.

The solution: have httpd source unpacked freshly in a normal directory, that 
is not a symlink to anything (such as /tmp).
Comment 22 Dustin Mitchell 2003-06-28 17:46:57 UTC
From the autoconf manual:
POSIX 1003.1-2001 requires that pwd must support the `-L' ("logical") and `-P'
("physical") options, with `-L' being the default. However, traditional shells
do not support these options, and their pwd command has the `-P' behavior.

Portable scripts should assume neither option is supported, and should assume
neither behavior is the default. Also, on many hosts `/bin/pwd' is equivalent to
`pwd -P', but POSIX does not require this behavior and portable scripts should
not rely on it.
Perhaps a configure test could be added that tries -L, and uses it where
supported (for example, on Solaris 8!)

Email/comment if you'd like me to do this and submit a patch.
Comment 23 Jeff Trawick 2003-10-10 12:13:25 UTC
*** Bug 23577 has been marked as a duplicate of this bug. ***
Comment 24 Jeff Trawick 2003-10-10 12:41:27 UTC
*** Bug 23225 has been marked as a duplicate of this bug. ***
Comment 25 Joe Orton 2004-01-25 16:03:16 UTC
*** Bug 21718 has been marked as a duplicate of this bug. ***
Comment 26 Joe Orton 2004-01-26 17:08:26 UTC
Created attachment 10090 [details]
Proposed workaround for duplicate definitions in exports.c
Comment 27 Joe Orton 2004-01-26 17:12:10 UTC
Fixing the apr-config problem is difficult, fixing the symptom which causes this
issue is relatively simple though: can someone with the symlinked build problem
try the patch to make_exports.awk attached above, or download the pre-patched
version from: http://people.redhat.com/jorton/misc/make_exports.awk
Comment 28 Michel Gravey 2004-01-27 13:55:54 UTC
*** Bug 26458 has been marked as a duplicate of this bug. ***
Comment 29 Dustin Mitchell 2004-01-31 05:40:30 UTC
Tried the new make_exports.awk it with Apache 2.0.48, again on Solaris 8 (same machine, as a 
matter of fact).  Worked like a champ.  What a nasty, ugly hack!  You're not really going to put that 
into a release, are you? :)
Comment 30 Jeff Trawick 2004-01-31 12:51:02 UTC
Sometimes nasty, ugly hacks are required to get the ugly police off their
behinds to fix it correctly.  Go Joe!!!!
Comment 31 André Malo 2004-04-03 20:39:19 UTC
*** Bug 28166 has been marked as a duplicate of this bug. ***
Comment 32 Joe Orton 2004-07-09 09:51:30 UTC
*** Bug 29994 has been marked as a duplicate of this bug. ***
Comment 33 David Eisner 2004-08-18 18:56:12 UTC
Joe Orton's modifed make_exports.awk fixed the problem for me as well, building
httpd-2.0.50 on Solaris 9.

I wasted some time tracking this down yesterday. It was frustrating. Sulka
discovered the cause of this problem over a year ago. Symlinks are not uncommon,
especially with automounting.  At the very least, perhaps the INSTALL file could
be updated to say "NOTE: Apache will not compile if the sources are located in a
path with a symlink."

Comment 34 David Eisner 2004-08-18 18:58:10 UTC
Created attachment 12476 [details]
Proposed change to INSTALL file.
Comment 35 Joe Orton 2004-09-01 10:23:56 UTC
The proper fixes have been backported to the stable branch now, and should make
it into the 2.0.51 release.
Comment 36 Guido Serra (Zeph) 2012-07-26 11:39:01 UTC
I checked out trunk, and I stepped into the same issue trying to compile it on my laptop with OsX ... the perl hack above solved it, but still, googling I found lot of people with the same issue but they probably never reached the informations in this ticket

I dare to reopen it... feel free to shoot me :)
Comment 37 Christophe JAILLET 2019-02-11 16:34:33 UTC
(revert spam(?) change.
However, I've let it as RESOLVED/LATER with tag MassUpdate because it is really old now)