threads / discuss / 18672

strbuf name conflict on Mac OS

Subject: strbuf name conflict on Mac OS

## tl;dr

5 messages between Mar 31, 2009 and Mar 31, 2009.

replies: 4people: 4as markdown or json

Joshua Juran· Mar 31, 2009, 20:17 UTC · lore

Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its own struct strbuf, with which git's collides.

Since OpenTransport.h also defines some POSIX constants (such as O_NONBLOCK) as enums, it's necessary to include OpenTransport.h from fcntl.h (and other affected headers) so as to control the order in which the definitions appear in the translation unit.

This is the minimal patch:

diff --git a/strbuf.h b/strbuf.h
index 89bd36e..b8f380e 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -40,6 +40,8 @@

  #include <assert.h>

+#define strbuf git_strbuf
+
  extern char strbuf_slopbuf[];
  struct strbuf {
         size_t alloc;


Josh

Johannes Schindelin· Mar 31, 2009, 20:24 UTC · re: Joshua Juran · lore

Re: strbuf name conflict on Mac OS

Hi,

On Tue, 31 Mar 2009, Joshua Juran wrote:

Show 24 quoted lines

> Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its own struct
> strbuf, with which git's collides.
> 
> Since OpenTransport.h also defines some POSIX constants (such as O_NONBLOCK)
> as enums, it's necessary to include OpenTransport.h from fcntl.h (and other
> affected headers) so as to control the order in which the definitions appear
> in the translation unit.
> 
> This is the minimal patch:
> 
> 
> diff --git a/strbuf.h b/strbuf.h
> index 89bd36e..b8f380e 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -40,6 +40,8 @@
> 
> #include <assert.h>
> 
> +#define strbuf git_strbuf
> +
> extern char strbuf_slopbuf[];
> struct strbuf {
>        size_t alloc;

How about this instead?

-- snip --

diff --git a/Makefile b/Makefile
index 32d6782..370c2d9 100644
--- a/Makefile
+++ b/Makefile
@@ -659,6 +659,7 @@ ifeq ($(uname_S),SCO_SV)
 	TAR = gtar
 endif
 ifeq ($(uname_S),Darwin)
+	BASIC_CFLAGS += -Dstrbuf=git_strbuf
 	NEEDS_SSL_WITH_CRYPTO = YesPlease
 	NEEDS_LIBICONV = YesPlease
 	ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
-- snap --

No need to let other platforms (and the C source) suffer...

Ciao,
Dscho

Jay Soffian· Mar 31, 2009, 21:36 UTC · re: Johannes Schindelin · lore

Re: strbuf name conflict on Mac OS

On Tue, Mar 31, 2009 at 4:24 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> How about this instead?
>  ifeq ($(uname_S),Darwin)
> +       BASIC_CFLAGS += -Dstrbuf=git_strbuf

Heh, wrong platform. See Joshua's other message about porting git to Mac OS (not Mac OS X). :-)

j.

Joshua Juran· Mar 31, 2009, 21:57 UTC · re: Jay Soffian · lore

Re: strbuf name conflict on Mac OS

On Mar 31, 2009, at 2:36 PM, Jay Soffian wrote:

Show 8 quoted lines

> On Tue, Mar 31, 2009 at 4:24 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> How about this instead?
>>  ifeq ($(uname_S),Darwin)
>> +       BASIC_CFLAGS += -Dstrbuf=git_strbuf
>
> Heh, wrong platform. See Joshua's other message about porting git to
> Mac OS (not Mac OS X). :-)

That, and I'm not using make. There's no need for this to be any more painful than necessary. :-)

I've added compat/lamp.h, following Brian's suggestion.

Josh

Brian Gernhardt· Mar 31, 2009, 20:26 UTC · re: Joshua Juran · lore

Re: strbuf name conflict on Mac OS

On Mar 31, 2009, at 4:17 PM, Joshua Juran wrote:

Show 7 quoted lines

> Apple's OpenTransport.h from Universal Interfaces 3.4.2 defines its  
> own struct strbuf, with which git's collides.
>
> Since OpenTransport.h also defines some POSIX constants (such as  
> O_NONBLOCK) as enums, it's necessary to include OpenTransport.h from  
> fcntl.h (and other affected headers) so as to control the order in  
> which the definitions appear in the translation unit.

Just to be clear, this is related to your work on LAMP under Classic and not OS X, correct? If so, perhaps you need to create a compat/ classic_mac.h file that's included (when the correct #defines are seen) from git-compat-util.h in the manner of compat/ {cygwin,mingw}.h. I'm assuming that this naming conflict is not the only such you'll find and it's better to keep platform specific tweaks to a single place when possible.

~~ Brian