From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: Nicolas Pitre <nico@cam.org>, git@vger.kernel.org
Subject: Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
Date: Wed, 1 Oct 2008 08:54:58 -0700 [thread overview]
Message-ID: <20081001155458.GF21310@spearce.org> (raw)
In-Reply-To: <20081001034712.GE24513@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Sep 30, 2008 at 01:51:22PM -0700, Shawn O. Pearce wrote:
>
> > Yea, its a bit ugly due to the rats nest of system includes.
> > Right now I don't see how we can include your patch, it breaks a
> > major platform for us. But obviously my "fix" is also bogus and
> > won't get ARM working again.
> >
> > Any other ideas we can try? 'cause I don't have any right now. :-|
>
> I think you have an inherent conflict. Using openssl is going to end up
> including their SHA definition, and we clearly can't include both..
...
> So I think the right way is probably to use a level of indirection. Turn
> the ARM implementation into
>
> void ARM_SHA1_Init()
>
> and
>
> #define SHA1_Init ARM_SHA1_Init
Ick. I agree that renaming our SHA1 implementation to a different
set of symbols is the right solution. But this could cause trouble
in any code that needs both SHA1 implementation and OpenSSL,
especially if a SHA_CTX was passed to a function in another module.
> You can make it even simpler by just having all code call git_SHA1_Init,
> and that will expand to whichever implementation has been chosen.
$ git grep --cached SHA1_Init | wc -l
32
$ git grep --cached SHA1_Final | wc -l
26
$ git grep --cached SHA1_Update | wc -l
39
$ git grep --cached SHA_CTX | wc -l
48
I think its easy enough to just rename our SHA_CTX and SHA_*
functions to something more git specific. Since its mostly a global
s/// we should be able to run it through into master without too
much effort. It would however make merging certain changes from
maint fun, but I think we can handle it until the 1.6.1 release
goes final. We tend not to twiddle SHA1 related code in maint.
Of course this is me speaking... Junio is the one that would be faced
with the brunt of that pain. If it comes down to it I'd be willing
to handle the maint branch and its merges back into master for him.
A funny thing from the above stats... we have 6 SHA1_Init calls
which aren't balanced by a SHA1_Final call. Weird.
--
Shawn.
next prev parent reply other threads:[~2008-10-01 15:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 20:22 [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations Nicolas Pitre
2008-09-30 20:39 ` Shawn O. Pearce
2008-09-30 20:46 ` Nicolas Pitre
2008-09-30 20:51 ` Shawn O. Pearce
2008-10-01 3:47 ` Jeff King
2008-10-01 15:54 ` Shawn O. Pearce [this message]
2008-10-01 16:04 ` Jeff King
2008-10-01 16:10 ` Shawn O. Pearce
2008-10-01 16:35 ` Nicolas Pitre
2008-10-01 16:39 ` Shawn O. Pearce
2008-10-01 18:05 ` [PATCH v2] " Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081001155458.GF21310@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=nico@cam.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).