Bug 1243 - Multiple including of paths.h on AIX 5.1 systems.
Summary: Multiple including of paths.h on AIX 5.1 systems.
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Build system (show other bugs)
Version: 4.4p1
Hardware: All AIX
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_4_7 V_4_6_P2
  Show dependency treegraph
 
Reported: 2006-10-03 04:36 AEST by pirzyk
Modified: 2008-04-04 09:56 AEDT (History)
2 users (show)

See Also:


Attachments
Have configure figure out whether paths.h defines. (2.22 KB, patch)
2007-05-31 17:58 AEST, Darren Tucker
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pirzyk 2006-10-03 04:36:16 AEST
This is due to including paths.h from multiple locations.  It is included via includes.h as well as directly in the following c files:

./auth.c
./clientloop.c
./loginrec.c
./misc.c
./monitor.c
./readpass.c
./session.c
./sftp.c
./ssh-agent.c
./ssh-keygen.c
./ssh-keysign.c
./ssh.c
./sshconnect.c
./sshd.c
./sshpty.c

Removing the following code fragment from the c files allows OpenSSH to compile on AIX:

 #ifdef HAVE_PATHS_H
 # include <paths.h>
 #endif

For reference, here is a compile time error message:

xlc -O2  -I. -I. -I/usr/local/encap/zlib-1.1.4/include -I/usr/local/encap/openssl-0.9.7l/include -I/usr/local/encap/tcp_wrappers-7.6+6/include -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/encap/openssh-4.4p1/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/encap/openssh-4.4p1/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/encap/openssh-4.4p1/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/encap/openssh-4.4p1/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/etc\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/encap/openssh-4.4p1/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c readpass.c
"/usr/include/paths.h", line 50.9: 1506-213 (S) Macro name _PATH_BSHELL cannot be redefined.
"/usr/include/paths.h", line 50.9: 1506-358 (I) "_PATH_BSHELL" is defined on line 322 of defines.h.
"/usr/include/paths.h", line 52.9: 1506-213 (S) Macro name _PATH_CSHELL cannot be redefined.
"/usr/include/paths.h", line 52.9: 1506-358 (I) "_PATH_CSHELL" is defined on line 325 of defines.h.
"/usr/include/paths.h", line 57.9: 1506-213 (S) Macro name _PATH_MAILDIR cannot be redefined.
"/usr/include/paths.h", line 57.9: 1506-358 (I) "_PATH_MAILDIR" is defined on line 359 of defines.h.
Comment 1 Darren Tucker 2006-10-03 19:49:18 AEST
(In reply to comment #0)
> This is due to including paths.h from multiple locations.  It is
> included via includes.h as well as directly in the following c files:

Actually it's not a multiple include, but defines.h redefines the things that paths.h sets.  Removing paths.h isn't really the right way to fix it (we should use the ones provided by the system where possible) but it should indeed be fixed.
Comment 2 Kieron Curtis 2007-05-31 17:08:35 AEST
PATCH #1243: I believe this bug is due to a typo in the "includes.h" file.

Line 52 of includes.h checks for definition of macro HAVE_PATHS when it should in fact be checking for HAVE_PATHS_H
No-where else in the source is any reference made to the the errant name, only the latter. Using the errant name causes the compiler to execute the wrong order of include files and macro definitions.

Errant code in includes.h:
    ...
    #ifdef HAVE_PATHS
    # include <paths.h>
    #endif
    ...

When it should be as follows:
    ...
    #ifdef HAVE_PATHS_H
    # include <paths.h>
    #endif
    ...

This fix allows the compilation to proceed without errors.

Note 1: this problem still exists in openssh-4.6p1.

Note 2: the AIX compiler XLC V6 will cause fatal errors when macros are redefined, whilst XLC V8 will produce warnings. Hence, using later versions of the compiler may "hide" the problem.
Comment 3 Darren Tucker 2007-05-31 17:58:26 AEST
Created attachment 1299 [details]
Have configure figure out whether paths.h defines.

Thanks for the info.  You are correct about line 52 being wrong, and paths.h is probably never pulled in by includes.h.

The question is: since we're trying to move away from includes.h to per-source-file includes, should we fix paths.h, or, since it's effectively not used now, remove it entirely and go for an alternative solution such as this attachment?
Comment 4 Darren Tucker 2007-05-31 17:59:23 AEST
Target next release.
Comment 5 Darren Tucker 2007-06-11 14:48:47 AEST
I have applied the change suggested by Kieron in comment #2 since it's definitely an improvement.  This will be in the next release.

We may do the more involved changes at a later date.

Thanks.
Comment 6 Damien Miller 2008-04-04 09:56:36 AEDT
Close resolved bugs after release.