patch for freebsd support in drizzle

[Ross M.]

the attached patch gets drizzzle compiling and working on freebsd 7.1. most of the changes are pretty innocuous, fixing compiler/linker flags, quelling compiler warnings, adding missing #includes, ...

./configure must be run with the following env vars set (common on freebsd):
 - LDFLAGS=-L/usr/local/lib
 - CFLAGS='-I/usr/local/include -D__APPLE_CC__'
 - CPPFLAGS='-D__APPLE_CC__'

the __APPLE_CC__ stuff is to fix problems with a couple system header files that use it in math without making sure that it's defined. (bug w/freebsd's headers, unrelated to drizzle.)

non-trivial fixes:
 - freebsd doesn't provide log2. workaround is #define log2(x) (log(x) / M_LN2) when it's not available.
 - gperf needs the -D flag since to quell problems with value hashing collisions
 - lots of UNIV_INTERN attributes needed to be added to the handler interface/code
 - acx_pthread.m4 was putting the linker flags it found for pthreads in to PTHREAD_CFLAGS rather than PTHREAD_LIBS

the one problem i've yet to cleanly overcome is a bad interaction between the mktime autoconf test and some system headers included by drizzle/protobuf. i have left the fix out of the main patch (freebsd.patch) and included it in a separate patch (freebsd_mktime.patch) freebsd.patch can be applied to the drizzle repo, but freebsd_mktime.patch should not be applied. i'm still looking at this issue and will attach an updated patch and ask the list(s) about this one.

linux x86_64 builds cleanly after applying the patch.

make check almost completes without any failures. i'm currently seeing a couple problems related to math that i'm going to look in to and possibly report separately.

[Ross M. (rwmcfa1)]

working on a cleaner patch for this part of things, no luck just yet, thoughts welcomed...

[Brian Aker (brianaker)]

Hi!

This is awesome!

A couple of things:
1) Can you lay out instructions for building on FreeBSD? Which ports
need to be done/etc. I've got a FreeBSD 7.X load on a machine and I
would be happy to add FreeBSD to the list of platforms we compile on
for release (aka... platforms we never break).

2) Instead of patches, can you push a bzr tree up to Launchpad? We
track all patches via LP. It makes for easier integration for us, and
we can always backtrack to find out who did what.

Thanks again!

Cheers,
 -Brian

On Jul 25, 2009, at 3:26 PM, Ross M. wrote:

> Public bug reported:
>
> the attached patch gets drizzzle compiling and working on freebsd 7.1.
> most of the changes are pretty innocuous, fixing compiler/linker
> flags,
> quelling compiler warnings, adding missing #includes, ...
>
> ./configure must be run with the following env vars set (common on
> freebsd):
> - LDFLAGS=-L/usr/local/lib
> - CFLAGS='-I/usr/local/include -D__APPLE_CC__'
> - CPPFLAGS='-D__APPLE_CC__'
>
> the __APPLE_CC__ stuff is to fix problems with a couple system header
> files that use it in math without making sure that it's defined. (bug
> w/freebsd's headers, unrelated to drizzle.)
>
> non-trivial fixes:
> - freebsd doesn't provide log2. workaround is #define log2(x)
> (log(x) / M_LN2) when it's not available.
> - gperf needs the -D flag since to quell problems with value hashing
> collisions
> - lots of UNIV_INTERN attributes needed to be added to the handler
> interface/code
> - acx_pthread.m4 was putting the linker flags it found for pthreads
> in to PTHREAD_CFLAGS rather than PTHREAD_LIBS
>
> the one problem i've yet to cleanly overcome is a bad interaction
> between the mktime autoconf test and some system headers included by
> drizzle/protobuf. i have left the fix out of the main patch
> (freebsd.patch) and included it in a separate patch
> (freebsd_mktime.patch) freebsd.patch can be applied to the drizzle
> repo,
> but freebsd_mktime.patch should not be applied. i'm still looking at
> this issue and will attach an updated patch and ask the list(s) about
> this one.
>
> linux x86_64 builds cleanly after applying the patch.
>
> make check almost completes without any failures. i'm currently
> seeing a
> couple problems related to math that i'm going to look in to and
> possibly report separately.
>
> ** Affects: drizzle
> Importance: Undecided
> Status: New
>
>
> ** Tags: freebsd
>
> --
> patch for freebsd support in drizzle
> https://bugs.launchpad.net/bugs/404687
> You received this bug notification because you are a member of
> Drizzle-
> developers, which is subscribed to Drizzle.
>
> Status in A Lightweight SQL Database for Cloud and Web: New
>
> Bug description:
> the attached patch gets drizzzle compiling and working on freebsd
> 7.1. most of the changes are pretty innocuous, fixing compiler/
> linker flags, quelling compiler warnings, adding missing
> #includes, ...
>
> ./configure must be run with the following env vars set (common on
> freebsd):
> - LDFLAGS=-L/usr/local/lib
> - CFLAGS='-I/usr/local/include -D__APPLE_CC__'
> - CPPFLAGS='-D__APPLE_CC__'
>
> the __APPLE_CC__ stuff is to fix problems with...

[Ross M. (rwmcfa1)]

On Sat, Jul 25, 2009 at 4:39 PM, Brian Aker<email address hidden> wrote:
> Hi!

hello.

> This is awesome!

sweet. glad you think so too.

> A couple of things:
> 1) Can you lay out instructions for building on FreeBSD? Which ports
> need to be done/etc. I've got a FreeBSD 7.X load on a machine and I
> would be happy to add FreeBSD to the list of platforms we compile on
> for release (aka... platforms we never break).

might take me a bit to get to a clean enough system so that i can work
through the complete requirements. you want that in something like
README.FreeBSD or just emailed here?

> 2) Instead of patches, can you push a bzr tree up to Launchpad? We
> track all patches via LP. It makes for easier integration for us, and
> we can always backtrack to find out who did what.

libdrizzle fixes pushed to:
   https://code.launchpad.net/~rwmcfa1/+junk/libdrizzle-freebsd
drizzle fixes pushed to:
   https://code.launchpad.net/~rwmcfa1/+junk/drizzle-freebsd

let me know if that's not a correct/workable location. i read the
launchpad stuff before i saw the one pointed to by the README.

> Thanks again!

np.

--
-rm

[Brian Aker (brianaker)]

Hi!

On Jul 25, 2009, at 8:49 PM, Ross M. wrote:

> might take me a bit to get to a clean enough system so that i can work
> through the complete requirements. you want that in something like
> README.FreeBSD or just emailed here?

That would be great.

Cheers,
 -Brian

[Monty Taylor (mordred)]

Ross M. wrote:
> Public bug reported:
>
> the attached patch gets drizzzle compiling and working on freebsd 7.1.
> most of the changes are pretty innocuous, fixing compiler/linker flags,
> quelling compiler warnings, adding missing #includes, ...

Fantastic. Working through it right now.

> ./configure must be run with the following env vars set (common on freebsd):
> - LDFLAGS=-L/usr/local/lib
> - CFLAGS='-I/usr/local/include -D__APPLE_CC__'
> - CPPFLAGS='-D__APPLE_CC__'
>
> the __APPLE_CC__ stuff is to fix problems with a couple system header
> files that use it in math without making sure that it's defined. (bug
> w/freebsd's headers, unrelated to drizzle.)

K. I'm going to put __APPLE_CC__ in as a define into config.h if the
platform in FreeBSD ... does that sound reasonable? I also have a thing
that adds -L/usr/local/lib -I/usr/local/include to the paths on Solaris
- but only if those variables are unset in the environment. Would you
like me to add FreeBSD to the mix on that setting? Or is it fine to
leave it as is (I always strive for ./configure to work without env vars...)

> non-trivial fixes:
> - freebsd doesn't provide log2. workaround is #define log2(x) (log(x) / M_LN2) when it's not available.

K. That seems sensible. You also added an include for math.h into
handler.cc - but it's already in global.h. Did this actually solve
something for you? If so, I'd like to figure out why the include from
global.h didn't work.

BTW- log2 is supposedly C99 - are we perhaps not triggering C99 support
properly? Or is this just a FreeBSD bug?

> - gperf needs the -D flag since to quell problems with value hashing collisions

K

> - lots of UNIV_INTERN attributes needed to be added to the handler interface/code

K. Were these making compile/link problems on FreeBSD?

> - acx_pthread.m4 was putting the linker flags it found for pthreads in to PTHREAD_CFLAGS rather than PTHREAD_LIBS

So that's intentional and the flags that are going in to PTHREAD_CFLAGS
are ones that are compiler flags (like '-pthread' or -mt) not linker
flags. It _should_ be putting -lpthread and the like in PTHREAD_LIBS
already. What was the symptom? Also, PTHREAD_LIBS should have been added
to the global LIBS, so adding it to client_drizzleslap_LDADD directly
shouldn't be required. I'm guessing something broke here, of course...

Aha! We were adding PTHREAD_CFLAGS to AM_CFLAGS and not AM_CXXFLAGS.
Doh. Wow, I wonder what all that broke... I've added a fix for that...

> the one problem i've yet to cleanly overcome is a bad interaction
> between the mktime autoconf test and some system headers included by
> drizzle/protobuf.

The mktime test makes me want to kill someone.

> i have left the fix out of the main patch
> (freebsd.patch) and included it in a separate patch
> (freebsd_mktime.patch) freebsd.patch can be applied to the drizzle repo,
> but freebsd_mktime.patch should not be applied. i'm still looking at
> this issue and will attach an updated patch and ask the list(s) about
> this one.

I'll go look at that next.

> linux x86_64 builds cleanly after applying the patch.

gnulib/getopt.c:
 It's a file provided by gnulib, so I'd like to not patch it if we can....

[Ross M. (rwmcfa1)]

On Sun, Jul 26, 2009 at 12:24 PM, Monty Taylor<email address hidden> wrote:

>> ./configure must be run with the following env vars set (common on freebsd):
>>  - LDFLAGS=-L/usr/local/lib
>>  - CFLAGS='-I/usr/local/include -D__APPLE_CC__'
>>  - CPPFLAGS='-D__APPLE_CC__'
>>
>> the __APPLE_CC__ stuff is to fix problems with a couple system header
>> files that use it in math without making sure that it's defined. (bug
>> w/freebsd's headers, unrelated to drizzle.)
>
> K. I'm going to put __APPLE_CC__ in as a define into config.h if the
> platform in FreeBSD ... does that sound reasonable? I also have a thing
> that adds -L/usr/local/lib -I/usr/local/include to the paths on Solaris
> - but only if those variables are unset in the environment. Would you
> like me to add FreeBSD to the mix on that setting? Or is it fine to
> leave it as is (I always strive for ./configure to work without env vars...)

the __APPLE_CC__ work-around seems good/reasonable, though it's a bug
in freebsd that i'll probably try and submit otherwise.

the -L additions would be nice, especially if they're already there
for solaris. might as well enable them for FreeBSD too.

>> non-trivial fixes:
>>  - freebsd doesn't provide log2. workaround is #define log2(x) (log(x) / M_LN2) when it's not available.
>
> K. That seems sensible. You also added an include for math.h into
> handler.cc - but it's already in global.h. Did this actually solve
> something for you? If so, I'd like to figure out why the include from
> global.h didn't work.
>
> BTW- log2 is supposedly C99 - are we perhaps not triggering C99 support
> properly? Or is this just a FreeBSD bug?

it's probably just the first thing i tried to get at log2 before i
realized that FreeBSD doesn't define it. it does have 'long double
log2l(long double)', but not log2 so i guess it goes in to the
category of oversight.

>>  - lots of UNIV_INTERN attributes needed to be added to the handler
> interface/code
>
> K. Were these making compile/link problems on FreeBSD?

yeah, there were complaints about mis-matches between attributes

>>  - acx_pthread.m4 was putting the linker flags it found for pthreads
> in to PTHREAD_CFLAGS rather than PTHREAD_LIBS
>
> So that's intentional and the flags that are going in to PTHREAD_CFLAGS
> are ones that are compiler flags (like '-pthread' or -mt) not linker
> flags. It _should_ be putting -lpthread and the like in PTHREAD_LIBS
> already. What was the symptom? Also, PTHREAD_LIBS should have been added
> to the global LIBS, so adding it to client_drizzleslap_LDADD directly
> shouldn't be required. I'm guessing something broke here, of course...

PTHREAD_LIBS was empty in the Makefile unless i changed PTHREAD_CFLAGS
to _LIBS. so whether it was added to the LDADD or specifically to the
necessary app it wasn't helping anything.

> Aha! We were adding PTHREAD_CFLAGS to AM_CFLAGS and not AM_CXXFLAGS.
> Doh. Wow, I wonder what all that broke... I've added a fix for that...

cool.

>> the one problem i've yet to cleanly overcome is a bad interaction
>> between the mktime autoconf test and some system headers included by
>> drizzle/protobuf.
>
> The mktime test makes me want to kill someone.

yeah. i'v...

[Ross M. (rwmcfa1)]

On Sun, Jul 26, 2009 at 12:24 PM, Monty Taylor<email address hidden> wrote:

> gnulib/getopt.c:
>  It's a file provided by gnulib, so I'd like to not patch it if we can.
> Was the char *const *argv breaking FreeBSD? (Don't, btw, get me started
> on why _getopt_internal doesn't take char *const *argv itself. sloppy)

...
g-prototypes -Wredundant-decls -Wmissing-declarations -Wcast-align
-I/usr/local/include -D__APPLE_CC__ -MT getopt.lo -MD -MP -MF
.deps/getopt.Tpo -c getopt.c -fPIC -DPIC -o .libs/getopt.o
getopt.c:1115: error: conflicting types for 'rpl_getopt'
getopt.h:205: error: previous declaration of 'rpl_getopt' was here
*** Error code 1

there doesn't seem to be a way around it :( i guess the freebsd
version of gcc is more particular, which we've seen at work.)

--
-rm

[Monty Taylor (mordred)]

Ross M. wrote:
> On Sun, Jul 26, 2009 at 12:24 PM, Monty Taylor<email address hidden>
> wrote:
>
>> gnulib/getopt.c:
>> It's a file provided by gnulib, so I'd like to not patch it if we can.
>> Was the char *const *argv breaking FreeBSD? (Don't, btw, get me started
>> on why _getopt_internal doesn't take char *const *argv itself. sloppy)
>
> ...
> g-prototypes -Wredundant-decls -Wmissing-declarations -Wcast-align
> -I/usr/local/include -D__APPLE_CC__ -MT getopt.lo -MD -MP -MF
> .deps/getopt.Tpo -c getopt.c -fPIC -DPIC -o .libs/getopt.o
> getopt.c:1115: error: conflicting types for 'rpl_getopt'
> getopt.h:205: error: previous declaration of 'rpl_getopt' was here
> *** Error code 1
>
> there doesn't seem to be a way around it :( i guess the freebsd
> version of gcc is more particular, which we've seen at work.)

Fantastic. Utterly fantastic. K. I'll pull in that patch too. Thanks!

[Jay Pipes (jaypipes)]

Fixes already merged into my captain branch...should be into trunk today.

[Ross M. (rwmcfa1)]

On Tue, Jul 28, 2009 at 1:32 PM, Jay Pipes<email address hidden> wrote:
> Fixes already merged into my captain branch...should be into trunk
> today.

awesome!!!

--
-rm

[Ross M. (rwmcfa1)]

On Tue, Jul 28, 2009 at 1:32 PM, Jay Pipes<email address hidden> wrote:
> Fixes already merged into my captain branch...should be into trunk
> today.
>
> ** Changed in: drizzle
>   Importance: Undecided => Medium
>
> ** Changed in: drizzle
>       Status: New => Fix Committed
>
> ** Changed in: drizzle
>    Milestone: None => aloha
>
> ** Changed in: drizzle
>     Assignee: (unassigned) => Monty Taylor (mordred)

i've had a chance to look more closely at the merges. most of the
fixes mentioned in this bug went in to Monty's branch earlier enough
to be in the merge, but the final piece, the gnulib mktime fixes,
didn't make the cut. not sure what, if anything, that means for this
bug, but just wanted to add the note.

best,
--
-rm