Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild
2017-02-28 21:00 GMT+01:00 Konstantin Belousov : > Ideally, ports should stop shipping mangled system includes, or even better, > gcc stop doing fixincludes. Amen. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems are a Curl upgrade on 12.0 current of Sun Oct 2
Basename@FBSD_1.5 is the new symbol. Did you by any chance downgrade your system? On 5 Dec 2016 6:59 p.m., "Dimitry Andric" wrote: > On 05 Dec 2016, at 15:44, Willem Jan Withagen wrote: > > > > Now some of my lining attempts give me: > > > > /usr/local/lib/libcurl.so: undefined reference to `basename@FBSD_1.5 > > I guess that that libc has become versioned, of the version number got > > bumpped? > > > > So would I need to rebuild world? > > Yes, this was changed by Ed in r308264: > > https://svnweb.freebsd.org/base?view=revision&revision=308264 > > Although I would think there might have been a backwards compat symbol... > > -Dimitry > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
2016-11-24 13:13 GMT+01:00 Vsevolod Stakhov : > On 23/11/2016 16:27, Ed Schouten wrote: >> Hi Hans, >> >> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >> >> Nice! Do you by any chance have any numbers that show the performance >> improvements made by this change? Assuming that the SAT solver of >> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >> affect performance linearly. My guess is therefore that the running >> time is reduced by approximately 5/12. Is this correct? > > There won't be any improvement if you just remove duplicates from SAT > formula. This situation is handled by picosat internally and even for > naive DPLL there is no significant influence of duplicate KNF clauses: > once you've assumed all vars in some clause, you automatically resolve > all duplicates. Exactly. This is why I've stated: it affects performance linearly. Referring to Wikipedia's pseudo-code of the algorithm: the number of calls to unit-propagate() and pure-literal-assign() drops linearly, but the recursion will stay the same. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
2016-11-23 17:41 GMT+01:00 Hans Petter Selasky : > GitHub wouldn't allow me to make a .diff attachment. But there's absolutely no need for doing that in the first place! :-) 1. Go to https://github.com/freebsd/pkg 2. Click 'Fork' on the top right. This will probably create a https://github.com/hselasky/pkg 3. Check out that repository using git(1), create a separate branch and commit the changes to the SAT solver. 4. Go to https://github.com/hselasky/pkg and click on 'New pull request'. 5. Fill in the form. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
Hi Hans, 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : > I've made a patch to hopefully optimise SAT solving in our pkg utility. Nice! Do you by any chance have any numbers that show the performance improvements made by this change? Assuming that the SAT solver of pkg(1) uses an algorithm similar to DPLL[1], a change like this would affect performance linearly. My guess is therefore that the running time is reduced by approximately 5/12. Is this correct? By the way, why attach a zip file with a diff? GitHub's pull requests are awesome! :-) [1] Davis-Putnam-Logemann-Loveland algorithm: https://en.wikipedia.org/wiki/DPLL_algorithm -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o
Hi Steve, 2013/5/19 Steve Wills : > I had a similar issue with devel/kBuild recently. It may be due to > -Dlint getting passed to the build. See this rev: > > [...] > > which defines _Thread_local as empty when lint is defined. This then > affects runetype.h: > > http://svnweb.freebsd.org/base/head/include/runetype.h?annotate=232498&pathrev=250623#l92 > > I'm not sure if this is a bug in cdefs.h, runetype.h or things building > with -Dlint or none of the above. Comments would be appreciated. This is a bit of a weird issue, which I didn't expect. It seems that we have various ports that actually *compile* code using -Dlint. I thought it was only used by tools like xlint, which only process source code. I've reverted the change to sys/cdefs.h. Thanks for reporting the issue! -- Ed Schouten ___ 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"
[Resolved] GCC 4.6 compilation problems w.r.t. static_assert
* Ed Schouten , 20111228 19:10: > Hmmm... This seems to apply to my changes. I will look into this > tomorrow. Thanks for the report! Just to clarify, as mentioned earlier in this thread, the linking problems problems are not related by my C11 patches, as they are only part of HEAD. It seems they were caused due to local configuration problems and have been resolved. The GCC 4.6 compilation problem on HEAD was caused by one of my changes. Please update your system to r228955 or later. Thanks for reporting. -- Ed Schouten WWW: http://80386.nl/ pgp80d5lu6HSh.pgp Description: PGP signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
* Rainer Hurling , 20111228 17:31: > error: macro "_Static_assert" passed 3 arguments, but takes just 2 > In file included from > /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! -- Ed Schouten WWW: http://80386.nl/ pgpQFINa5Yqbu.pgp Description: PGP signature
Re: VirtualBox-kmod fails to build on -CURRENT
* Bernhard Fröhlich , 2001 20:38: > Thanks a lot for the patch. To be able to submit it upstream please > reply if it is okay that the patch is licensed under the MIT License > so that Oracle can include it in their products. Sure. I don't care. :-) -- Ed Schouten WWW: http://80386.nl/ pgp6tg3n8md5Q.pgp Description: PGP signature
Re: VirtualBox-kmod fails to build on -CURRENT
* Marco Steinbach , 2001 18:18:
> You were right about the device naming, I had to create a symlink.
Okay. I've attached a new version of the patch that:
- Adds a symbolic link from /dev/vboxdrv0 to /dev/vboxdrv automatically,
- Changes the code to use /dev/vboxdrv.
This means the kernel module is backwards compatible, but VirtualBox
itself isn't. This is probably a good compromise.
I trust that the warnings and traces you are seeing are in no way
related to my patch, so I suppose you're better off reporting those to
the VirtualBox developers.
decke@, (or who else maintains VirtualBox), will you do the honour of
getting the patch upstreamed/applied locally? The patch probably has to
be used by both the virtualbox-ose and the virtualbox-ose-kmod port.
Thanks!
--
Ed Schouten
WWW: http://80386.nl/
--- src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
+++ src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
@@ -69,10 +69,9 @@
static int VBoxDrvFreeBSDModuleEvent(struct module *pMod, int enmEventType,
void *pvArg);
static int VBoxDrvFreeBSDLoad(void);
static int VBoxDrvFreeBSDUnload(void);
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char
*pachName, int cchName, struct cdev **ppDev);
-static d_fdopen_t VBoxDrvFreeBSDOpen;
-static d_close_tVBoxDrvFreeBSDClose;
+static d_open_t VBoxDrvFreeBSDOpen;
+static void VBoxDrvFreeBSDDtr(void *pData);
static d_ioctl_tVBoxDrvFreeBSDIOCtl;
static int VBoxDrvFreeBSDIOCtlSlow(PSUPDRVSESSION pSession, u_long
ulCmd, caddr_t pvData, struct thread *pTd);
@@ -100,21 +99,13 @@
static struct cdevswg_VBoxDrvFreeBSDChrDevSW =
{
.d_version =D_VERSION,
-#if __FreeBSD_version > 800061
-.d_flags = D_PSEUDO | D_TRACKCLOSE | D_NEEDMINOR,
-#else
-.d_flags = D_PSEUDO | D_TRACKCLOSE,
-#endif
-.d_fdopen = VBoxDrvFreeBSDOpen,
-.d_close = VBoxDrvFreeBSDClose,
+.d_open = VBoxDrvFreeBSDOpen,
.d_ioctl = VBoxDrvFreeBSDIOCtl,
.d_name = "vboxdrv"
};
-/** List of cloned device. Managed by the kernel. */
-static struct clonedevs*g_pVBoxDrvFreeBSDClones;
-/** The dev_clone event handler tag. */
-static eventhandler_tag g_VBoxDrvFreeBSDEHTag;
+/** The /dev/vboxdrv character device. */
+static struct cdev *g_pVBoxDrvFreeBSDChrDev;
/** Reference counter. */
static volatile uint32_tg_cUsers;
@@ -176,20 +167,11 @@
if (RT_SUCCESS(rc))
{
/*
- * Configure device cloning.
+ * Configure character device. Add symbolic link for compatibility.
*/
-clone_setup(&g_pVBoxDrvFreeBSDClones);
-g_VBoxDrvFreeBSDEHTag = EVENTHANDLER_REGISTER(dev_clone,
VBoxDrvFreeBSDClone, 0, 1000);
-if (g_VBoxDrvFreeBSDEHTag)
-{
-Log(("VBoxDrvFreeBSDLoad: returns successfully\n"));
-return VINF_SUCCESS;
-}
-
-printf("vboxdrv: EVENTHANDLER_REGISTER(dev_clone,,,) failed\n");
-clone_cleanup(&g_pVBoxDrvFreeBSDClones);
-rc = VERR_ALREADY_LOADED;
-supdrvDeleteDevExt(&g_VBoxDrvFreeBSDDevExt);
+g_pVBoxDrvFreeBSDChrDev = make_dev(&g_VBoxDrvFreeBSDChrDevSW, 0,
UID_ROOT, GID_WHEEL, VBOXDRV_PERM, "vboxdrv");
+make_dev_alias(g_pVBoxDrvFreeBSDChrDev, "vboxdrv0");
+return VINF_SUCCESS;
}
else
printf("vboxdrv: supdrvInitDevExt failed, rc=%d\n", rc);
@@ -210,8 +192,7 @@
/*
* Reserve what we did in VBoxDrvFreeBSDInit.
*/
-EVENTHANDLER_DEREGISTER(dev_clone, g_VBoxDrvFreeBSDEHTag);
-clone_cleanup(&g_pVBoxDrvFreeBSDClones);
+destroy_dev(g_pVBoxDrvFreeBSDChrDev);
supdrvDeleteDevExt(&g_VBoxDrvFreeBSDDevExt);
@@ -225,59 +206,6 @@
/**
- * DEVFS event handler.
- */
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char
*pszName, int cchName, struct cdev **ppDev)
-{
-int iUnit;
-int rc;
-
-Log(("VBoxDrvFreeBSDClone: pszName=%s ppDev=%p\n", pszName, ppDev));
-
-/*
- * One device node per user, si_drv1 points to the session.
- * /dev/vboxdrv where N = {0...255}.
- */
-if (!ppDev)
-return;
-if (dev_stdclone(pszName, NULL, "vboxdrv", &iUnit) != 1)
-return;
-if (iUnit >= 256 || iUnit < 0)
-{
-Log(("VBoxDrvFreeBSDClone: iUnit=%d >= 256 - rejected\n", iUnit));
-return;
-}
-
-Log(("VBoxDrvFreeBSDClone: pszName=%s iUnit=%d\n", pszName, iUnit));
-
-rc = clone_create(&g_pVBoxDrvFreeBSDClones, &g_VBoxDrvFreeBSDChrDevSW,
&iUnit, ppDev, 0);
-Log(("VBoxDrvFreeBSDClone: clone_create -> %d; iUnit=%d\n", rc, iUnit));
-if (rc)
-{
Re: VirtualBox-kmod fails to build on -CURRENT
* Marco Steinbach , 20111031 13:11: > Thanks for having a look into this -- I'm trying out your patch right > now. This will take a while, as I'll try and test this on 7, also. Great. Thanks! I just inspected the code and it seems VirtualBox expects the device to be named /dev/vboxdrv%d explicitly. If that's the case, please try to add a symbolic link from vboxdrv0 to vboxdrv. If that works, I can get that fixed as well. -- Ed Schouten WWW: http://80386.nl/ pgprvecGx0i0i.pgp Description: PGP signature
Re: VirtualBox-kmod fails to build on -CURRENT
* Ed Schouten , 20111031 12:07: > Ugh. Too impatient. Please try the attached patch. It should build on > 7.x and higher. I have only compile-tested it, because I am not a > VirtualBox user (yet). Read: I have only compile-tested it on HEAD, but the used interfaces should be present as of 7.x. -- Ed Schouten WWW: http://80386.nl/ pgpA5DdwA3IFx.pgp Description: PGP signature
Re: VirtualBox-kmod fails to build on -CURRENT
* Ed Schouten , 20111031 11:26:
> I think I'll take a closer look at this code more thoroughly sometime
> this week.
Ugh. Too impatient. Please try the attached patch. It should build on
7.x and higher. I have only compile-tested it, because I am not a
VirtualBox user (yet).
| SUPDrv-freebsd.c | 153 ++-
| 1 file changed, 21 insertions(+), 132 deletions(-)
--
Ed Schouten
WWW: http://80386.nl/
--- src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
+++ src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
@@ -69,10 +69,9 @@
static int VBoxDrvFreeBSDModuleEvent(struct module *pMod, int enmEventType,
void *pvArg);
static int VBoxDrvFreeBSDLoad(void);
static int VBoxDrvFreeBSDUnload(void);
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char
*pachName, int cchName, struct cdev **ppDev);
-static d_fdopen_t VBoxDrvFreeBSDOpen;
-static d_close_tVBoxDrvFreeBSDClose;
+static d_open_t VBoxDrvFreeBSDOpen;
+static void VBoxDrvFreeBSDDtr(void *pData);
static d_ioctl_tVBoxDrvFreeBSDIOCtl;
static int VBoxDrvFreeBSDIOCtlSlow(PSUPDRVSESSION pSession, u_long
ulCmd, caddr_t pvData, struct thread *pTd);
@@ -100,21 +99,13 @@
static struct cdevswg_VBoxDrvFreeBSDChrDevSW =
{
.d_version =D_VERSION,
-#if __FreeBSD_version > 800061
-.d_flags = D_PSEUDO | D_TRACKCLOSE | D_NEEDMINOR,
-#else
-.d_flags = D_PSEUDO | D_TRACKCLOSE,
-#endif
-.d_fdopen = VBoxDrvFreeBSDOpen,
-.d_close = VBoxDrvFreeBSDClose,
+.d_open = VBoxDrvFreeBSDOpen,
.d_ioctl = VBoxDrvFreeBSDIOCtl,
.d_name = "vboxdrv"
};
/** List of cloned device. Managed by the kernel. */
-static struct clonedevs*g_pVBoxDrvFreeBSDClones;
-/** The dev_clone event handler tag. */
-static eventhandler_tag g_VBoxDrvFreeBSDEHTag;
+static struct cdev *g_pVBoxDrvFreeBSDChrDev;
/** Reference counter. */
static volatile uint32_tg_cUsers;
@@ -176,20 +167,10 @@
if (RT_SUCCESS(rc))
{
/*
- * Configure device cloning.
+ * Configure character device.
*/
-clone_setup(&g_pVBoxDrvFreeBSDClones);
-g_VBoxDrvFreeBSDEHTag = EVENTHANDLER_REGISTER(dev_clone,
VBoxDrvFreeBSDClone, 0, 1000);
-if (g_VBoxDrvFreeBSDEHTag)
-{
-Log(("VBoxDrvFreeBSDLoad: returns successfully\n"));
-return VINF_SUCCESS;
-}
-
-printf("vboxdrv: EVENTHANDLER_REGISTER(dev_clone,,,) failed\n");
-clone_cleanup(&g_pVBoxDrvFreeBSDClones);
-rc = VERR_ALREADY_LOADED;
-supdrvDeleteDevExt(&g_VBoxDrvFreeBSDDevExt);
+g_pVBoxDrvFreeBSDChrDev = make_dev(&g_VBoxDrvFreeBSDChrDevSW, 0,
UID_ROOT, GID_WHEEL, VBOXDRV_PERM, "vboxdrv");
+return VINF_SUCCESS;
}
else
printf("vboxdrv: supdrvInitDevExt failed, rc=%d\n", rc);
@@ -210,8 +191,7 @@
/*
* Reserve what we did in VBoxDrvFreeBSDInit.
*/
-EVENTHANDLER_DEREGISTER(dev_clone, g_VBoxDrvFreeBSDEHTag);
-clone_cleanup(&g_pVBoxDrvFreeBSDClones);
+destroy_dev(g_pVBoxDrvFreeBSDChrDev);
supdrvDeleteDevExt(&g_VBoxDrvFreeBSDDevExt);
@@ -225,59 +205,6 @@
/**
- * DEVFS event handler.
- */
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char
*pszName, int cchName, struct cdev **ppDev)
-{
-int iUnit;
-int rc;
-
-Log(("VBoxDrvFreeBSDClone: pszName=%s ppDev=%p\n", pszName, ppDev));
-
-/*
- * One device node per user, si_drv1 points to the session.
- * /dev/vboxdrv where N = {0...255}.
- */
-if (!ppDev)
-return;
-if (dev_stdclone(pszName, NULL, "vboxdrv", &iUnit) != 1)
-return;
-if (iUnit >= 256 || iUnit < 0)
-{
-Log(("VBoxDrvFreeBSDClone: iUnit=%d >= 256 - rejected\n", iUnit));
-return;
-}
-
-Log(("VBoxDrvFreeBSDClone: pszName=%s iUnit=%d\n", pszName, iUnit));
-
-rc = clone_create(&g_pVBoxDrvFreeBSDClones, &g_VBoxDrvFreeBSDChrDevSW,
&iUnit, ppDev, 0);
-Log(("VBoxDrvFreeBSDClone: clone_create -> %d; iUnit=%d\n", rc, iUnit));
-if (rc)
-{
-#if __FreeBSD_version > 800061
-*ppDev = make_dev(&g_VBoxDrvFreeBSDChrDevSW, iUnit, UID_ROOT,
GID_WHEEL, VBOXDRV_PERM, "vboxdrv%d", iUnit);
-#else
-*ppDev = make_dev(&g_VBoxDrvFreeBSDChrDevSW, unit2minor(iUnit),
UID_ROOT, GID_WHEEL, VBOXDRV_PERM, "vboxdrv%d", iUnit);
-#endif
-if (*ppDev)
-{
-dev_ref(*ppDev);
-(*ppDev)->si_flags |= SI_CHEAPCLONE;
-Log(("VBoxDrvFreeBSDClone: Created *ppDev=%p iUnit=%d si_drv1=%p
si_drv2=%p\n",
-
Re: VirtualBox-kmod fails to build on -CURRENT
Hi Bernhard, * Bernhard Froehlich , 20111031 11:04: > My first guess is that it could be enough to remove the flag but I > don't know if we need to replace some code with make_dev_p(). So i've > CC'd ed@ and hope that he can shed some light on that. > > https://www.virtualbox.org/browser/trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c#L104 Hmmm... You can simply remove D_PSEUDO for now, but I think eventually the driver should be restructured a bit. It seems we can simply use the cdevpriv API for this, where we have a single /dev/vboxdrv device node. I think I'll take a closer look at this code more thoroughly sometime this week. -- Ed Schouten WWW: http://80386.nl/ pgpicPjIOWu2Q.pgp Description: PGP signature
ports/162049: The Ports tree lacks a framework to restart services
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
--
Ed Schouten
WWW: http://80386.nl/
pgpPIcEFLSqiZ.pgp
Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Jilles Tjoelker , 20111002 18:23: > The proper fix is indeed in autotools, but I think it is inappropriate > to keep head effectively frozen until this problem can be fixed > properly. What I think is even a bigger disgrace, is that we haven't even added the autotools fixes to our own packages in Ports. This means that people running FreeBSD 9.0-RELEASE with a binary libtool package will not be able to generate future-proof source tarballs. This is not just a 10.0-bug, it's a bug in general. -- Ed Schouten WWW: http://80386.nl/ pgp5uKANdFZbe.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
Hi, * Stanislav Sedov , 20110929 22:43: > I think this is a good idea. > I recommend sending this to re@ and/or core@ for consideration. > Personally, I'd love to see this committed ASAP, as I'm unable > to do any ports work right now. I've poked portmgr@. :-) -- Ed Schouten WWW: http://80386.nl/ pgpsgq9JCe9nI.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Xin LI , 20110929 12:08: > This is not sufficient since some places it's freebsd[123], > freebsd[[123]], etc... Yes, but the patch I propose already fixes a large class of compilation issues. It is by no means a silver bullet. -- Ed Schouten WWW: http://80386.nl/ pgpnUhQiJ8vUz.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Ed Schouten , 20110929 11:07:
> I meant simply adding this line to bsd.port.mk, to be executed after
> pre-configure and before configure.
More specifically, see the attached patch.
--
Ed Schouten
WWW: http://80386.nl/
--- Mk/bsd.port.mk
+++ Mk/bsd.port.mk
@@ -3667,6 +3667,16 @@
@${DO_NADA}
.endif
+# Work around an issue where FreeBSD 10.0 is detected as FreeBSD 1.x.
+run-autotools-fixup:
+.if ${OSVERSION} >= 100
+ @find ${WRKSRC} -type f \( -name config.libpath -o \
+ -name config.rpath -o -name configure -o -name libtool.m4 \) \
+ -exec sed -i '' 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
+.else
+ @${DO_NADA}
+.endif
+
# Configure
.if !target(do-configure)
@@ -4266,7 +4276,7 @@
_CONFIGURE_DEP= patch
_CONFIGURE_SEQ= build-depends lib-depends configure-message \
configure-autotools pre-configure pre-configure-script \
-run-autotools do-configure post-configure post-configure-script
+run-autotools run-autotools-fixup do-configure post-configure post-configure-script
_BUILD_DEP= configure
_BUILD_SEQ= build-message pre-build pre-build-script do-build \
post-build post-build-script
pgpU7Tmu2JJOq.pgp
Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Matthew Seaman , 20110929 11:01: > Because that's a change to the upstream distfiles downloaded from the > net. So this change would have to be implemented by adding patch files > to every port that needed it, or by adding a new make target in the > various Makefiles. I meant simply adding this line to bsd.port.mk, to be executed after pre-configure and before configure. -- Ed Schouten WWW: http://80386.nl/ pgpBq7UqfhcJ4.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
* Ed Schouten , 20110929 10:47:
> -exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
Whoops. Don't forget to add '' after the -i.
--
Ed Schouten
WWW: http://80386.nl/
pgpeXx31sf2gD.pgp
Description: PGP signature
Instafix for FreeBSD ports brokenness on 10.0?
Hi folks,
Why can't we simply fix the entire ports tree at once by doing something
like this?
find ${WRKSRC} -type f \( -name config.libpath -o \
-name config.rpath -o -name configure -o -name libtool.m4 \) \
-exec sed -i 's/freebsd1\*)/SHOULDNOTMATCHANYTHING)/' {} +
Just to be safe, we can only execute this when OSVERSION is 10.0.
--
Ed Schouten
WWW: http://80386.nl/
pgpbCNHmqdKNT.pgp
Description: PGP signature
Re: Utmpx usage
* Chris Rees , 20110523 10:40: > I've been perusing the linux manpage for utmp, and noticed that login and > getty deal with utmp for logins, and It's only init's job to deal with > logouts. Since runit is an init replacement, this makes perfect sense. Yeah; it probably acts as a safety belt for misbehaving tools that forget to write logout records. On FreeBSD logout records are written by pam_lastlog(8), making that logic in init(8) superfluous. You could consider calling getutxline() in a loop to obtain the ut_ids for a specific TTY. -- Ed Schouten WWW: http://80386.nl/ pgpayNYGoNxVC.pgp Description: PGP signature
Re: Utmpx usage
Hi Chris! * Chris Rees , 20110522 09:29: > Hi all, > > After removing all kittens from Ed's reach, I'm disclosing that > sysutils/runit tried to use utmpx to directly read() and write() the > utmpx files directly... > > I've replaced the offending code with a patch to the port [1], but I > wonder if anyone would please review the patch? I don't have a CURRENT > machine to try it on... I may have also made some terrible mistakes -- > I'm not hugely familiar with utmpx. > > Thanks! > > Chris > > [1] http://www.bayofrum.net/~crees/patches/runit-utmpx.patch As promised, I would look at your patch this evening. I've changed the cc to ports@, since it's likely a better place to discuss this. First of all, you can remove the getutxent()/endutxent() calls; at least on FreeBSD (but even on Solaris -- the first OS to implement utmpx) pututxline() is implemented separately from the read-functions. There is no need to open the database for reading. Secondly, please make sure you set the proper fields of the utmpx structure. Always zero it (e.g. with memset()) before calling pututxline() to prevent random junk from ending up in the log files. Also, for DEAD_PROCESS must we set ut_id, but not ut_line. ut_id must be set to one of the identifiers of an existing session. These identifiers can be set to arbitrary values by the application that added the entry. Some apps are lazy and just put the TTY name in there, but you cannot assume that that's the case. Run `getent utmpx active' to see what the identifiers look like. For example, pam_lastlog(8) uses random identifiers. You must also set ut_tv, even though our implementation does it for you. Finally, I'm not really sure what the code is trying to solve here. What's the use of implementing an utmp_logout(), to simulate logouts on the utmp database, without actually providing code to perform logins? Maybe we should just patch runit to leave utmp(x) alone. So far I don't have a feeling it's trying to do something useful with it. Any opinions, anyone? -- Ed Schouten WWW: http://80386.nl/ pgpjnV0WNoYZA.pgp Description: PGP signature
General note on rc scripts and daemonizing
Hello port maintainers,
I think I'd better send an email about this to ports@, because I've seen
it in various places and it is getting a bit tiresome to mail all port
authors individually.
I've seen various cases in the past where people write rc scripts that
do the following:
command="/usr/local/bin/dog"
command_args="--bark > /dev/null 2>&1 &"
So in this case `dog --bark' doesn't daemonize itself, so the & is
sufficient here, right? Well, it is not. :-) The point is that we simply
tell the kernel to redirect stdout/stderr and run it in the background.
It doesn't tell the kernel that the process should run in a separate
session (see getsid(2)/setsid(2)).
This has various implications. The most important one I can think of, is
that the daemon can still do open("/dev/tty", ...) if it wants and spam
your TTY, even if the daemon is running as user `nobody'. This also
means that if you run the rc script from within a pseudo-terminal, it
can never actually destroy the pseudo-terminal for you, because maybe
the daemon is interested in using it.
Below is the output of `pstat -t' on one of my systems, where I decided
to fire up MySQL:
| LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE
| ...
| pts/11 0000 000 0 82711 0 G
The kernel actually wants to clean up this pseudo-terminal (state = G),
but it is prevented from doing so. It will only clean it up by the time
MySQL is shut down.
So how can this be solved? We already have a tool in base called
daemon(8). It is simply a wrapper around daemon(3) (which calls
setsid(2), which you can use to daemonize processes. So the next time
you write an rc script and need to daemonize something which cannot do
it by itself, please think of the kittens. ;-)
[ CCing this to r...@. Maybe we should add some kind of built-in
functionality to call daemon(8)? ]
--
Ed Schouten
WWW: http://80386.nl/
pgpF0TnjyFCyD.pgp
Description: PGP signature
Re: HEADS UP: gone. All welcome . - ports/sysutils/screen and ports/sysutils/tmux not showing sessions
Hi Vincent, * Vincent Poy wrote: > It appears that after utmpx.h gone into effect, ports/sysutils/screen and > ports/sysutils/tmux are not working correctly after a updated ports tree and > building/installing the ports. What basically happens is the screen/tmux > sessions which basically use tty's don't show up on the system in w, who, > finger. I just rebuilt screen and doesn't seem to work indeed. The point is that I wrote a perfectly fine patch for it and sent it to cy@, but he committed a completely different version to the ports tree. You'd better discuss this regression with him. My version did work: | (e...@dull) ~ $ tty | /dev/pts/0 | (e...@dull) ~ $ w | 9:02AM up 5 days, 11:02, 1 user, load averages: 0.08, 0.08, 0.03 | USER TTY FROM LOGIN@ IDLE WHAT | ed pts/0mekker.80386.nl 9:02AM - w | (e...@dull) ~ $ screen | (e...@dull) ~ $ tty | /dev/pts/2 | (e...@dull) ~ $ w | 9:03AM up 5 days, 11:02, 1 user, load averages: 0.05, 0.08, 0.03 | USER TTY FROM LOGIN@ IDLE WHAT | ed pts/2mekker:S.0 9:03AM - w -- Ed Schouten WWW: http://80386.nl/ pgpATLo0sj2Xg.pgp Description: PGP signature
Re: HEADS UP: gone. All welcome . - ports/sysutils/screen and ports/sysutils/tmux not showing sessions
* Vincent Poy wrote: > It appears that after utmpx.h gone into effect, ports/sysutils/screen and > ports/sysutils/tmux are not working correctly after a updated ports tree and > building/installing the ports. What basically happens is the screen/tmux > sessions which basically use tty's don't show up on the system in w, who, > finger. Which is because tmux doesn't update utmp files anyway. -- Ed Schouten WWW: http://80386.nl/ pgpYR4k1xJh09.pgp Description: PGP signature
Re: HEADS UP: gone. All welcome .
Hello Yvan, * VANHULLEBUS Yvan wrote: > We're working on this, but as we have now to work with both utmp.h and > utmpx.h (at least for FreeBSD releases and FreeBSD CURRENT), we're > trying to find a clean way to solve the issue. I think the cleanest solution would be to split them off completely. Most projects do things like: #define utmp utmpx but this really makes the code harder to interpret. Just moving all the utmp stuff into a small set of routines that you port per operating system is probably the best way to go. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpS8nwQ04zj9.pgp Description: PGP signature
Re: HEADS UP: gone. All welcome .
sizeof ut.ut_host, sin, sin->sa_len);
+ pututxline(&ut);
}
> 5. hylafax
>
> http://pointyhat.freebsd.org/errorlogs/i386-9-latest/hylafax-6.0.4.log
>
> ... configure use of (extended utmp interface)
> but fails.
>
> Even forcing it to use the SysV interface fails:
> GettySysV.c++: In member function 'void SysVGetty::writeWtmp(utmpx*)':
> GettySysV.c++:177: error: '_PATH_WTMPX' was not declared in this scope
> GettySysV.c++:177: error: 'updwtmpx' was not declared in this scope
> GettySysV.c++: In member function 'void SysVGetty::loginAccount()':
> GettySysV.c++:200: error: 'struct utmpx' has no member named 'ut_xtime'
> GettySysV.c++: In member function 'virtual void SysVGetty::hangup()':
> GettySysV.c++:243: error: 'struct utmpx' has no member named 'ut_xtime'
> *** Error code 1
No need to call updwtmpx(). ut_xtime should be called ut_tv.tv_sec.
--- faxd/GettySysV.c++
+++ faxd/GettySysV.c++
@@ -44,13 +44,7 @@
#define utmp utmpx
#undef ut_time
-#ifdef __linux__
-#ifdef __GLIBC__
#define ut_time ut_tv.tv_sec
-#endif
-#else
-#define ut_time ut_xtime
-#endif
#define getutent getutxent
#define getutid getutxid
@@ -172,16 +166,6 @@
void
SysVGetty::writeWtmp(utmp* ut)
{
-// append record of login to wtmp file
-#if HAS_UTMPX
-updwtmpx(_PATH_WTMPX, ut);
-#else
-int fd = Sys::open(_PATH_WTMP, O_WRONLY|O_APPEND);
-if (fd >= 0) {
- Sys::write(fd, (char *)ut, sizeof (*ut));
- Sys::close(fd);
-}
-#endif
}
/*
> 6. manpage
>
> $ man getutxent
>
> Please proivide some example here.
Well, the other get*ent(3) manpages don't provide examples either, but
if you can think of something you consider to be useful to be provided
as an example, be sure to send ideas, patches, etc.
--
Ed Schouten
WWW: http://80386.nl/
pgp6dfgupcUtj.pgp
Description: PGP signature
Re: HEADS UP: gone. All welcome .
* Ed Schouten wrote: > I just looked at this problem and sent a patch to the Xorg folks. I > can't find my email in the xorg-devel archives yet, so I've attached a > patch to this email. Hopefully the respective port maintainer can turn > it into something useful. And it got fixed upstream: http://cgit.freedesktop.org/xorg/app/sessreg/commit/?id=9792646873ac0e597cc65ef4a056444fd8f9a7fd I just asked whether they are planning on releasing this soon, because then it might just be easier to bump sessreg than backporting it to our version. -- Ed Schouten WWW: http://80386.nl/ pgpBLTZdZtK5Q.pgp Description: PGP signature
Re: HEADS UP: gone. All welcome .
* Rainer Hurling wrote: > Is it ok to report such problems in this thread? I think it's better to file PRs for them, to make sure the port maintainer is also informed. I'll take a look at the gftp problem tomorrow. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpI7CYOEymJ1.pgp Description: PGP signature
Re: HEADS UP: gone. All welcome .
Hello Rainer,
* Rainer Hurling wrote:
> After updating my system i tried to rebuild Xorg ports. All went
> fine until it has to compile x11/sessreg.
>
> It seems that the configure script does not find struct
> 'utmpx.ut_syslen' and so the build process falls back to utmp?
>
> Could you please take a look if this is an issue of the new interface.
I just looked at this problem and sent a patch to the Xorg folks. I
can't find my email in the xorg-devel archives yet, so I've attached a
patch to this email. Hopefully the respective port maintainer can turn
it into something useful.
--
Ed Schouten
WWW: http://80386.nl/
diff --git a/configure.ac b/configure.ac
index 6e2f470..be1b4b4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,13 +39,14 @@ AC_PROG_INSTALL
XORG_DEFAULT_OPTIONS
-AC_CHECK_HEADERS([lastlog.h utmpx.h sys/param.h])
+AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h])
AC_CHECK_MEMBER([struct utmpx.ut_syslen],
HAVE_SYSLEN=1,
HAVE_SYSLEN=0,
[#include ])
AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN,
[utmpx structure includes ut_syslen field])
+AC_CHECK_FUNCS([updwtmpx utmpxname])
AC_SYS_LARGEFILE
diff --git a/sessreg.c b/sessreg.c
index c674450..992a213 100644
--- a/sessreg.c
+++ b/sessreg.c
@@ -75,7 +75,6 @@
# include
# include
# include
-# include
#if defined(__SVR4) || defined(SVR4) || defined(linux) || defined(__GLIBC__)
# define SYSV
@@ -84,7 +83,10 @@
#include
#define Time_t time_t
-static void set_utmp (struct utmp *u, char *line, char *user, char *host, Time_t date, int addp);
+#ifdef USE_UTMP
+static void set_utmp (struct utmp *u, char *line, char *user, char *host,
+ Time_t date, int addp);
+#endif
#ifdef USE_UTMPX
static void set_utmpx (struct utmpx *u, const char *line, const char *user,
@@ -94,7 +96,12 @@ static void set_utmpx (struct utmpx *u, const char *line, const char *user,
static int wflag, uflag, lflag;
static char *wtmp_file, *utmp_file, *line;
#ifdef USE_UTMPX
-static char *wtmpx_file = NULL, *utmpx_file = NULL;
+#ifdef HAVE_UPDWTMPX
+static char *wtmpx_file = NULL;
+#endif
+#ifdef HAVE_UTMPXNAME
+static char *utmpx_file = NULL;
+#endif
#endif
static int utmp_none, wtmp_none;
/*
@@ -103,7 +110,9 @@ static int utmp_none, wtmp_none;
*/
static int hflag, sflag, xflag, tflag;
static char *host_name = NULL;
+#ifdef USE_UTMP
static int slot_number;
+#endif
static char *xservers_file, *ttys_file;
static char *user_name;
static int aflag, dflag;
@@ -175,7 +184,7 @@ sysnerr (int x, const char *s)
int
main (int argc, char **argv)
{
-#ifndef SYSV
+#if defined(USE_UTMP) && !defined(SYSV)
int utmp;
#endif
char *line_tmp;
@@ -183,7 +192,9 @@ main (int argc, char **argv)
int wtmp;
#endif
Time_t current_time;
+#ifdef USE_UTMP
struct utmp utmp_entry;
+#endif
#ifdef USE_UTMPX
struct utmpx utmpx_entry;
#endif
@@ -218,7 +229,9 @@ main (int argc, char **argv)
host_name = getstring (&argv, &hflag);
break;
case 's':
+#ifdef USE_UTMP
slot_number = atoi (getstring (&argv, &sflag));
+#endif
break;
case 'x':
xservers_file = getstring (&argv, &xflag);
@@ -244,14 +257,14 @@ main (int argc, char **argv)
/* set up default file names */
if (!wflag) {
wtmp_file = WTMP_FILE;
-#ifdef USE_UTMPX
+#if defined(USE_UTMPX) && defined(HAVE_UPDWTMPX)
wtmpx_file = WTMPX_FILE;
#endif
}
#ifndef NO_UTMP
if (!uflag) {
utmp_file = UTMP_FILE;
-#ifdef USE_UTMPX
+#if defined(USE_UTMPX) && defined(HAVE_UTMPXNAME)
utmpx_file = UTMPX_FILE;
#endif
}
@@ -262,7 +275,7 @@ main (int argc, char **argv)
if (!Lflag)
llog_file = LLOG_FILE;
#endif
-#if !defined(SYSV) && !defined(linux) && !defined(__QNX__)
+#if defined(USE_UTMP) && !defined(SYSV) && !defined(linux) && !defined(__QNX__)
if (!tflag)
ttys_file = TTYS_FILE;
if (!sflag && !utmp_none) {
@@ -281,34 +294,42 @@ main (int argc, char **argv)
line = line_tmp;
}
time (¤t_time);
+#ifdef USE_UTMP
set_utmp (&utmp_entry, line, user_name, host_name, current_time, aflag);
+#endif
#ifdef USE_UTMPX
/* need to set utmpxname() before calling set_utmpx() for
UtmpxIdOpen to work */
+#ifdef HAVE_UTMPXNAME
if (utmpx_file != NULL) {
utmpxname (utmpx_file);
}
+#endif
set_utmpx (&utmpx_entry, line, user_name,
host_name, current_time, aflag);
#endif
if (!utmp_none) {
#ifdef USE_UTMPX
- if (utmpx_file != NULL) {
+# ifdef HAVE_UTMPX_NAME
+ if (utmpx_file != NULL)
+#endif
+ {
setutxent ();
(void) getutxid (&utmpx_entry);
pututxline (&utmpx_entry);
endutxent ();
}
#endif
-#ifdef SYSV
+#ifdef USE_UTMP
+# ifdef SYSV
utmpname (utmp_file);
setutent ();
(void) getutid (&utmp_entry);
pututline (&utmp_entry);
endutent ();
-#else
+# else
utmp = ope
HEADS UP: gone. All welcome .
Hello everyone, I just made various commits to FreeBSD HEAD to remove our old user accounting database interface (see utmp(5)) and replace it by the POSIX standardized utmpx interface (see getutxent(3)). This means we just got rid of some annoyances that are as old as the FreeBSD project itself: - Hostnames were originally restricted to 16 bytes, which is way too short for your average hostname generated by your ISP, but also for IPv6 addresses, which are at most 32 + 7 = 39 characters. - No support for login sessions not related to TTYs, like ppp(8), ftpd(8) sessions. - No support for multiple login sessions on one TTY, for example generated by login(1). I was not able to give us a smooth transition from utmp towards utmpx, simply because our utmp implementation offered almost no utility functions, which means all consumers modify the database files themselves. This means you should probably recompile any applications you're interested in that uses the user accounting database. I realize this may be quite uncomfortable, but we can't always win. [ This information is mainly for port maintainers: ] I've noticed there is some breakage in ports, but it shouldn't be too serious. I've seen cases where an application includes , even though it doesn't use anything provided by that header. In other cases they used fields like UT_NAMESIZE to derive the maximum user name length supported by the system, which is clearly not what this definition was intended for. I've incremented __FreeBSD_version to 97 to identify the import of utmpx. In case a certain port breaks badly, let me know and I'm willing to take a look at it. Be sure to give it a try and report any issues. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgpQip4OfOMJy.pgp Description: PGP signature
Re: [Patch] Proposal: USE_GNU89 switch
* Mel Flynn wrote:
> Are there any edge cases of (antiquated) ports that (indirectly) use
> bsd.sys.mk and as such get hit by:
> 11 # the default is gnu99 for now
> 12 CSTD?= gnu99
>
> In other words should one clean CFLAGS of -std before applying the
> forced one, similar as to what WITH_DEBUG in ports does for -O*.
Yes. This should fix it:
--- bsd.port.mk
+++ bsd.port.mk
@@ -2180,6 +2180,10 @@
.endif
.endif
+.if defined(USE_CSTD)
+CFLAGS:= ${CFLAGS:N-std=*} -std=${USE_CSTD}
+.endif
+
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS= #
--
Ed Schouten
WWW: http://80386.nl/
pgpgwTc7RwWrQ.pgp
Description: PGP signature
Re: [Patch] Proposal: USE_GNU89 switch
* Gabor Kovesdan wrote: > As for LLVM, probably it won't work out for the whole ports > tree. I don't know what's the portmgr opinion on this, if we start to > use LLVM in Ports Collection, we should reconsider the knob, though. LLVM/Clang support is trivial. Erwin Lansing fired up an experimental ports build for us and the numbers are *very* promising. There are still some issues with the compiler itself, but so far it seems the only architectural change to the tree that needs to be made, is a hint to fall back to C89. This is not just about LLVM/Clang support. If the GCC folks ever decide to switch to C99 by default, we'll have exactly the same issue. -- Ed Schouten WWW: http://80386.nl/ pgpD8x3SqNiQm.pgp Description: PGP signature
Re: [Patch] Proposal: USE_GNU89 switch
* Gabor Kovesdan wrote: > I don't think it's a good idea. This knob is completely superfluous and > thus should be avoided. One can just add -std to CFLAGS from a port > Makefile. Forced build are also possible without this stuff, you can set > this in /etc/make.conf. So how can we be sure all C compilers implement this switch? In bsd.port.mk I see some traces of ICC support. Using this approach it would also be possible to remap certain C standards to different compilers. Really, I really don't care how it's done, whether it's a flag or added to the compiler flags directly. I'm just saying adding it to CFLAGS directly sounds like a very bad idea. Adding it to /etc/make.conf sounds even worse, because it probably only confuses (autoconf) scripts that try to figure out a way to make the compiler speak C99. -- Ed Schouten WWW: http://80386.nl/ pgp7YgIl9fxzg.pgp Description: PGP signature
[Patch] Proposal: USE_GNU89 switch
Hi,
I'm proposing the following patch:
--- bsd.port.mk
+++ bsd.port.mk
@@ -2180,6 +2180,10 @@
.endif
.endif
+.if defined(USE_CSTD)
+CFLAGS+= -std=${USE_CSTD}
+.endif
+
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS=#
I thought it would be better to add USE_CSTD, instead of USE_GNU89,
where the port itself can specify which C standard to use. This will
also allow us to force builds with -std=gnu99 when needed, for example.
Any comments? Anyone who wants to integrate this patch into CVS, or
should I do it?
--
Ed Schouten
WWW: http://80386.nl/
pgpKIP1MUNLcg.pgp
Description: PGP signature
Re: Proposal: USE_GNU89 switch
* Pav Lucistnik wrote: > Placing CFLAGS+= -std=gnu89 would not work? > > Would the flag do anything else except adding to CFLAGS? Well, it could work, but maybe it would be nice to make it compiler agnostic. -- Ed Schouten WWW: http://80386.nl/ pgpoaGOme1njw.pgp Description: PGP signature
Proposal: USE_GNU89 switch
Hi folks, As some of you may have heard, Erwin Lansing (droso) has been helping us folks from the FreeBSD-Clang project [1] to build an entire ports tree with Clang. Even though we're hitting some compiler bugs (crashes, miscompilations, etc), things have been going very good. We noticed there is a certain class of build errors we're seeing, namely related to GNU or ISO C99 style inlining. GCC supported the `inline' keyword long before ISO standardized it, but unfortunately the semantics between GNU and ISO C99 style inlining are not the same. GCC solved this by using ISO C99 style inlining, only when -std=c99 or -std=gnu99 is passed to the compiler. By default it will use -std=gnu89. Clang does a good job at emulating this, but the difference is that it uses gnu99 by default. This is very good in my opinion. ISO C99 is 10 years old. We've noticed some ports (probably less than 100) really depend on GNU-style inlining. One option would be to just ignore the issue, but this will cause problems in the future anyway (by the time GCC itself will switch to gnu99). This is why I'm proposing a USE_GNU89 switch, to force the ports framework to add -std=gnu89 to the CFLAGS. I've been looking through /usr/ports/Mk. I suspect such a switch should be added to bsd.gcc.mk? I'm sending this message to gerald@ as well, because I've been told he is the maintainer of various GCC related bits. -- Ed Schouten WWW: http://80386.nl/ [1] http://wiki.freebsd.org/BuildingFreeBSDWithClang pgp6NZIfzLg1K.pgp Description: PGP signature
Fwd: svn commit: r191947 - head/sys/sys
Hi all, I just made this commit to SVN. I suspect it won't be a problem, but be sure to notify me when the build breaks. I'll be happy to fix. - Forwarded message from Ed Schouten - > Date: Sat, 9 May 2009 19:01:24 + (UTC) > From: Ed Schouten > To: src-committ...@freebsd.org, svn-src-...@freebsd.org, > svn-src-h...@freebsd.org > Subject: svn commit: r191947 - head/sys/sys > > Author: ed > Date: Sat May 9 19:01:24 2009 > New Revision: 191947 > URL: http://svn.freebsd.org/changeset/base/191947 > > Log: > Clean up . > > - Just use #error when including in the kernel. Code > hasn't used this header for years now and probably doesn't compile > anyway, because of -Werror. > > - Get rid of struct ttysize, TIOCGSIZE and TIOCSSIZE. All code nowadays > use both TIOC[GS]SIZE and TIOC[GS]WINSZ. Because we have other popular > systems that don't implement the first, it's of little use to support > interfaces nowadays. > > Modified: > head/sys/sys/ioctl.h > > - End forwarded message - -- Ed Schouten WWW: http://80386.nl/ pgpOD2MOP3zF2.pgp Description: PGP signature
Re: Bump libsndfile port to 1.0.19
* Ed Schouten wrote: > Shall I commit this patch to SVN? CVS. I've been hacking on src too much, I guess. -- Ed Schouten WWW: http://80386.nl/ pgpeKxGH3Ykl3.pgp Description: PGP signature
Bump libsndfile port to 1.0.19
Hello all,
Not long after we bumped the libsndfile port to 1.0.18, it turned out
there was an undisclosed security vulnerability. The author decided to
release a new version, 1.0.19. An advantage of this version is that it
also works with a *released* version of libvorbis, so we don't need the
awful regexes anymore.
Shall I commit this patch to SVN?
--
Ed Schouten
WWW: http://80386.nl/
--- audio/libsndfile/Makefile
+++ audio/libsndfile/Makefile
@@ -6,7 +6,7 @@
#
PORTNAME= libsndfile
-PORTVERSION= 1.0.18
+PORTVERSION= 1.0.19
CATEGORIES=audio
MASTER_SITES= http://www.mega-nerd.com/libsndfile/
@@ -37,10 +37,6 @@
.endif
post-patch:
- @${REINPLACE_CMD} \
- -e 's/vorbis >= 1\.2\.1/vorbis >= 1.2.0/g' \
- -e 's/vorbisenc >= 1\.2\.1/vorbisenc >= 1.2.0/g' \
- ${WRKSRC}/configure
@${REINPLACE_CMD} -e '/^SUBDIRS =/s/ doc / /g' ${WRKSRC}/Makefile.in
post-install:
--- audio/libsndfile/distinfo
+++ audio/libsndfile/distinfo
@@ -1,3 +1,3 @@
-MD5 (libsndfile-1.0.18.tar.gz) = 9fde6efb1b75ef38398acf856f252416
-SHA256 (libsndfile-1.0.18.tar.gz) =
c0821534a8510982d26b3085b148d9091dede53780733515eb49c99a65da293a
-SIZE (libsndfile-1.0.18.tar.gz) = 923666
+MD5 (libsndfile-1.0.19.tar.gz) = 8fa24b0c0a8758543427c9741ea06924
+SHA256 (libsndfile-1.0.19.tar.gz) =
4b567a02e15bcae25fa1aeb3361b4e2cb8b2ce08e9b53faa81f77a34fb2b5419
+SIZE (libsndfile-1.0.19.tar.gz) = 924368
pgpddogdicDgO.pgp
Description: PGP signature
Re: [headsup] call for assistance with ports broken on -current
* Mark Linimon wrote: > These changes are: tty changes, jail changes, import of strndup(3), ^^^ > ARP v2, libusb20, and possibly VFS. (libusb20 has not yet been run > through pointyhat, and its list is probably incomplete.) Working on it. -- Ed Schouten WWW: http://80386.nl/ pgpaoq718BybH.pgp Description: PGP signature
Re: /usr/bin/limits (WAS: Re: Apache.sh on current)
* Yuriy Tsibizov <[EMAIL PROTECTED]> wrote:
> (gdb) bt
> #0 0x in ?? ()
> #1 0x0804937d in main (argc=3, argv=0xbfbfed44)
> at /usr/src/usr.bin/limits/limits.c:341
> (gdb) l
> 341 val = resources[rcswhich].func(lc, resources[rcswhich].cap,
> limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur);
> 342 limits[rcswhich].rlim_cur = resources[rcswhich].func(lc,
> str, val, val);
> 343 /* maximum value overridden by resourcename or
> resourcename-max */
> 344 sprintf(str, "%s-max", resources[rcswhich].cap);
> 345 val = resources[rcswhich].func(lc, resources[rcswhich].cap,
> limits[rcswhich].rlim_max, limits[rcswhich].rlim_max);
> 346 limits[rcswhich].rlim_max = resources[rcswhich].func(lc,
> str, val, val);
> 347 }
> 348 }
> 349 }
> 350
> (gdb) p resources
> $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 }, {
> cap = 0x804adca "filesize", func = 0x8048c34 }, {
> cap = 0x804add3 "datasize", func = 0x8048c34 }, {
> cap = 0x804addc "stacksize", func = 0x8048c34 }, {
> cap = 0x804ade6 "coredumpsize", func = 0x8048c34 },{
> cap = 0x804adf3 "memoryuse", func = 0x8048c34 }, {
> cap = 0x804adfd "memorylocked", func = 0x8048c34 },{
> cap = 0x804ae0a "maxproc", func = 0x8048c94 }, {
> cap = 0x804ae12 "openfiles", func = 0x8048c94 }, {
> cap = 0x804ae1c "sbsize", func = 0x8048c34 }, {
> cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 }, {
> cap = 0x0, func = 0}}
Looks like I introduced this regression when importing MPSAFE TTY.
limits(1) dies when RLIMIT_NLIMITS is increased, but the array in
limits.c isn't extended (seems to be quite fragile).
Can you try the attached patch for limits(1)? Thanks!
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://80386.nl/
--- limits.c
+++ limits.c
@@ -76,17 +76,18 @@
{
{ "", "infinity", "Resource limits%s%s:\n", "-max", "-cur", "",
{
- { " cputime%-4s %8s", " secs\n", 1},
- { " filesize%-4s %8s", " kB\n",1024 },
- { " datasize%-4s %8s", " kB\n",1024 },
- { " stacksize%-4s%8s", " kB\n",1024 },
- { " coredumpsize%-4s %8s", " kB\n",1024 },
- { " memoryuse%-4s%8s", " kB\n",1024 },
- { " memorylocked%-4s %8s", " kB\n",1024 },
- { " maxprocesses%-4s %8s", "\n", 1},
- { " openfiles%-4s%8s", "\n", 1},
- { " sbsize%-4s %8s", " bytes\n", 1},
- { " vmemoryuse%-4s %8s", " kB\n",1024 }
+ { " cputime%-4s %8s", " secs\n", 1},
+ { " filesize%-4s %8s", " kB\n",1024 },
+ { " datasize%-4s %8s", " kB\n",1024 },
+ { " stacksize%-4s%8s", " kB\n",1024 },
+ { " coredumpsize%-4s %8s", " kB\n",1024 },
+ { " memoryuse%-4s%8s", " kB\n",1024 },
+ { " memorylocked%-4s %8s", " kB\n",1024 },
+ { " maxprocesses%-4s %8s", "\n", 1},
+ { " openfiles%-4s%8s", "\n", 1},
+ { " sbsize%-4s %8s", " bytes\n", 1},
+ { " vmemoryuse%-4s %8s", " kB\n",1024 },
+ { " pseudo-terminals%-4s %8s", "\n", 1}
}
},
{ "sh", "unlimited", "", " -H", " -S", "",
@@ -101,22 +102,24 @@
{ "ulimit%s -u %s", ";\n", 1},
{ "ulimit%s -n %s", ";\n", 1},
{ "ulimit%s -b %s", ";\n", 1},
- { "ulimit%s -v %s", ";\n", 1024 }
+ { "ulimit%s -v %s", ";\n", 1024 },
+ { "ulimit%s -p %s", ";\n", 1}
}
},
{ "csh", "unlimited", "", " -h", "", NULL,
{
- { "limit%s cputime %s", ";\n", 1},
- { "limit%s filesize %s", ";\n", 1024 },
- { "limit%s datasize %s", ";\n", 1024 },
- { "limit%s stacksize %s",";\n", 1024 },
- { "limit%s coredumpsize %s", ";\n", 1024 },
- { "limit%s memoryuse %s&
Re: HEADS UP: sgtty removal this weekend
Hello everyone, Heads down: http://lists.freebsd.org/pipermail/cvs-src/2008-June/092121.html I've also increased the __FreeBSD_version to 800039, which could be useful for you folks. I'd like to thank several people, especially miwi@ for committing most of my patches and pav@ for performing an experimental ports build with my patchset. Thanks! -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgpCfAK1R2f8U.pgp Description: PGP signature
HEADS UP: sgtty removal this weekend
Hello everyone, The last year I've been busy now and then removing the dependency of ports on the sgtty programming interface. sgtty is the old way of changing terminal attributes (baud rate, parameters, control characters, etc). Nowadays people should all be using the POSIX termios interface to do these things. When I started, there were many ports that used sgtty. See the following link for some of the PR's I've filed: http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports&text=sgtty&closedtoo=on Pav did an experimental ports run some days ago, which gave me a list of 20 ports that will be broken when sgtty gets removed from the operating system. I've sent patches for most of them, which still have to be reviewed/committed/etc. There aren't any high profile ports on this list. I'm sending this email for two reasons: Users: if you experience compilation problems on FreeBSD -CURRENT after weekend, be sure to update your ports tree. It might be possible that a fix has been committed already. Port maintainers: if you receive emails from tinderbox, related to , and , these could be related to the removal of this programming interface. Below is a list of ports that could get broken this weekend. The ports with an asterisk already have a patch in GNATS. - annextools* - beav - calctool* - conserver-com* - conserver* - fep - gap - ja-mh* - ja-sj3* - metamail* - moria - ncurses* - socks5* - splitvt* - vi-vnelvis* - vi-vnterm* Existing binaries that use the sgtty interface will still work after my commit. I'm only removing the programming interface, not the actual sgtty-to-termios compatibility layer. Some of you may already know I'm working on a new TTY layer for the FreeBSD operating system. This implementation will not support sgtty, which means I want to phase out this interface as soon as possible. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgphMk9uWP7Nx.pgp Description: PGP signature
pkg-config and library dependencies
Hello everyone,
This morning I ran a `readelf -d' on an application that I maintain
(audio/herrie) and I saw that my application depends on a lot of
libraries that the application doesn't use anyway, but get pulled in
recursively.
If I understand correctly, this is bad behaviour. If your application
uses GNOME's GLib, it always depends on libiconv, even though you don't
call any functions in those libraries. So when libiconv's major gets
bumped, you don't need to recompile a single library, but the entire
tree of applications.
It turns out that my configure script added some unneeded -lfoo's, so I
removed those, but there were still a lot of libraries that got added by
pkg-config and friends. It turns out that a lot of those .pc's add
rubbish:
| $ pkg-config --libs libcurl
| -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -lcurl
| $ pkg-config --libs glib-2.0
| -L/usr/local/lib -lglib-2.0 -liconv
| $ pkg-config --libs gthread-2.0
| -pthread -L/usr/local/lib -lgthread-2.0 -lglib-2.0 -liconv
The last case is even worse. Your application will link directly against
libthr if your use libgthread, voiding the entire idea of abstracting
the threads library. I guess the reason they were added, is keep things
working when compiling static binaries, because you can't recursively
pull dependencies in that case, but that is a wrong argument, because
you can then add the libraries to Libs.private and use
`pkg-config --static'.
I've added a bunch of patches for the ports I use for audio/herrie. I
didn't file any PR's yet, because I'd like to hear your opinions on this
matter. Are my findings correct?
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://g-rave.nl/
--- ftp/curl/files/patch-libcurl.pc.in 1970-01-01 01:00:00.0 +0100
+++ ftp/curl/files/patch-libcurl.pc.in 2007-12-22 11:18:46.0 +0100
@@ -0,0 +1,10 @@
+--- libcurl.pc.in 2007-02-18 10:41:27.0 +0100
libcurl.pc.in 2007-12-22 10:19:13.0 +0100
+@@ -33,6 +33,6 @@
+ URL: http://curl.haxx.se/
+ Description: Library to transfer files with ftp, http, etc.
+ Version: @VERSION@
+-Libs: -L${libdir} -lcurl @LDFLAGS@ @LIBS@
++Libs: -L${libdir} -lcurl
+ Libs.private: @LIBCURL_LIBS@ @LIBS@
+ Cflags: -I${includedir}
--- devel/glib20/files/patch-pkgconfig 1970-01-01 01:00:00.0 +0100
+++ devel/glib20/files/patch-pkgconfig 2007-12-22 13:00:56.0 +0100
@@ -0,0 +1,51 @@
+--- glib-2.0.pc.in 2007-11-24 07:41:02.0 +0100
glib-2.0.pc.in 2007-12-22 12:59:43.0 +0100
+@@ -10,6 +10,7 @@
+ Name: GLib
+ Description: C Utility Library
+ Version: @VERSION@
+-Libs: -L${libdir} -lglib-2.0 @INTLLIBS@ @ICONV_LIBS@
++Libs: -L${libdir} -lglib-2.0
++Libs.private: @INTLLIBS@ @ICONV_LIBS@
+ Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
+
+--- gmodule-2.0.pc.in 2007-11-24 07:41:02.0 +0100
gmodule-2.0.pc.in 2007-12-22 12:59:43.0 +0100
+@@ -9,5 +9,6 @@
+ Description: Dynamic module loader for GLib
+ Requires: glib-2.0
+ Version: @VERSION@
+-Libs: -L${libdir} @G_MODULE_LDFLAGS@ -lgmodule-2.0 @G_MODULE_LIBS@
++Libs: -L${libdir} @G_MODULE_LDFLAGS@ -lgmodule-2.0
++Libs.private: @G_MODULE_LIBS@
+ Cflags:
+--- gmodule-export-2.0.pc.in 2007-11-24 07:41:02.0 +0100
gmodule-export-2.0.pc.in 2007-12-22 12:59:43.0 +0100
+@@ -9,5 +9,6 @@
+ Description: Dynamic module loader for GLib
+ Requires: glib-2.0
+ Version: @VERSION@
+-Libs: -L${libdir} @G_MODULE_LDFLAGS@ -lgmodule-2.0 @G_MODULE_LIBS@
++Libs: -L${libdir} @G_MODULE_LDFLAGS@ -lgmodule-2.0
++Libs.private: @G_MODULE_LIBS@
+ Cflags:
+--- gmodule-no-export-2.0.pc.in 2007-11-24 07:41:02.0 +0100
gmodule-no-export-2.0.pc.in 2007-12-22 12:59:43.0 +0100
+@@ -9,5 +9,6 @@
+ Description: Dynamic module loader for GLib
+ Requires: glib-2.0
+ Version: @VERSION@
+-Libs: -L${libdir} -lgmodule-2.0 @G_MODULE_LIBS@
++Libs: -L${libdir} -lgmodule-2.0
++Libs.private: @G_MODULE_LIBS@
+ Cflags:
+--- gthread-2.0.pc.in 2007-11-24 07:41:02.0 +0100
gthread-2.0.pc.in 2007-12-22 12:59:43.0 +0100
+@@ -7,5 +7,6 @@
+ Description: Thread support for GLib
+ Requires: glib-2.0
+ Version: @VERSION@
+-Libs: -L${libdir} -lgthread-2.0 @G_THREAD_LIBS@
++Libs: -L${libdir} -lgthread-2.0
++Libs.private: @G_THREAD_LIBS@
+ Cflags: @G_THREAD_CFLAGS@
--- audio/libid3tag/files/patch-id3tag.pc.in 2003-12-29 20:54:29.0 +0100
+++ audio/libid3tag/files/patch-id3tag.pc.in 2007-12-22 11:31:05.0 +0100
@@ -1,6 +1,6 @@
--- id3tag.pc.in.orig 1970-01-01 09:00:00.0 +0900
+++ id3tag.pc.in 2003-11-11 08:42:38.0 +0900
-@@ -0,0 +1,10 @@
+@@ -0,0 +1,11 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
@@ -9,5 +9,6 @@
+Name: ID3TAG
+Description: libid3tag - ID3 tag manipulation library
+Version: @VERSION@
-+Libs: -L${libdir} -lid3tag -lz
++Libs: -L${libdir} -lid3tag
++Libs.private: -lz
+Cflags:
--- audio/libmad/files/ma
Using finch (libpurple) without X11
Hello, Last week I tried to use finch (the Pidgin CLI application) on one of the machines I maintain that doesn't have X11. For some reason, I must install X11 before I can compile libfinch. I don't really want to install X11 just to test some CLI tool, so I took a look and found two problems: - gnomehier depends on USE_XLIB. This shouldn't be needed, because the only thing this port does, is create some placeholder directories. - libpurple depends on gnomehier to install a desktop icon for Pidgin, even though Pidgin is not installed. The port should only install the desktop icon when actually installing Pidgin, right? -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpnRFgTpcL5W.pgp Description: PGP signature
Re: Moving applications from to
Hello, * Ed Schouten <[EMAIL PROTECTED]> wrote: > Last year Kris made a list of applications that still make use of > : > > http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064010.html I took a look at all the ports in the list, except the internationalized ones (Japanese, etc). Below is a complete list of PR's that I have opened in the last days: - ports/110354: irc/party - ports/110356: irc/blackened - ports/110358: net/freewais-sf - ports/110360: misc/heyu - ports/110361: games/jzip - ports/110363: ports-mgmt/portmanager - ports/110378: misc/heyu2 - ports/110384: textproc/ispell - ports/110386: net/openldap* - ports/110434: editors/aee - ports/110435: mail/metamail - ports/110439: cad/spice - ports/110440: cad/cider - ports/110443: astro/ephem - ports/110444: devel/xxgdb Almost all non-internationalized ports should now work without COMPAT_43TTY. Some ports still include , but don't use it anyway (kdenetwork3, gtar, etc). There are some ports, however, that I didn't port because they were too big, used flags that aren't present in termios, looked like they were written by a bunch of monkeys, didn't run on my architecture, etc., etc.: - cad/magic - databases/grass - editors/em - emulators/dlx - games/freebsd-games - games/tads - mail/xmail - math/gap - misc/fep - misc/mshell - net-mgmt/annextools - net/pmf - net/rmsg - net/ztelnet When all the PR's are closed, I guess most people can live without COMPAT_43TTY as well. Maybe we should add a permanent #warning to to warn people that they shouldn't use it and that it depends on COMPAT_43TTY? -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpFzmZ1zWA8G.pgp Description: PGP signature
Moving applications from to
Hello, As some of you may know, FreeBSD -CURRENT has split up the COMPAT_43 option to two separate ones: COMPAT_43, which implements a lot of old crufty system calls and COMPAT_43TTY, which implements the old BSD TTY line discipline. COMPAT_43 has been disabled on -CURRENT and some people hope that COMPAT_43TTY will also leave somewhere in the far future. Last year Kris made a list of applications that still make use of : http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064010.html I took a look at that list and basically you can divide it into two categories: - Applications that can use , but use at the moment (wrong flags in Makefiles or invalid search order in ./configure) - Applications that use , because they don't support termios I am willing to take a look at the first category of ports, because they aren't hard to port. The second group of ports are often the more older/deprecated ports that were written before termios existed, so in a lot of cases they aren't used that often anymore. I already took a look at the following ports: - 110354: irc/party - 110356: irc/blackened - 110358: net/freewais-sf - 110360: misc/heyu - 110361: games/jzip - 110363: ports-mgmt/portmanager I'd love to have an up-to-date list of ports that still make use of , but I don't have the material to run a complete ports build. Is there anyone that run a complete build of Ports with the following line in : #warning "Using old TTY line discipline" All ports that print this message during compilation still make use of . Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Second Life: don't want to maintain it ;-)
Hello everyone,
Yesterday the online game Second Life got released under the GNU GPL. I
took some time to port it to FreeBSD, but I cannot test/maintain it,
because I don't have OpenGL acceleration on my FreeBSD box and my
machine is quite cripple anyway (RELENG_6 -> CURRENT library horror).
Here's a patch if someone wants to maintain a port for it. Please notice
that Second Life depends on some ports that aren't in our ports tree:
openjpeg and xmlrpc-epi.
Yours,
--
Ed Schouten <[EMAIL PROTECTED]>
WWW: http://g-rave.nl/
--- linden/indra/SConstruct Sun Jan 7 23:50:12 2007
+++ linden/indra/SConstruct Tue Jan 9 09:10:47 2007
@@ -24,6 +24,8 @@
if platform == 'linux2':
platform = 'linux'
+platform = 'linux'
+
##
# GET VERSION#
##
@@ -104,7 +106,7 @@
try:
build_dir_prefix = os.environ['TEMP_BUILD_DIR']
except:
- build_dir_prefix = '/tmp/' + os.environ['USER']
+ build_dir_prefix = 'build'
build_dir = build_dir_prefix + os.getcwd() + '/' + system_str + '-' +
build_target + '-' + buildtype
@@ -181,15 +183,16 @@
flags += '-DLL_LINUX=1 '
system_link_flags +=
'-Wl,--version-script=newview/linux_tools/hidesymbols.ver '
if build_target == 'client':
- flags += '-DAPPID=secondlife -DLL_SDL=1 -DLL_X11=1 '
+ flags += '-DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0
-DLL_X11=1 '
flags += '-DLL_GTK=1 '
- client_external_libs += [ 'gtk-x11-2.0', 'elfio' ]
- include_dirs += [ ' ../libraries/' + system_str +
'/include/gtk-2.0' ]
- include_dirs += [ ' ../libraries/' + system_str +
'/include/glib-2.0']
- include_dirs += [ ' ../libraries/' + system_str +
'/include/pango-1.0' ]
- include_dirs += [ ' ../libraries/' + system_str +
'/include/atk-1.0' ]
- include_dirs += [ ' ../libraries/' + system_str +
'/include/ELFIO' ]
- include_dirs += [ ' ../libraries/' + system_str +
'/include/llfreetype2' ]
+ client_external_libs += [ 'ELFIO' ]
+
+ pipe = os.popen('pkg-config --cflags gtk+-2.0;
curl-config --cflags')
+ flags += pipe.read().replace('\n','')
+ pipe.close()
+ pipe = os.popen('pkg-config --libs gtk+-2.0;
curl-config --libs')
+ system_link_flags += pipe.read().replace('\n','') + ' '
+ pipe.close()
else:
# Mac-only flags
flags += '-x c++ -arch ppc -pipe -Wno-trigraphs
-fpascal-strings -faltivec -fasm-blocks -g -O2 -fmessage-length=0 -mtune=G4
-Wno-deprecated-declarations -Wno-invalid-offsetof -mmacosx-version-min=10.3
-DLL_DARWIN=1 -Wmost -Wno-sign-compare -Wno-switch -fpch-preprocess
-F./newview/build/Deployment -fconstant-cfstrings -ffor-scope -Wno-reorder
-isysroot /Developer/SDKs/MacOSX10.3.9.sdk '
@@ -205,7 +208,7 @@
# ENVIRONMENT #
- gcc_bin = 'g++-3.4'
+ gcc_bin = 'g++'
# If you strip more aggressively than -S then the quality of crash-
# logger backtraces deteriorates.
strip_cmd = 'strip -S -o $TARGET $SOURCE'
@@ -355,7 +358,7 @@
create_static_module('llxml')
create_static_module('lscript')
- net_external_libs = [ 'curl', 'ssl', 'crypto', 'aprutil-1', 'apr-1' ]
+ net_external_libs = [ 'ssl', 'crypto', 'aprutil-1', 'apr-1' ]
common_external_libs = net_external_libs + [ 'xmlrpc', 'expat', 'z' ]
if build_target == 'client':
@@ -381,7 +384,7 @@
##
output_bin = 'newview/secondlife-' + arch + '-bin'
- external_libs = client_external_libs + common_external_libs + [
'freetype', 'jpeg', 'SDL', 'GL', 'GLU', 'ogg', 'vorbisenc', 'vorbisfile',
'vorbis', 'fmod-3.75', 'db-4.2', 'openjpeg' ]
+ external_libs = client_external_libs + common_external_libs + [
'jpeg', &#
How to properly check for GCC 4.1 in port
Hello, I'm the maintainer for the net/totd port. This port doesn't compile with GCC 4.1. The easiest fix is to add -Wno-pointer-sign to the CFLAGS. GCC 3.4 doesn't allow this option. What's the nicest way to add a conditional to the port Makefile to check for a GCC version? Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpcXzcXAsewu.pgp Description: PGP signature
