Created attachment 300756 [details] [review]
[PATCH 1/5] libide: fix "void function should not return a value"

Created attachment 300757 [details] [review]
[PATCH 2/5] build: add llvm-config35 to the list of name of llvm-config

This patch can fix the problem on FreeBSD, but adding a --with- option or providing an environment variable to override the default may be better.

Created attachment 300759 [details] [review]
[PATCH 3/5] libide: don't attach -gnu to the local system type instead of failing

I see the comment in the code, but I don't know the portability problem it says in the uname() call. POSIX standard supports uname().

Created attachment 300761 [details] [review]
[PATCH 4/5] libide: find GNU make via configure instead of hard-coding make

Most GNOME modules require GNU make to build. For example, Makefile.introspection can only be run using GNU make. It will be better if we can provide an option for users to set the make implemetation that they want to use.

Created attachment 300762 [details] [review]
[PATCH 5/5] build: remove -lstdc++

FreeBSD 10 and later uses clang and libc++ by default, so there is no libstdc++. I can build gnome-builder on Linux without using -lstdc++, so I think it can be removed.

Review of attachment 300759 [details] [review]:

This needs to be a valid host triplet for the autoconf --host= or --target= parameter.

Thanks for the patches!

Going to push these now, but we should figure out what the right host triplet is for FreeBSD. It very well might still be -gnu, but I'm not up to date.

According to http://wiki.osdev.org/Target_Triplet, it seems that if we come up with "x86_64-freebsd", we are probably okay.

We use "amd64-portbld-freebsd10.1" or "x86_64-portbld-freebsd10.1" in FreeBSD ports. "amd64-freebsd" (showed by ide-list-devices) is also OK.

We did a bunch of build cleanup in the last couple of weeks, any chance you could test things out and see if they are still working on FreeBSD?

There is a linking failure because sched_getcpu is not available on FreeBSD.

There is a sysctl wrapper function called kinfo_getproc can be used to get the number of CPU that a process run on, but it uses malloc internally. We have to link to libutil to use this function.

static unsigned int egg_get_current_cpu (void)
{
  struct kinfo_proc *proc = kinfo_getproc (getpid ());
  unsigned int cpu = proc->ki_oncpu;
  return cpu;
}

If we want to avoid malloc and linking to libutil, we can use sysctl directly.

static unsigned int egg_get_current_cpu (void)
{
  struct kinfo_proc proc;
  sysctl ((int []){ CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid () },
          4,
          &proc,
          &(size_t){ sizeof (proc) },
          NULL,
          0);
  return proc.ki_oncpu;
}

It seems the default compiler on FreeBSD 10.1, clang 3.4.1, doesn't support __builtin_ia32_rdtscp. Clang 3.5 has this built-in function.

I don't know whether we really want to use sysctl when compilers don't support __builtin_ia32_rdtscp, so I didn't make a patch.

Yeah, we'd want to avoid the syscall altogether. Almost certainly the atomic would be faster. On Linux, sched_getcpu() uses cached information that is updated during scheduler transitions (along with information exported from the vdso). So it was okay to use as a fallback.

For the time being I've just made it fallback to atomics.

There is another error after the sched_getcpu code is disabled:

implicit declaration of function '__sync_fetch_and_add8' is invalid in C99.

Try with 76ed2c3ff7896e8fbadab7a98007807ee99a833c

gnome-builder can be successfully built now.

It crashes when 'unsaved document 1' is closed in a project placed in XDG_DOWNLOAD_DIR.

14:00:03.0655                    GLib-GObject[432164192]:  WARNING: g_object_weak_unref: couldn't find weak ref 0x800a11d80(0x822199480)
**
egg-signal-group:ERROR:egg-signal-group.c:201:egg_signal_group_unbind: assertion failed: (handler->handler_id != 0)

Can you see if commit f6b132576e889c72966f804881052dbc9eb3a679 fixes this for you?

Yes, it is fixed now although I still get some unrelated crashes. There are also some possible glib bugs that prevent gnome-builder tests from passing. (It is expected because glib tests also fail with similar errors.)

Thanks for all fixes!

Lovely. Please file bugs for those if you have time :)