[2674] in Kerberos-V5-bugs

home help back first fref pref prev next nref lref last post

pending/382: KRB5-1.0 - extraneous file - src/Makefile

daemon@ATHENA.MIT.EDU (Tom Perrine)
Thu Feb 27 17:00:43 1997

Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: gnats-admin@rt-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, Tom Perrine <tep@SDSC.EDU>
Date: Thu, 27 Feb 1997 13:53:37 -0800
From: Tom Perrine <tep@SDSC.EDU>
To: krb5-bugs@MIT.EDU
Cc: security@SDSC.EDU, workcore@franklin.sdsc.edu


>Number:         382
>Category:       pending
>Synopsis:       KRB5-1.0 - extraneous file - src/Makefile
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Thu Feb 27 16:55:00 EST 1997
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
While I was building KRB5-1.0 for four architectures simultaneously, I
discovered that there is an extra file in the distribution.

The file krb5-1.0/src/Makefile should not be in the distribution, it
should be created by configure.

If you are using 'lndir' to create parallel source trees, before the
configure run, it will happily make a link in each tree to the
original "src/Makefile" file.

Then, when you run configure for each architecture (in my case, in
parallel on multiple machines), the different configure runs will, in
turn, overwrite the original (src/Makefile) file with their own
configure output, instead of creating a new Makefile for each
architecture.

This is normally not a problem, as (it appears), most people build
the parallel source trees using "lndir', then run (configure,make)
cycles for each architecture in turn.

You will also see this problem if you (configure,make) architecture A,
then (configure,make) architecture B, and then try to re-"make"
architecture A again without running configure for A again.

This bug most often results in seemingly random compilation failures,
or the "wrong" C compiler (or compiler arguments) being used.  This is
because when building for multiple architectures, usually the ONLY
differences (if any) are in which compiler and platform-specific
compiler arguments.  If you use the same compiler (and arguments) for
all architectures, (e.g. "gcc"), then you may never notice this
problem.

I finally tracked it down after noticing that a Solaris system was
insisting on using "gcc" instead of "acc", but only in the top-level
"src" dir.

The fix is to "rm krb5-1.0/src/Makefile" after unpacking the archives,
but before running 'lndir'.

-- 
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center 
http://www.sdsc.edu/~tep/     | Voice: +1.619.534.5000
I miss my 36-bit friends: Multics, TOPS-10, and TOPS-20.

home help back first fref pref prev next nref lref last post