Re: [Haskell] Announce: The Haskell Platform 2011.4
Hello there, On Sat, Dec 17, 2011 at 10:04 PM, Don Stewart don...@gmail.com wrote: We're pleased to announce the release of the Haskell Platform: a single, standard Haskell distribution for everyone. Download the Haskell Platform 2011.4.0.0: http://haskell.org/platform/ The specification, along with installers (including Windows, Apple and Unix installers for a full Haskell environment) are available. The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. What you get is specified here: http://hackage.haskell.org/platform/contents.html For your information, it is available for FreeBSD as well. Though note that the corresponding ports can be only found at our GitHub repository for now: https://github.com/freebsd-haskell/freebsd-haskell/ In order to use the ports from this repository, you will have to install and configure portshaker(8). For further details, see the README file in the repository. After merging the ports trees, Haskell Platform can be installed by the following command: # cd /usr/ports/devel/hs-haskell-platform/ make install clean or updated in the conventional way, e.g. by portmaster(8) (together with other Haskell ports): # portmaster -r ghc They are published this way, because the FreeBSD Ports Collection is only partially thawed (large-scale changes, like updating core Haskell packages or GHC, are still not allowed) due to the on-going release cycle for FreeBSD 9.0. On behalf of the FreeBSD Haskell Team, Gabor ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Using customised usernames in ports
Hi all,
Since we've stopped using pkg-install scripts and started using USERS=
and GROUPS= to create users and groups we've lost the ability to
provide an alternative username/groupname for the port to install
with.
It's still possible to do for a port (ex postgresql):
PG_USER?= pgsql
USERS= ${PG_USER}
but if PG_USER is set to something different, a new line in
/usr/ports/UIDs must be added to match it, and put back every time the
port is upgraded.
The patch at [1] will allow a username already existing on the system
to be used instead, so it'll be easy enough for the end user to create
the user and group then set the PG_USER (or whatever) in make.conf,
and packages will also be built using the correct user.
Thanks to brooks@ for pointing out the use of getent.
Comments?
Chris
[1] http://www.bayofrum.net/~crees/patches/bsd-port-mk-users-existing.diff
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: x11/xcb-util downgraded?
On Sat, 17 Dec 2011 11:18:04 + Chris Rees cr...@freebsd.org wrote: On 17 December 2011 10:47, Denise H. G. darc...@gmail.com wrote: Hi all With the version bump of x11/xcb-util, some ports seems to be broken. However, after recompiling x11/startup-notification, and all the ports that depend on x11/startup-notification, everything will be OK. And x11/startup-notification needs to be set to depend on x11/xcb-util, whose library is 'xcb-util.0' insead of 'xcb-aux.o'startup-notification Hope this will work. Thanks for reporting-- this problem is known [1] and affects many ports. A 'proper' solution will come soon! Chris Hmm, could this be why my attempt to upgrade claws-mail just now failed with: libtool: link: cannot find the library `/usr/local/lib/libxcb-aux.la' or unhandled argument `/usr/local/lib/libxcb-aux.la' gmake[4]: *** [claws-mail] Error 1 I checked and libxcb-aux.la indeed does not exist, although I did find an old *.so version under /usr/local/lib/compat/pkg. OK, I just rebuilt all of my *xcb* ports after making the suggested changes in x11/startup-notification and, sure enough, claws-mail now compiles successfully. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg_version and portversion: ports version comparison weirdness
Can anyone explain why I'm seeing the following? libX11-1.4.99.1needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg_version and portversion: ports version comparison weirdness
On 12/18/2011 17:43, Conrad J. Sabatier wrote: Can anyone explain why I'm seeing the following? libX11-1.4.99.1needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? That's the point of the ,1 ... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pypy-1.7
Hi All, As of 2011/12/13 pypy-1.7 is in ports (under lang/pypy, thanks lwhsu@). Please uninstall pypy-1.6 before building pypy-1.7, there is a memory leak in pypy-1.6 that prevents it from translating pypy-1.7. For those that are interested, there is a TODO list [1] and the WIP repository for pypy it at github [2]. Contributions are very welcome! Regards David [1] https://github.com/DragonSA/pypy/blob/master/TODO [2] https://github.com/DragonSA/pypy signature.asc Description: This is a digitally signed message part.
Re: pkg_version and portversion: ports version comparison weirdness
On Sun, Dec 18, 2011 at 8:43 AM, Conrad J. Sabatier conr...@cox.net wrote: Can anyone explain why I'm seeing the following? libX11-1.4.99.1 needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? Yes. When epoch increments it starts the versioning all over. Largest epoch value ALWAYS is considered newer that any smaller epoch value, regardless of the rest of the version number. Epoch is normally used when a port needs to be rolled back to an older version due to a serious problem caused by the newer version. E.g. xcb-utils-3.6 broke a LOT of stuff, so the epoch was bumped to 1 and the version was set back to 3.6. Once a port has an epoch applied, it will never be removed. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg_version and portversion: ports version comparison weirdness
On Sun, 18 Dec 2011 10:06:48 -0800 Kevin Oberman kob6...@gmail.com wrote: On Sun, Dec 18, 2011 at 8:43 AM, Conrad J. Sabatier conr...@cox.net wrote: Can anyone explain why I'm seeing the following? libX11-1.4.99.1 needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? Yes. When epoch increments it starts the versioning all over. Largest epoch value ALWAYS is considered newer that any smaller epoch value, regardless of the rest of the version number. I suspected that was the case, but wasn't sure exactly how the epoch setting was intended to be used. Epoch is normally used when a port needs to be rolled back to an older version due to a serious problem caused by the newer version. E.g. xcb-utils-3.6 broke a LOT of stuff, so the epoch was bumped to 1 and the version was set back to 3.6. Once a port has an epoch applied, it will never be removed. Ah, OK. Thank you. I had never really understood the meaning of the PORTEPOCH variable. Nice to finally have it explained. Regards, Conrad -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RUN_DEPENDS for python based port
On Sat, Dec 17, 2011 at 3:23 AM, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:
Chris and Matthew already noted what the problems are.
I also suggest to use:
${PYTHON_PKGNAMEPREFIX}yaml=0:${PORTSDIR}/devel/py-yaml
That is much cleaner. Thank you.
So USE_PYTHON=yes should be changed with USE_PYTHON= 2.6-2.7, (otherwise
port build will fail with python3) and LICENSE= ASL worth to be added.
Also added.
I've attached an archive including all the port files (distinfo,
pkg-plist, etc) for any other feedback you can offer. I still have two
remaining issues on my checklist that perhaps the group can provide
solutions for as well.
1) Building the port never successfully fetches the upstream .tar.gz,
but if I copy/paste the URL and run fetch manually it works just fine.
Thoughts?
2) The existing setup.py installs the two config files
(etc/salt/{master,minion}) to /usr/etc instead of /usr/local/etc. I'm
not familiar enough with setup.py to tweak that. Any suggestions
there?
If I can get those last few things figured out I'll submit the port.
Thanks,
Christer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
help with man pages
The port I'm working on includes about a half-dozen man pages which I
understand I need to use MANn to install. What I guess I don't fully
understand is how to path those files. If the files are found in the
extracted source under source-version/doc/man/ should I use:
MAN1= doc/man/manpage.1
MAN7= doc/man/manpage.7
...etc...
or do I need to reference ${WORKSRC}/doc/man/ ?
Do I also need to install the man pages in do-install?
${INSTALL_MAN} ${WRKSRC}/doc/man/manpage.1 ${PREFIX}/man/man1
Appreciate the help
Christer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: help with man pages
On Sun, Dec 18, 2011 at 6:30 PM, Christer Edwards
christer.edwa...@gmail.com wrote:
The port I'm working on includes about a half-dozen man pages which I
understand I need to use MANn to install. What I guess I don't fully
understand is how to path those files. If the files are found in the
extracted source under source-version/doc/man/ should I use:
MAN1= doc/man/manpage.1
MAN7= doc/man/manpage.7
...etc...
or do I need to reference ${WORKSRC}/doc/man/ ?
MANn takes the place of adding entries to the plist (allowing for the
use of MANCOMPRESSED and such). Accordingly, the files referenced are
nominally in the installed tree, but the MANn magic knows about
MANPREFIX, so you should just use MAN1= manpage.1 with no other path
components.
Do I also need to install the man pages in do-install?
${INSTALL_MAN} ${WRKSRC}/doc/man/manpage.1 ${PREFIX}/man/man1
You need to ensure that they end up in $MANPREFIX, so yes.
-Ben Kaduk
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RUN_DEPENDS for python based port
Christer Edwards wrote on 19.12.2011 01:25:
On Sat, Dec 17, 2011 at 3:23 AM, Ruslan Mahmatkhanov
cvs-...@yandex.ru wrote:
Chris and Matthew already noted what the problems are. I also
suggest to use:
${PYTHON_PKGNAMEPREFIX}yaml=0:${PORTSDIR}/devel/py-yaml
That is much cleaner. Thank you.
So USE_PYTHON=yes should be changed with USE_PYTHON=2.6-2.7,
(otherwise port build will fail with python3) and LICENSE= ASL
worth to be added.
Also added.
I've attached an archive including all the port files (distinfo,
pkg-plist, etc) for any other feedback you can offer. I still have
two remaining issues on my checklist that perhaps the group can
provide solutions for as well.
Looks like mailing list eats the attachment. Would you please upload
it somewhere and provide us with the link.
1) Building the port never successfully fetches the upstream
.tar.gz, but if I copy/paste the URL and run fetch manually it
works just fine. Thoughts?
I need to look at Makefile, but the common problem is that fetch(1)
doesn't follow redirects by default. You can tweak it with FETCH_ARGS.
You may see /usr/ports/deskutils/gtg/Makefile for an example.
2) The existing setup.py installs the two config files
(etc/salt/{master,minion}) to /usr/etc instead of /usr/local/etc.
I'm not familiar enough with setup.py to tweak that. Any
suggestions there?
${REINPLACE_CMD} is what you need. You may find usage example in
deskutils/gtg also.
If I can get those last few things figured out I'll submit the
port.
Thanks, Christer
Do not forget to check the port with ports-mgmt/portlint.
--
Regards,
Ruslan
Tinderboxing kills... the drives.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/gcc on freebsd 10
On Thu, 15 Dec 2011, Gerald Pfeifer wrote: lang/gcc build would fail for me on FreeBSD 10 (head) with binutils-2.22 installed during its configure step with the errors like the following in config.log: Yes, I am aware of it. lang/gcc is the slowly moving, conservative option, lang/gcc46 being the fast, aggressive one. In consequence, lang/gcc46 has already been fixed with regard to FreeBSD 10, whereas this likely will take another month or so for lang/gcc when the next upstream release hapens. (Had I better network connectivity right now, I might try the backport, I managed to get a somewhat decent connection now (and until Thursday). Want to give the attached patch against lang/gcc a try? It passes my tests, but I'd prefer to get confirmation from someone directly affected before committing it. GeraldIndex: files/patch-freebsd10 === RCS file: files/patch-freebsd10 diff -N files/patch-freebsd10 0a1,873 Upstream SVN commit 181536. Index: libtool.m4 === --- libtool.m4(revision 181535) +++ libtool.m4(revision 181536) @@ -2273,7 +2273,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[[123]]*) objformat=aout ;; +freebsd[[23]].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -2291,7 +2291,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[[01]]* | freebsdelf3.[[01]]*) @@ -4804,7 +4804,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' _LT_TAGVAR(hardcode_direct, $1)=yes _LT_TAGVAR(hardcode_minus_L, $1)=yes @@ -5751,7 +5751,7 @@ esac ;; - freebsd[[12]]*) + freebsd2.*) # C++ shared libraries reported to be fairly broken before # switch to ELF _LT_TAGVAR(ld_shlibs, $1)=no Index: libgomp/configure === --- libgomp/configure (revision 181535) +++ libgomp/configure (revision 181536) @@ -9317,7 +9317,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct=yes hardcode_minus_L=yes @@ -10230,7 +10230,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -10248,7 +10248,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[01]* | freebsdelf3.[01]*) @@ -13164,7 +13164,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds_FC='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct_FC=yes hardcode_minus_L_FC=yes @@ -13869,7 +13869,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -13887,7 +13887,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[01]* | freebsdelf3.[01]*) Index: libgomp/ChangeLog === --- libgomp/ChangeLog (revision 181535) +++ libgomp/ChangeLog (revision 181536) @@ -1,3 +1,7 @@ +2011-11-20 Andreas Tobler andre...@fgznet.ch + + * configure: Regenerate. + 2011-10-26 Release Manager * GCC 4.6.2 released. Index: libquadmath/configure === --- libquadmath/configure (revision 181535) +++ libquadmath/configure (revision 181536) @@ -8727,7 +8727,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct=yes hardcode_minus_L=yes @@ -9643,7 +9643,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -9661,7 +9661,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes
Beret
I would like to help spread availability of a linux game that has been recently open sourced by encouraging it to be included in package repositories. I don't use FreeBSD and am not yet familiar with *BSD and would like to request if anyone else is available to prepare a package for the game. Also, as of yet the game has not been prepared specifically to include *BSD support, however, as it is open source, it should be fairly easy to prepare the game to be compilable in *BSD. See http://www.indiedb.com/games/beret/forum/thread/open-source ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Beret
Mizery De Aria wrote on 19.12.2011 09:54: I would like to help spread availability of a linux game that has been recently open sourced by encouraging it to be included in package repositories. I don't use FreeBSD and am not yet familiar with *BSD and would like to request if anyone else is available to prepare a package for the game. Also, as of yet the game has not been prepared specifically to include *BSD support, however, as it is open source, it should be fairly easy to prepare the game to be compilable in *BSD. See http://www.indiedb.com/games/beret/forum/thread/open-source Couple of questions: 1. As far i understand i only can download sources from gitorius. And for packaging in FreeBSD there should be versioned source tarball available for download. Do you have plans to create one (like `releases' on github)? 2. If there will versioned tarball and, say, i create a port for Beret, would you take maintainership of this port and will you handle updates in future? -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [PATCH] lang/gcc -- Fix build on freebsd-current
On Sat, 17 Dec 2011, b. f. wrote: Fixes have already been implemented upstream, at Gerald's request, and are in lang/gcc46. But these fixes were introduced after the last stable release of gcc 4.6, which corresponds to lang/gcc. When a new version of gcc 4.6 is released, and the port is updated accordingly, it will include the fixes. In the meantime, I think Gerald was waiting for Martin to incorporate the patch to adjust the run-autotools-fixup target in ports/Mk/bsd.port.mk As usual, Brendan is right on target. :-) If you guys would like to test the attached patch for lang/gcc, it does allow that port to build on a FreeBSD 10 system for me, and if I get independent confirmation in the next three days it'll be in before holiday season. GeraldIndex: files/patch-freebsd10 === RCS file: files/patch-freebsd10 diff -N files/patch-freebsd10 0a1,873 Upstream SVN commit 181536. Index: libtool.m4 === --- libtool.m4(revision 181535) +++ libtool.m4(revision 181536) @@ -2273,7 +2273,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[[123]]*) objformat=aout ;; +freebsd[[23]].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -2291,7 +2291,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[[01]]* | freebsdelf3.[[01]]*) @@ -4804,7 +4804,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' _LT_TAGVAR(hardcode_direct, $1)=yes _LT_TAGVAR(hardcode_minus_L, $1)=yes @@ -5751,7 +5751,7 @@ esac ;; - freebsd[[12]]*) + freebsd2.*) # C++ shared libraries reported to be fairly broken before # switch to ELF _LT_TAGVAR(ld_shlibs, $1)=no Index: libgomp/configure === --- libgomp/configure (revision 181535) +++ libgomp/configure (revision 181536) @@ -9317,7 +9317,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct=yes hardcode_minus_L=yes @@ -10230,7 +10230,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -10248,7 +10248,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[01]* | freebsdelf3.[01]*) @@ -13164,7 +13164,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds_FC='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct_FC=yes hardcode_minus_L_FC=yes @@ -13869,7 +13869,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -13887,7 +13887,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[01]* | freebsdelf3.[01]*) Index: libgomp/ChangeLog === --- libgomp/ChangeLog (revision 181535) +++ libgomp/ChangeLog (revision 181536) @@ -1,3 +1,7 @@ +2011-11-20 Andreas Tobler andre...@fgznet.ch + + * configure: Regenerate. + 2011-10-26 Release Manager * GCC 4.6.2 released. Index: libquadmath/configure === --- libquadmath/configure (revision 181535) +++ libquadmath/configure (revision 181536) @@ -8727,7 +8727,7 @@ ;; # Unfortunately, older versions of FreeBSD 2 do not have this feature. -freebsd2*) +freebsd2.*) archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' hardcode_direct=yes hardcode_minus_L=yes @@ -9643,7 +9643,7 @@ objformat=`/usr/bin/objformat` else case $host_os in -freebsd[123]*) objformat=aout ;; +freebsd[23].*) objformat=aout ;; *) objformat=elf ;; esac fi @@ -9661,7 +9661,7 @@ esac shlibpath_var=LD_LIBRARY_PATH case $host_os in - freebsd2*) + freebsd2.*) shlibpath_overrides_runpath=yes ;; freebsd3.[01]* | freebsdelf3.[01]*) Index:
