the libtoolX ports instead of the one included with each port. Ports that
set USE_LIBTOOL_VER=X will now use the ports version of libtool instead of
the included version. To restore previous behavior, use the new macro,
USE_INC_LIBTOOL_VER. Both macros accept the same argument: a libtool version.
For example, to use the ports version of libtool-1.5, add the following to
your Makefile:
USE_LIBTOOL_VER= 15
To use the included version of libtool with extra hacks provided by
libtool-1.5, add the following to your Makefile:
USE_INC_LIBTOOL_VER= 15
With this change, ports that had to add additional libtool hacks to prevent
.la files from being installed or to fix certain threading issues can now
delete those hacks (after appropriate testing, of course).
PR: 63944
Based on work by:eik and marcus
Approved by: ade (autotools maintainer)
Tested by: kris on pointyhat
Bound to be hidden problems: You bet
Begin autotools sanitization sequence by requiring ports to explicitly
specify which version of {libtool,autoconf,automake} they need, erasing
the concept of a "system default".
For ports-in-waiting:
USE_LIBTOOL=YES -> USE_LIBTOOL_VER=13
USE_AUTOCONF=YES -> USE_AUTOCONF_VER=213
USE_AUTOMAKE=YES -> USE_AUTOMAKE_VER=14
Ports attempting to use the old style system after June 1st 2004 will be
sorely disappointed.
- switch devel/gettext (0.11.1) on, installing full package
- flip devel/gettext-old (0.10.35) to installing only static binaries
with a "-old" suffix -- gettext-old will have its deorbit burn
sequence initiated just after 4.6-RELEASE
- fix up ports for the new world order
Reviewed by: portmgr
the ECHO macro is set to "echo" by default, but it is set to "true" if
make(1) is invoked with the -s option while ECHO_CMD is always set to
the echo command.
Use command macros where appropriate.
try to use writev(2) in a non-blocking mode, especially on sockets. Not only
this makes handling of EAGAIN rather weird, but in the case of sockets makes
your code subject of a ENOBUFS, which is absolutely unclear how to handle
properly. *sigh*
Bump PORTREVISION.
Instead of replacing writev(2) with loop based on write(2), test system
limit on the number of vectors writev(2) accepts and split call to writev(2)
to several calls in such a way that number of vectors in each call doesn't
exceed this limit (aka UIO_MAXIOV). Bump PORTREVISION.
FreeBSD's writev(2) implementation is rather unreliable when large number of
vectors is submitted - it returns EINVAL despite the fact that all arguments
are pretty valid. This caused serious problems with GNOME's oaf and prevented
Nautilus from working properly. The problem disappeared when I've replaced
writev(2) call with appropriate loop based around ordinary write(2). Perhaps
this should be investigated and the real source of the problem fixed instead,
but I do not have a time for this right now. For those who interested I'm
ready to provide a step-by step instruction on how to reproduce the bug.
Special thanks to: andersca @ nautilus#irc.gnome.org
to listen on any network (IPv4 or IPv6) sockets, if and only
if the user hasn't already installed a ${PREFIX}/etc/orbitrc file
(the default, and most likely case)
Issue raised by: Louis A. Mamakos <louie@TransSys.COM>
Discussed on: security mailing list
