Mac OS X/Darwin compatibility issues

classic Classic list List threaded Threaded
9 messages Options
Jjgod Jiang Jjgod Jiang
Reply | Threaded
Open this post in threaded view
|

Mac OS X/Darwin compatibility issues

Hi,

When I tried to compile notmuch under Mac OS X 10.6, several issues
arisen:

1. g++ reports 'warning: command line option "-Wmissing-declarations"
is valid for C/ObjC but not for C++'

2.
notmuch-reply.c: In function ‘address_is_users’:
notmuch-reply.c:87: warning: passing argument 2 of
‘notmuch_config_get_user_other_email’ from incompatible pointer type

That's due to the size incompatibility of 'unsigned int' and 'size_t'
(size_t is uint64_t in Mac OS X).

3. Several errors about missing GNU extensions like getline() and strndup():

warning: implicit declaration of function ‘getline’
error: ‘strndup’ was not declared in this scope

We can implement these with fgets() and strncpy() though.

- Jiang

Alexander Botero-Lowry Alexander Botero-Lowry
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Wed, 18 Nov 2009 11:50:17 +0800, Jjgod Jiang <[hidden email]> wrote:
> Hi,
>
> When I tried to compile notmuch under Mac OS X 10.6, several issues
> arisen:
>
> 1. g++ reports 'warning: command line option "-Wmissing-declarations"
> is valid for C/ObjC but not for C++'
>
I got that too. I presume it's newly supported in GCC4.4?

> 3. Several errors about missing GNU extensions like getline() and strndup():
>
strndup from V8:

char* strndup(char* str, size_t n) {
  // Stupid implementation of strndup since macos isn't born with
  // one.
  size_t len = strlen(str);
  if (len <= n)
    return StrDup(str);
  char* result = new char[n+1];
  size_t i;
  for (i = 0; i <= n; i++)
    result[i] = str[i];
  result[i] = '\0';
  return result;
}

> warning: implicit declaration of function ‘getline’
> error: ‘strndup’ was not declared in this scope
>
for getline do you mind trying #define _GNU_SOURCE 1
before #include <stdio.h> in the offending files? The FreeBSD man pages
mentions that as a way of enabling the GNU version of getline().

Alex

Jjgod Jiang Jjgod Jiang
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

Hi,

On Wed, Nov 18, 2009 at 1:45 PM, Alexander Botero-Lowry
<[hidden email]> wrote:
> for getline do you mind trying #define _GNU_SOURCE 1
> before #include <stdio.h> in the offending files? The FreeBSD man pages
> mentions that as a way of enabling the GNU version of getline().

It seems even _GNU_SOURCE is defined, getline is still not present.
the C lib in Mac OS X simply doesn't have it. See also [1].

- Jiang

[1] http://stackoverflow.com/questions/1117108/compiling-c-code-using-gnu-c-getline-on-mac-osx

Alexander Botero-Lowry Alexander Botero-Lowry
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Wed, 18 Nov 2009 14:14:27 +0800, Jjgod Jiang <[hidden email]> wrote:

> Hi,
>
> On Wed, Nov 18, 2009 at 1:45 PM, Alexander Botero-Lowry
> <[hidden email]> wrote:
> > for getline do you mind trying #define _GNU_SOURCE 1
> > before #include <stdio.h> in the offending files? The FreeBSD man pages
> > mentions that as a way of enabling the GNU version of getline().
>
> It seems even _GNU_SOURCE is defined, getline is still not present.
> the C lib in Mac OS X simply doesn't have it. See also [1].
>
Alas. Since it's ostensibly based on the FreeBSD one, I figured there
was a chance that would fix the problem. :/

Carl Worth-2 Carl Worth-2
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

In reply to this post by Jjgod Jiang
On Wed, 18 Nov 2009 11:50:17 +0800, Jjgod Jiang <[hidden email]> wrote:
> 1. g++ reports 'warning: command line option "-Wmissing-declarations"
> is valid for C/ObjC but not for C++'

In cairo, what we do is have a huge list of desired warnings and then
test each one in turn with a test-compile in the configure script.
That's probably what we should do here, (I recently established a
Makefile.config for this purpose that should be generated by the
configure script.)

> 2.
> notmuch-reply.c: In function ‘address_is_users’:
> notmuch-reply.c:87: warning: passing argument 2 of
> ‘notmuch_config_get_user_other_email’ from incompatible pointer type

Thanks for the report. I think I saw a fix for this in a commit from
Chris Wilson that's in my queue. (Though from a quick glance I'm not
sure where the size_t type got started in the code and propagated
throught this part).

> 3. Several errors about missing GNU extensions like getline() and strndup():
>
> warning: implicit declaration of function ‘getline’
> error: ‘strndup’ was not declared in this scope
>
> We can implement these with fgets() and strncpy() though.

Yes. I knew I was "cheating" by using some GNU extensions here. I'm
happy to accept portability patches for these things, but it's hard for
me to get excited about writing them myself.

Care to take a whack at these?

-Carl

Stewart Smith-2 Stewart Smith-2
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Wed, Nov 18, 2009 at 11:27:20PM +0100, Carl Worth wrote:
> Yes. I knew I was "cheating" by using some GNU extensions here. I'm
> happy to accept portability patches for these things, but it's hard for
> me to get excited about writing them myself.
>
> Care to take a whack at these?

http://www.gnu.org/software/gnulib/

could be a partial answer.

We've taken to using it where needed for Drizzle and seems to work fine.
--
Stewart Smith

Alexander Botero-Lowry Alexander Botero-Lowry
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Thu, 19 Nov 2009 10:45:28 +1100, Stewart Smith <[hidden email]> wrote:

> On Wed, Nov 18, 2009 at 11:27:20PM +0100, Carl Worth wrote:
> > Yes. I knew I was "cheating" by using some GNU extensions here. I'm
> > happy to accept portability patches for these things, but it's hard for
> > me to get excited about writing them myself.
> >
> > Care to take a whack at these?
>
> http://www.gnu.org/software/gnulib/
>
> could be a partial answer.
>
Why add yet another dependency for a couple of functions? Especially
considering how notmuch already depends on glib which includes portability
functions for various things.

alex

Stewart Smith-2 Stewart Smith-2
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Wed, Nov 18, 2009 at 04:24:42PM -0800, Alexander Botero-Lowry wrote:

> On Thu, 19 Nov 2009 10:45:28 +1100, Stewart Smith <[hidden email]> wrote:
> > On Wed, Nov 18, 2009 at 11:27:20PM +0100, Carl Worth wrote:
> > > Yes. I knew I was "cheating" by using some GNU extensions here. I'm
> > > happy to accept portability patches for these things, but it's hard for
> > > me to get excited about writing them myself.
> > >
> > > Care to take a whack at these?
> >
> > http://www.gnu.org/software/gnulib/
> >
> > could be a partial answer.
> >
> Why add yet another dependency for a couple of functions? Especially
> considering how notmuch already depends on glib which includes portability
> functions for various things.

The idea with gnulib (at least what we've done with drizzle) is to
just copy the bits you need into the tree. Does work pretty well for
those small things that you just don't need to depend on a giant like
glib for.
--
Stewart Smith

Carl Worth-2 Carl Worth-2
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X/Darwin compatibility issues

On Thu, 19 Nov 2009 16:42:42 +1100, Stewart Smith <[hidden email]> wrote:
>
> The idea with gnulib (at least what we've done with drizzle) is to
> just copy the bits you need into the tree. Does work pretty well for
> those small things that you just don't need to depend on a giant like
> glib for.

Looks like that's the intended mode of usage for gnulib:

        Its components are intended to be shared at the source level, rather
        than being a library that gets built, installed, and linked against.
        Thus, there is no distribution tarball; the idea is to copy files from
        Gnulib into your own source tree.

That does sound like exactly what we need for getting portable
implementations of the few GNU-extension functions we're using here.

So thanks for sharing this.

-Carl