DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8867>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8867 expors.c generation fails when using a symlink to the source ------- Additional Comments From [EMAIL PROTECTED] 2003-06-17 14:09 ------- 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
