Bug 176668 – beagle fails to compile on FreeBSD

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Roy Marples (RETIRED) 2007-05-01 11:46:00 UTC]

i686-gentoo-freebsd6.2-gcc -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/lib/pkgconfig/../../include/mono-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_THREAD_SAFE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0 -D_THREAD_SAFE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/librsvg-2 -O2 -march=pentium-m -pipe -MT thread-glue.lo -MD -MP -MF .deps/thread-glue.Tpo -c thread-glue.c  -fPIC -DPIC -o .libs/thread-glue.o
thread-glue.c:30:26: error: linux/unistd.h: No such file or directory
gmake[2]: *** [thread-glue.lo] Error 1
gmake[2]: *** Waiting for unfinished jobs....
mv -f .deps/mono-glue.Tpo .deps/mono-glue.Plo
gmake[2]: Leaving directory `/var/tmp/portage/app-misc/beagle-0.2.16.2/work/beagle-0.2.16.2/glue'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/var/tmp/portage/app-misc/beagle-0.2.16.2/work/beagle-0.2.16.2'
gmake: *** [all] Error 2

[Comment 1 Roy Marples (RETIRED) 2007-05-01 11:46:35 UTC]

Created attachment 117835 [details, diff]
Only include <linux/foo.h> for linux systems

[Comment 2 Roy Marples (RETIRED) 2007-05-12 15:01:18 UTC]

Created attachment 119018 [details, diff]
Remove support for posix_fadvise

This FreeBSD specific patch is also needed as our libc does not have posix_fadvise and rapidly fills the beagle logs with this error. I only spotted it because I ran out of space!

This patch was taken from FreeBSD ports.

I don't know if it's possible in C# to #ifdef around it as if we could then the patch wouldn't be OS specific like it is now :/

[Comment 3 Frank Richter 2007-05-27 22:30:53 UTC]

(In reply to comment #2)
> I don't know if it's possible in C# to #ifdef around it as if we could then the
> patch wouldn't be OS specific like it is now :/

It is. C# doesn't have a full-fledged macro preprocessor as C/C++, but it supports conditional compilation. For all the gory details see section 9.5 of ECMA-334.

[Comment 4 Luis Medinas (RETIRED) 2007-07-17 02:52:00 UTC]

Roy there's any bug open on upstream bugzilla ? If not i'll open one to fix this.

[Comment 5 Roy Marples (RETIRED) 2007-07-17 06:44:34 UTC]

No, I've not sent this upstream as it's an OS conditional patch. IE, upstream won't accept it as it stands, hence my call for help in making it unconditional :)

[Comment 6 Cédric Krier 2008-05-18 11:13:23 UTC]

Is it work now with 0.3.6 ?