[Mono-devel-list] [LONG] Any Interest in FreeBSD Patches? Then see attached.

John Merryweather Cooper john_m_cooper at yahoo.com
Fri Jul 16 17:13:33 EDT 2004

On Fri, 2004-07-16 at 13:28, Dick Porter wrote:
> On Fri, 2004-07-16 at 20:47, John Merryweather Cooper wrote:
> > I'm the FreeBSD maintainer for mono and I've finally gotten a
> > reasonable, working mono on FreeBSD (at least on -CURRENT, FreeBSD
> > 5.2).  In the hopes that some of this might get integrated into the next
> > release (and make my job a little easier), I've attached the patches
> > necessary to get Mono 1.0 working.  All of these patches can be had via
> > cvsweb at:
> Thanks for this.
> > # extra-patch-signbit  ONLY NEEDED FOR FREEBSD 4.x
> This one will have to wait for Paolo to get back.
> > # patch-configure
> > #####
> > 
> > The build environment in the FreeBSD Ports system defines two
> > environment variables:  PTHREAD_CFLAGS and PTHREAD_LIBS.  The contents
> > of these two environments vary depending on the FreeBSD version,
> How does this patch impact FreeBSD builders of the tarball?  I'm
> assuming PTHREAD_CFLAGS and PTHREAD_LIBS won't be set automatically for
> them.  Is it possible to have a set of probably-correct defaults, and
> let the ports build override them?

I'm unclear about your reference to "FreeBSD builders of the tarball." 
If you mean package building, then this is handled by the build
environment on Bento, the package building machine.  Bento builds the
binary versions carried on the FTP sites for distribution using the
FreeBSD package system and on CD-ROM/DVD's.

Nevertheless, the educated defaults can be used--PROVIDED that they can
be overridden.  These would be (in pseudo code):

#include <sys/param.h>

/* definitions for -STABLE and really early versions of -CURRENT */
#if (__FREEBSD__version < 500016)
#define PTHREAD_LIBS	-pthread

/* definitions for newer versions of -CURRENT before KSE */
#elif (__FREEBSD__version < 502102)
#define PTHREAD_LIBS	-lc_r

/* definitions for -CURRENT */
#define PTHREAD_CFLAGS	/* empty */
#define PTHREAD_LIBS	-lpthread

These values can always be recovered from /usr/ports/Mk/bsd.port.mk. 
Note that only the first (-STABLE) and last (-CURRENT) choices are
maintained in for ports (such as lang/mono) in the ports tree, but there
are still plenty of people running older -CURRENTs.  However, nobody has
been able to get lang/mono to run on the non-KSE -CURRENTs, so it's a
pretty dead choice.

Since there's considerable development energy on threads in -CURRENT,
expect these flags to change "early and often" on -CURRENT.

> > # patch-ligbc_Makefile.in
> > # patch-ligbc_configure
> > # patch-libgc_dbg_mlc.c
> > # patch-libgc_dyn_load.c
> > # patch-libgc_include_private_gcconfig.h
> > # patch-libgc_ltmain.sh
> > # patch-libgc_os_dep.c
> > # patch-libgc_threadlibs.c
> These patches should be fed upstream to the libgc people, see
> http://www.hpl.hp.com/personal/Hans_Boehm/gc for their site.  The
> mailing list info is at the bottom of that page.  We update to new
> versions of libgc fairly often.

Happily.  :)

> > # patch-ltmain.sh
> ltmain is a generated file (from libtool.)
> > # patch-mono_Makefile.in
> Again, Makefile.in is a generated file, built from Makefile.am.  There
> is no tests directory specified in Makefile.am.

As a general rule, we try to avoid using automake.  So, we take the
configure scripts and *.in files as we find them and patch them to
work.  There's just too much chaos in the auto[tools] stuff--although
there is a strong effort to resolve this chaos for FreeBSD, we're not
there yet.

> - Dick
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040716/b67ccb04/attachment.bin 

More information about the Mono-devel-list mailing list