Could you please attach your copy of exports.c?

Thanks!

*** Bug 9490 has been marked as a duplicate of this bug. ***

Could you please attach the broken exports.c?

Thanks!

Created attachment 2159 [details]
Attached it exports.c for Apache 2.0.36 - Same problem found with Apache 2.0.39

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


until:

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

Thanks,

Gary Farley

[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!

Not applicable anymore.
Have a later version installed.

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?

Sorry, didn't change the version to target 2.0.45 in the previous submit.

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.

*** Bug 18635 has been marked as a duplicate of this bug. ***

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)

This problem may also occur when building on NFS. (See bug report #19229).

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";

while(<STDIN>)
{
 if (/^const/)
 {
  chomp;
  if (defined $hash{$_})
  {
   print "/* $hash{$_}: $_ */\n";
  }
  else
  {
   $hash{$_} = $.;
   print "$_\n";
  }
 }
 else
 {
  print;
 }
}

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.

*** Bug 20401 has been marked as a duplicate of this bug. ***

*** Bug 20793 has been marked as a duplicate of this bug. ***

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

*** Bug 20861 has been marked as a duplicate of this bug. ***

*** Bug 20914 has been marked as a duplicate of this bug. ***

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

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.

*** Bug 23577 has been marked as a duplicate of this bug. ***

*** Bug 23225 has been marked as a duplicate of this bug. ***

*** Bug 21718 has been marked as a duplicate of this bug. ***

Created attachment 10090 [details]
Proposed workaround for duplicate definitions in exports.c

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

*** Bug 26458 has been marked as a duplicate of this bug. ***

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? :)

Sometimes nasty, ugly hacks are required to get the ugly police off their
behinds to fix it correctly.  Go Joe!!!!

*** Bug 28166 has been marked as a duplicate of this bug. ***

*** Bug 29994 has been marked as a duplicate of this bug. ***

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

Created attachment 12476 [details]
Proposed change to INSTALL file.

The proper fixes have been backported to the stable branch now, and should make
it into the 2.0.51 release.

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 :)

(revert spam(?) change.
However, I've let it as RESOLVED/LATER with tag MassUpdate because it is really old now)