evil build problems with cyrus-sasl-2.1.21

Bernard Leak bernard at brenda-arkle.demon.co.uk
Tue Aug 29 10:27:59 EDT 2006


Dear List,
                  I'd hoped to look over the mailing-list archives and 
current CVS source
before this point, but I haven't been able to see the archives yet 
(something seems
to be misconfigured - I've send a message to the Responsible Parties).
It is therefore quite possible that this duplicates even more of other 
people's
work than I currently suspect, and that it has already been broken by
subsequent development.  Anyway, here is a patch based on
the 2.1.21 release. 

I contrived to re-discover all by myself the
SASL_DB_BACKEND_STATIC_SRC{,S}
problem: I understand a patch for this is already floating around.
I haven't tried to separate out this change, as I don't know what
else the other patch may do.

There's a long back-history of people having trouble with builds from
$(SASL_STATIC_SRCS), typically failing with a complaint that sasldb.o
doesn't exist and can't be built.  Quaintly, the problem goes away when
trying to reproduce it - 'make' completes with no related problems.
I believe I have a proper repair for this, and hope nobody has beaten
me to it!

The existing Makefile unfortunately tries to 'build' the objects by
first building a 'linksrcs' pseudo-target which creates
symlinks to these source files.
Unfortunately, it seems to want to inherit the build rules for
making the objects from the sources, but providing an explicit
rule for these cases over-rides it.  The rule must not try to go
straight from the original source files to the object files (unless
it duplicates the source-to-object rules, in which case there would
be no need for the symlinks anyway).  If 'make' is invoked again,
then the usual .c.o rule seems to apply (I ought to be able to
work out when and why and how, but for the moment the
mechanism escapes me).

What's needed is to define the symlinks as a target, and then
the usual .c.o rule applies to these (without invoking 'make' again!).
Thus, we replace

$(SASL_STATIC_OBJS): linksrcs

linksrcs:
    -ln -s $(SASL_STATIC_SRCS) .

with

$(SASL_STATIC_OBJS): $(SASL_STATIC_SRCS)
 
$(SASL_STATIC_SRCS) :
    -if test -e "$@" ; then true ; \
    elif test -f ../plugins/"$@" ; then ln -s ../plugins/"$@" . ; \
    elif test -f ../sasldb/"$@" ; then ln -s ../sasldb/"$@" . ; \
    else false ; \
    fi

where SASL_STATIC_SRCS is now defined with bare source file-names,
not paths.

The rest of the changes are all about removing the directory paths
from the shell variable SASL_STATIC_SRCS inside 'configure'.

As I'm patching a release, the patch includes configure and Makefile.in :
of course, as a "true" source patch it should generate these, but it's
surely harmless.  Almost needless to say, the patch does make the
necessary changes to configure.in and Makefile.am too.
I'm actually too lazy to work out which of the m4 files is derived from
which (or whether they are really as full of duplication as they seem).
So I've patched the lot.

The 2-line offset in one of the hunks is the result of previously applying
another (independent) patch.  It hardly seems worth correcting, since
the sources to which it will be applied have doubtless changed anyway.

                                                                Bernard 
Leak.









The

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-sasl-2.1.21-bl12-1.patch
Type: text/x-patch
Size: 16356 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/cyrus-sasl/attachments/20060829/820ec425/cyrus-sasl-2.1.21-bl12-1.bin


More information about the Cyrus-sasl mailing list