Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction
I seem to recall a bug where some CPU models don't properly set registers after a CPUID instruction (e.g., http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s#rev1.150). Is it possible this CPU is one of those? Maybe Go needs similar workarounds? A way to test that hypothesis would be to add MOVL $0, BX MOVL $0, CX MOVL $0, DX before each of these CPUID instructions: src/cmd/dist/cpuid_386.s:9: CPUID src/runtime/asm_386.s:30: CPUID src/runtime/asm_386.s:47: CPUID On Fri, Aug 7, 2015 at 3:22 PM, Ted Unangst wrote: > Stuart Henderson wrote: >> >> I don't think a flavour is warranted, i386 packages are meant to run >> on all supported CPUs so if the runtime detection is insufficient >> we should just always set this variable. > > talk to upstream? this sounds like a bug if the runtime detection is > insufficient. unconditionally disabling sse would be a pessimization for most > users. >
Re: UPDATE: lang/go 1.6
2016-03-28 18:42 GMT-07:00 Juan Francisco Cantero Hurtado : > @@ -448,6 +501,7 @@ go/pkg/bootstrap/pkg${GOCFG}/bootstrap/c > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/arm64.a > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/big.a > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/gc.a > +go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/mips64.a > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/ppc64.a > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/x86.a > go/pkg/bootstrap/pkg${GOCFG}/bootstrap/internal/ FYI, the official Go binary releases do not include the pkg/bootstrap directory. It shouldn't cause any problems either, but it's just a waste of disk space.
Re: tedu lang/ghc?
On Tue, May 7, 2013 at 2:50 PM, Matthias Kilian wrote: > Spoiler: I'm not talking about Haskell but about ghc here. To ask a possibly dumb question, what are our other options for Haskell at the moment? E.g., it looks like x11/xmonad depends on lang/ghc, so does removing ghc mean removing xmonad?
Re: wip eclipse for testing
On Mon, May 13, 2013 at 7:08 PM, frantisek holop wrote: > i would like to test the wip eclipse port > but there is no way i could build that monster > on my netbook. what are my options? By wip eclipse port, do you mean https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse? If so, that port doesn't actually build all of eclipse. It downloads a prebuilt Linux Eclipse release, just rebuilds the native shared libraries, and replaces them in the Linux release. You'll probably need more memory to run it than to build it. :)
Update devel/ninja to 1.3.3
This updates ninja to 1.3.3, which includes the OpenBSD patches upstream and is the official version now used to build and test Chrome. ok? Index: Makefile === RCS file: /cvs/ports/devel/ninja/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile2 May 2013 19:09:18 - 1.1.1.1 +++ Makefile21 May 2013 06:06:17 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.1.1.1 2013/05/02 19:09:18 matthew Exp $ COMMENT = a small build system with a focus on speed -V =1.2.0 +V =1.3.3 DISTNAME = ninja-${V} CATEGORIES = devel HOMEPAGE = http://martine.github.io/ninja/ Index: distinfo === RCS file: /cvs/ports/devel/ninja/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo2 May 2013 19:09:18 - 1.1.1.1 +++ distinfo21 May 2013 06:06:17 - @@ -1,2 +1,2 @@ -SHA256 (ninja-1.2.0.tar.gz) = gToeZQ9Q7W6X01O7zjMTSNOet/2tT7pT5Kmb59qTnnI= -SIZE (ninja-1.2.0.tar.gz) = 136233 +SHA256 (ninja-1.3.3.tar.gz) = YhKvacK9ubbnpKW0WAJIOuv7XYln5DeYH6ZvDaPRej4= +SIZE (ninja-1.3.3.tar.gz) = 147703 Index: patches/patch-src_subprocess-posix_cc === RCS file: patches/patch-src_subprocess-posix_cc diff -N patches/patch-src_subprocess-posix_cc --- patches/patch-src_subprocess-posix_cc 2 May 2013 19:09:18 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,70 +0,0 @@ -$OpenBSD: patch-src_subprocess-posix_cc,v 1.1.1.1 2013/05/02 19:09:18 matthew Exp $ src/subprocess-posix.cc.orig Fri Apr 5 09:36:12 2013 -+++ src/subprocess-posix.ccThu May 2 12:01:23 2013 -@@ -25,13 +25,6 @@ - #include - #include - --// Older versions of glibc (like 2.4) won't find this in . glibc --// 2.4 keeps it in , though attempting to include that --// will redefine the pollfd structure. --#ifndef POLLRDHUP --#define POLLRDHUP 0x2000 --#endif -- - #include "util.h" - - Subprocess::Subprocess() : fd_(-1), pid_(-1) { -@@ -49,12 +42,12 @@ bool Subprocess::Start(SubprocessSet* set, const strin - if (pipe(output_pipe) < 0) - Fatal("pipe: %s", strerror(errno)); - fd_ = output_pipe[0]; --#if !defined(linux) -- // On linux we use ppoll in DoWork(); elsewhere we use pselect and so must -- // avoid overly-large FDs. -+#if !defined(linux) && !defined(__OpenBSD__) -+ // On Linux and OpenBSD, we use ppoll in DoWork(); elsewhere we use pselect -+ // and so must avoid overly-large FDs. - if (fd_ >= static_cast(FD_SETSIZE)) - Fatal("pipe: %s", strerror(EMFILE)); --#endif // !linux -+#endif // !linux && !__OpenBSD__ - SetCloseOnExec(fd_); - - pid_ = fork(); -@@ -189,7 +182,7 @@ Subprocess *SubprocessSet::Add(const string& command) - return subprocess; - } - --#ifdef linux -+#if defined(linux) || defined(__OpenBSD__) - bool SubprocessSet::DoWork() { - vector fds; - nfds_t nfds = 0; -@@ -199,7 +192,7 @@ bool SubprocessSet::DoWork() { - int fd = (*i)->fd_; - if (fd < 0) - continue; --pollfd pfd = { fd, POLLIN | POLLPRI | POLLRDHUP, 0 }; -+pollfd pfd = { fd, POLLIN | POLLPRI, 0 }; - fds.push_back(pfd); - ++nfds; - } -@@ -236,7 +229,7 @@ bool SubprocessSet::DoWork() { - return false; - } - --#else // linux -+#else // linux || __OpenBSD__ - bool SubprocessSet::DoWork() { - fd_set set; - int nfds = 0; -@@ -279,7 +272,7 @@ bool SubprocessSet::DoWork() { - - return false; - } --#endif // linux -+#endif // linux || __OpenBSD__ - - Subprocess* SubprocessSet::NextFinished() { - if (finished_.empty())
Re: Ninja build failures on sgi and mips64el
There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(&k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner wrote: > Mathew, > > I just wanted to let you know we have discovered some build failures on > sgi and mips64el during the "Build ninja using itself" phase. It looks > like something is segfaulting. Below is the build output although it > isn't very helpful. > > I can test diffs on mips64el and plan on trying to compile with debug > symbols to see if I can get more info out of the core file that is left. > > Building ninja using itself... > *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd > /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 && /usr/bin/env -i CXX="c++"CC=cc > PYTHONUS...) > *** Error 1 in devel/ninja > (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') > *** Error 1 in devel/ninja > (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') > ===> Exiting devel/ninja with an error > /bin/sh: exit 1: not found > *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') > Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist > > -- > James Turner
Re: Ninja build failures on sgi and mips64el
Jasper (or someone) will have to. My OpenBSD workstation is down until at least tomorrow. Glad to hear that fix worked though. On Mon, Jul 1, 2013 at 1:40 PM, David Coppa wrote: > On Mon, Jul 1, 2013 at 10:37 PM, Jasper Lievisse Adriaanse > wrote: >> This fixes the build on mips64. > > Thanks a lot, Mathew. > > Please go ahead and commit it, you or Jasper ;) > > Ciao, > David > >> On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote: >>> There's an unaligned word access in ninja's murmurhash implementation: >>> https://github.com/martine/ninja/blob/master/src/hash_map.h >>> >>> We need to change >>> >>> unsigned int k = *(unsigned int *)data; >>> >>> to >>> >>> unsigned int k; >>> memcpy(&k, data, sizeof k); >>> >>> and it should fix the unaligned accesses on strict arches like sparc64 and >>> mips. >>> >>> Sorry, I'm not able to fix this myself right now, but I can help >>> upstream the fix tomorrow. (I'm of course ok with any ports fix for >>> this.) >>> >>> >>> On Mon, Jul 1, 2013 at 10:24 AM, James Turner wrote: >>> > Mathew, >>> > >>> > I just wanted to let you know we have discovered some build failures on >>> > sgi and mips64el during the "Build ninja using itself" phase. It looks >>> > like something is segfaulting. Below is the build output although it >>> > isn't very helpful. >>> > >>> > I can test diffs on mips64el and plan on trying to compile with debug >>> > symbols to see if I can get more info out of the core file that is left. >>> > >>> > Building ninja using itself... >>> > *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd >>> > /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 && /usr/bin/env -i CXX="c++"CC=cc >>> > PYTHONUS...) >>> > *** Error 1 in devel/ninja >>> > (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') >>> > *** Error 1 in devel/ninja >>> > (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') >>> > ===> Exiting devel/ninja with an error >>> > /bin/sh: exit 1: not found >>> > *** Error 127 in /usr/ports >>> > (infrastructure/mk/bsd.port.subdir.mk:147'build') >>> > Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist >>> > >>> > -- >>> > James Turner >>> >> >> -- >> Regards, >> >> Jasper Lievisse Adriaanse, >> Engineering team M:tier >>
Re: UPDATE: emulators/mupen64plus
On Sun, Jul 7, 2013 at 8:36 PM, Anthony J. Bentley wrote: > Upstream released another graphics plugin, video-glide64mk2, but I haven't > made a port for it because it #includes , which doesn't seem to > appear with either GCC 4.6 or clang. > Is the source file C or C++?
Re: UPDATE: LLVM 3.3
On Thu, Jul 18, 2013 at 9:56 AM, Stuart Henderson wrote: > On 2013/07/18 22:48, Jonathan Gray wrote: > > @comment lib/libgtest.a > > @comment lib/libgtest_main.a > > +lib/libgtest.so > > +lib/libgtest_main.so > > presumably the above 4 lines want replacing with > > @comment lib/libgtest.so > @comment lib/libgtest_main.so > > ...? > > (not sure why this was originally commented, but presumably it should stay > commented?) > Probably to avoid conflicting with devel/gtest, and I agree it should stay commented.
Re: unbreak smtp-vilter
On Fri, Aug 9, 2013 at 9:45 AM, Ian Darwin wrote: > +-LDADD+= -nostdlib > ++LDADD+= --nodefaultlib Hm, I would think this needs to be "-nodefaultlibs" instead of "--nodefaultlib" (i.e., only one hyphen and add the s).
Re: unbreak smtp-vilter
Looks ok to me, but I haven't tested it or anything. On Fri, Aug 9, 2013 at 10:26 AM, Ian Darwin wrote: > Sharper cluestick from matthew@. > > OK now? > > Index: Makefile > === > RCS file: /cvs/ports/mail/smtp-vilter/Makefile,v > retrieving revision 1.53 > diff -u -p -r1.53 Makefile > --- Makefile9 May 2013 18:47:53 - 1.53 > +++ Makefile9 Aug 2013 17:25:11 - > @@ -3,7 +3,7 @@ > COMMENT= sendmail milter to scan messages for viruses and spam > > DISTNAME= smtp-vilter-1.3.8 > -REVISION= 0 > +REVISION= 1 > > CATEGORIES=mail > > Index: patches/patch-backend_vilter-attachment_Makefile > === > RCS file: patches/patch-backend_vilter-attachment_Makefile > diff -N patches/patch-backend_vilter-attachment_Makefile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-backend_vilter-attachment_Makefile9 Aug 2013 17:25:11 > - > @@ -0,0 +1,12 @@ > +$OpenBSD$ > +--- backend/vilter-attachment/Makefile.origSat May 4 07:07:11 2013 > backend/vilter-attachment/Makefile Fri Aug 9 12:19:15 2013 > +@@ -22,7 +22,7 @@ LIBDIR= /usr/pkg/lib/smtp-vilter > + CFLAGS+= -I/usr/src/gnu/usr.sbin/sendmail/include > + .endif > + > +-LDADD+= -nostdlib > ++LDADD+= -nodefaultlibs > + > + beforeinstall: > + -mkdir -p ${DESTDIR}${LIBDIR} > Index: patches/patch-backend_vilter-clamd_Makefile > === > RCS file: patches/patch-backend_vilter-clamd_Makefile > diff -N patches/patch-backend_vilter-clamd_Makefile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-backend_vilter-clamd_Makefile 9 Aug 2013 17:25:11 - > @@ -0,0 +1,12 @@ > +$OpenBSD$ > +--- backend/vilter-clamd/Makefile.orig Sat May 4 07:05:12 2013 > backend/vilter-clamd/Makefile Fri Aug 9 12:19:18 2013 > +@@ -22,7 +22,7 @@ LIBDIR= /usr/pkg/lib/smtp-vilter > + CFLAGS+= -I/usr/src/gnu/usr.sbin/sendmail/include > + .endif > + > +-LDADD+= -nostdlib > ++LDADD+= -nodefaultlibs > + > + beforeinstall: > + -mkdir -p ${DESTDIR}${LIBDIR} > Index: patches/patch-backend_vilter-icap_Makefile > === > RCS file: patches/patch-backend_vilter-icap_Makefile > diff -N patches/patch-backend_vilter-icap_Makefile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-backend_vilter-icap_Makefile 9 Aug 2013 17:25:11 - > @@ -0,0 +1,12 @@ > +$OpenBSD$ > +--- backend/vilter-icap/Makefile.orig Sat May 4 07:08:28 2013 > backend/vilter-icap/Makefile Fri Aug 9 12:19:21 2013 > +@@ -22,7 +22,7 @@ LIBDIR= /usr/pkg/lib/smtp-vilter > + CFLAGS+= -I/usr/src/gnu/usr.sbin/sendmail/include > + .endif > + > +-LDADD+= -nostdlib > ++LDADD+= -nodefaultlibs > + > + beforeinstall: > + -mkdir -p ${DESTDIR}${LIBDIR} > Index: patches/patch-backend_vilter-regex_Makefile > === > RCS file: patches/patch-backend_vilter-regex_Makefile > diff -N patches/patch-backend_vilter-regex_Makefile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-backend_vilter-regex_Makefile 9 Aug 2013 17:25:11 - > @@ -0,0 +1,12 @@ > +$OpenBSD$ > +--- backend/vilter-regex/Makefile.orig Sat May 4 07:10:56 2013 > backend/vilter-regex/Makefile Fri Aug 9 12:19:25 2013 > +@@ -22,7 +22,7 @@ LIBDIR= /usr/pkg/lib/smtp-vilter > + CFLAGS+= -I/usr/src/gnu/usr.sbin/sendmail/include > + .endif > + > +-LDADD+= -nostdlib > ++LDADD+= -nodefaultlibs > + > + beforeinstall: > + -mkdir -p ${DESTDIR}${LIBDIR} > Index: patches/patch-backend_vilter-spamd_Makefile > === > RCS file: patches/patch-backend_vilter-spamd_Makefile > diff -N patches/patch-backend_vilter-spamd_Makefile > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-backend_vilter-spamd_Makefile 9 Aug 2013 17:25:11 - > @@ -0,0 +1,12 @@ > +$OpenBSD$ > +--- backend/vilter-spamd/Makefile.orig Sat May 4 07:11:57 2013 > backend/vilter-spamd/Makefile Fri Aug 9 12:19:29 2013 > +@@ -22,7 +22,7 @@ LIBDIR= /usr/pkg/lib/smtp-vilter > + CFLAGS+= -I/usr/src/gnu/usr.sbin/sendmail/include > + .endif > + > +-LDADD+= -nostdlib > ++LDADD+= -nodefaultlibs > + > + beforeinstall: > + -mkdir -p ${DESTDIR}${LIBDIR} >
Re: x11/blackbox: "time_t" fix (too late i see .. but please read)
On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian wrote: > + bt::timeval::timeval(const ::timeval &t) > +- : tv_sec(t.tv_sec), tv_usec(t.tv_usec) > +-{ } > ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; } What's the point of these changes?
Re: [bug] chromium problem since 26.0.1410.43
On Thu, Apr 11, 2013 at 4:54 AM, Kenneth R Westerback wrote: > On Thu, Apr 11, 2013 at 05:11:15AM +, Ted Unangst wrote: >> Visiting www.apple.com displays the sad tab and this (repeating): >> [5303:600661216:0411/005904:ERROR:omnibox_view_gtk.cc(431)] Not implemented >> reached in virtual void OmniboxViewGtk::ApplyCaretVisibility() >> >> Runing as env G_SLICE=always-malloc chrome helps a little, but not really. >> It's still pretty useless. >> > > I see these same messages on amd64, but I have not been experiencing any > crashes. FWIW, the ApplyCaretVisibility() warnings were removed recently from trunk, as apparently they're considered harmless: https://code.google.com/p/chromium/issues/detail?id=172302 https://codereview.chromium.org/12470003
[NEW] devel/ninja
Attached is a port of the Ninja build system: http://martine.github.io/ninja/ It needs ppoll() support, so you'll need to test with a recent release snapshot containing libc.so.68.1. The patches to add OpenBSD support have already been merged upstream (https://github.com/martine/ninja/pull/565), so they'll be included in the next upstream release. ok? $ cat pkg/DESCR Ninja is a small build system with a focus on speed.
Re: [NEW] devel/ninja
On Wed, May 01, 2013 at 03:24:25PM -0700, Matthew Dempsky wrote: > Attached is a port of the Ninja build system: http://martine.github.io/ninja/ D'oh, attached for real this time... ninja.tar.gz Description: application/tar-gz
Re: [NEW] devel/ninja
On Thu, May 2, 2013 at 12:40 AM, David Coppa wrote: > Python is only needed for building ninja, so I've added MODPY_RUNDEP=No. No, it's needed at run time too for the "ninja -t browse" functionality too. > patch-bootstrap_py is not needed, 'cause ninja only wants libc, > libm and libstdc++ that come all from base. Ok by me. For the regress tests, it wants to build/link against gtest, but I didn't try to wire that up to the Makefile. > I've added a patch 'patch-src_util_cc' to get the number of cpus > on OpenBSD too (just a couple of extra #ifdefs, the code is the > same as for FreeBSD). I don't think that's necessary. We already support sysconf(_SC_NPROCESSORS_ONLN), which is implemented by just grabbing the hw.ncpu sysctl anyway.
Re: [NEW] devel/ninja
On Thu, May 2, 2013 at 2:21 AM, David Coppa wrote: > Ah... Didn't spot this. No problem. I almost didn't notice it either until I decided to run "grep python src/*.cc". :) > So, ok dcoppa@ to import this. Thanks, I'll import it tomorrow then. It's too late for me to risk a botched cvs import right now. :)
Re: amd64 bulk breakage 2013-12-29
On Mon, Dec 30, 2013 at 9:47 AM, Christian Weisgerber wrote: > math/octave undefined reference to `__guard' That's odd. Can you send me the build logs from this (or put them somewhere I can access them)?
Re: amd64 bulk breakage 2013-12-29
On Mon, Dec 30, 2013 at 12:13 PM, Pascal Stumpf wrote: > I don't have logs, but the problem is that lang/g77 still emits > references go __guard. The following diff should fix it (currently > compiling math/octave). Ah, makes sense. Diff looks ok to me assuming it builds successfully.
Re: POSIX standard as manual pages
Just curious, are the older POSIX standards available as man pages too? Is there a way to install them side-by-side? I'm by far most interested in the current up-to-date standard, but being able to easily cross-reference older revisions is sometimes handy. (E.g., when trying to make sure we're still compliant with older standards.) On Fri, May 9, 2014 at 8:18 AM, Vadim Zhukov wrote: > 09.05.2014 17:17 пользователь "Ingo Schwarze" написал: >> >> Hi Dmitrij and Vadim, >> >> Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400: >> > 09.05.2014 2:03 "Dmitrij D. Czarkoff" : >> >> >> Why not shorten "man-pages-posix" to just "posix"? >> >> That's what i originally suggested, too: >> >> From: Ingo Schwarze >> Date: Fri, 24 Jan 2014 00:45:56 +0100 >> To: Vadim Zhukov >> Cc: ports@openbsd.org >> Subject: Re: POSIX standard as manual pages >> [...] >> Do not install these manuals to /usr/local/man/, >> but to a dedicated directory, something like >> /usr/local/share/doc/posix/man/man{1,3}/*.{1,3} >> >> One advantage is that if any other POSIX documentation should ever >> show up in ports, it could go into share/doc/posix, too. >> There is no danger of clashes, posix/man is quite clear, >> man-pages-posix/man somewhat redundant. >> >> > It's upstream name, FWIW. >> >> The argument that a port should follow upstream's name (unless it is >> very badly chosen) and that most subdirectories of /usr/local/share/doc/ >> follow the respective ports' names is a valid one. >> >> > I won't mind to change actual folder if there will be a real reason. >> > You won't go to this folder directly anyway, will you? >> >> I already have your port installed because it is useful for me >> when doing work regarding POSIX conformance and when doing work >> regarding HISTORY sections. I already cd'ed into that directory >> several times, mostly to do multiple consecutive grep -R commands. >> Given that all this is still man(7), not mdoc(7), the new apropos >> is not yet very helpful, so searching still needs to be done the >> old way. > > This is a good point, thank you for input. The packages are for people, not > the other direction. So if people use this directory, err, directly, then > it's better to have an exception. I'll rename the folder when I'll get my > laptop back to normal operation. > >> Then again, i don't feel strongly either way, both paths seem >> acceptable to me. It's your port, and you are more used to ports >> naming conventions, so you should decide this detail, i think. >> >> Yours, >> Ingo >>
Re: NEW: net/ucspi-tcp
On Tue, May 27, 2014 at 2:14 PM, Jérémie Courrèges-Anglas wrote: > No proper license, approval required for patches and/or no > redistribution of binary packages, bla, bla. I may not remember the > details well enough; like most people that were interested in > daemontools/qmail/djbdns/blah, but stopped using them long time ago. FWIW, most of DJB's code has been public domain for a while now: http://cr.yp.to/distributors.html In particular, ucspi-tcp has been public domain for 6+ years now.
Re: [update] lang/go 1.3
On Fri, Jun 20, 2014 at 08:44:11PM +1000, Joel Sing wrote: > Index: pkg/PFRAG.amd64 > === > RCS file: /cvs/ports/lang/go/pkg/PFRAG.amd64,v > retrieving revision 1.3 > diff -u -p -r1.3 PFRAG.amd64 > --- pkg/PFRAG.amd64 2 Dec 2013 15:35:49 - 1.3 > +++ pkg/PFRAG.amd64 20 Jun 2014 10:40:46 - > @@ -1,5 +1,4 @@ > @comment $OpenBSD: PFRAG.amd64,v 1.3 2013/12/02 15:35:49 jsing Exp $ > -go/src/cmd/6l/enam.c > go/src/pkg/runtime/zasm_openbsd_amd64.h > go/src/pkg/runtime/zgoarch_amd64.go > go/src/pkg/runtime/zmalloc_openbsd_amd64.c > Index: pkg/PFRAG.i386 > === > RCS file: /cvs/ports/lang/go/pkg/PFRAG.i386,v > retrieving revision 1.3 > diff -u -p -r1.3 PFRAG.i386 > --- pkg/PFRAG.i3862 Dec 2013 15:35:49 - 1.3 > +++ pkg/PFRAG.i38620 Jun 2014 10:40:46 - > @@ -1,5 +1,4 @@ > @comment $OpenBSD: PFRAG.i386,v 1.3 2013/12/02 15:35:49 jsing Exp $ > -go/src/cmd/8l/enam.c > go/src/pkg/runtime/zasm_openbsd_386.h > go/src/pkg/runtime/zgoarch_386.go > go/src/pkg/runtime/zmalloc_openbsd_386.c > Index: pkg/PLIST > === > RCS file: /cvs/ports/lang/go/pkg/PLIST,v > retrieving revision 1.9 > diff -u -p -r1.9 PLIST > --- pkg/PLIST 25 Mar 2014 13:21:20 - 1.9 > +++ pkg/PLIST 20 Jun 2014 10:40:48 - [...] > @@ -2862,7 +3097,17 @@ go/src/pkg/runtime/vlop_arm_test.go > go/src/pkg/runtime/vlrt_386.c > go/src/pkg/runtime/vlrt_arm.c > go/src/pkg/runtime/zaexperiment.h > +go/src/pkg/runtime/zalg_openbsd_386.c > +go/src/pkg/runtime/zchan_openbsd_386.c > +go/src/pkg/runtime/zcomplex_openbsd_386.c > +go/src/pkg/runtime/zcpuprof_openbsd_386.c > go/src/pkg/runtime/zgoos_openbsd.go > +go/src/pkg/runtime/zhashmap_openbsd_386.c > +go/src/pkg/runtime/ziface_openbsd_386.c > +go/src/pkg/runtime/zlfstack_openbsd_386.c > +go/src/pkg/runtime/zrdebug_openbsd_386.c > +go/src/pkg/runtime/zslice_openbsd_386.c > +go/src/pkg/runtime/zsymtab_openbsd_386.c > go/src/pkg/runtime/zversion.go > go/src/pkg/sort/ > go/src/pkg/sort/example_interface_test.go This seems wrong. Shouldn't the _386.c files go into PFRAG.i386, and corresponding _amd64.c files should be added to PFRAG.amd64?
Re: [update] lang/go 1.3
On Sun, Jun 29, 2014 at 9:19 AM, Joel Sing wrote: > Longer answer, these particular ones should be - all of the source > (including 386, amd64, arm, etc) always get installed. However, the ones > you've spotted (runtime/z*.c) are generated during the build and should > be only installed for the given architecture. That's why I pointed out the runtime/z* files specifically, and not any of the hundreds of other _386 and _amd64 files in PLIST. :) > Revised diff follows... ok matthew
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
On Thu, Mar 15, 2012 at 3:19 AM, Marc Espie wrote: > #define __glibcxx_max(T) \ > - (__glibcxx_signed (T) ? ((T)1 << __glibcxx_digits (T)) - 1 : ~(T)0) > + (__glibcxx_signed (T) ? \ > + (T)1 << (__glibcxx_digits (T) - 1)) - 1) << 1) + 1) : ~(T)0) > + How about (T)(((unsigned T)1 << __glibc_digits(T)) - 1)? Also, we should use (T)-1 << __glibc_digits(T) in __glibc_min to avoid relying on overflow behavior for signed types.
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
I'm pretty sure unsigned int is never a signed type.
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
Oh even if it's not signed that ternary branch will still be in code. I see. Hm. On May 10, 2012 9:23 AM, "Matthew Dempsky" wrote:
Re: Combining ports built with PCC and GCC
On Tue, May 8, 2012 at 7:43 PM, Brett wrote: > I am wondering if this will work ok the other way round? In theory, GCC and PCC should implement the same ABI and so it should work either way. In practice, good luck.
Re: [WIP] devel/eclipse4/sdk
On Sun, May 20, 2012 at 2:26 PM, Stefan Unterweger wrote: > You have missed a build dependency on 'archivers/unzip'. Good catch, thanks. I'll fix that in the next version I mail out. > However, even if everything seems to build, it still fails at the end > when trying to install it. It seems as if there is some JAR file > missing, but I don't understand the build process well enough to guess > what might be failing here. I've unpacked all the distfiles to see > whether there's just some problem in picking the JAR up, but it isn't > there anywhere in the ports directory. Yeah, for some reason the i386 and amd64 Eclipse distribution jars use slightly different versions of some of the bundled components. I'll make sure the next version handles this correctly. > Thanks in the meantime for your effort. :o) Thanks for testing!
Bulk build test for mbsnrtowcs() and wcsnrtombs()?
Diff below adds mbsnrtowcs() and wcsnrtombs(), which are new POSIX 2008 functions. I'd appreciate if someone could run this through a bulk build and let me know if anything breaks or misbehaves. Thanks! Index: include/wchar.h === RCS file: /home/mdempsky/anoncvs/cvs/src/include/wchar.h,v retrieving revision 1.22 diff -u -p -r1.22 wchar.h --- include/wchar.h 5 Jan 2012 20:37:50 - 1.22 +++ include/wchar.h 25 May 2012 06:01:50 - @@ -158,6 +158,11 @@ unsigned long int wcstoul(const wchar_t wchar_t*wcsdup(const wchar_t *); int wcscasecmp(const wchar_t *, const wchar_t *); int wcsncasecmp(const wchar_t *, const wchar_t *, size_t); + +size_t mbsnrtowcs(wchar_t * __restrict, const char ** __restrict, size_t, +size_t, mbstate_t * __restrict); +size_t wcsnrtombs(char * __restrict, const wchar_t ** __restrict, size_t, +size_t, mbstate_t * __restrict); #endif #if __ISO_C_VISIBLE >= 1999 Index: lib/libc/locale/multibyte_citrus.c === RCS file: /home/mdempsky/anoncvs/cvs/src/lib/libc/locale/multibyte_citrus.c,v retrieving revision 1.1 diff -u -p -r1.1 multibyte_citrus.c --- lib/libc/locale/multibyte_citrus.c 27 Jul 2010 16:59:04 - 1.1 +++ lib/libc/locale/multibyte_citrus.c 25 May 2012 16:45:00 - @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "citrus_ctype.h" @@ -65,7 +66,19 @@ mbrtowc(wchar_t *pwc, const char *s, siz } size_t -mbsrtowcs(wchar_t *pwcs, const char **s, size_t n, mbstate_t *ps) +mbsrtowcs(wchar_t *dst, const char **src, size_t len, mbstate_t *ps) +{ + static mbstate_t mbs; + struct _citrus_ctype_rec *cc; + + if (ps == NULL) + ps = &mbs; + return (mbsnrtowcs(dst, src, SIZE_MAX, len, ps)); +} + +size_t +mbsnrtowcs(wchar_t *dst, const char **src, size_t nmc, size_t len, +mbstate_t *ps) { static mbstate_t mbs; struct _citrus_ctype_rec *cc; @@ -73,7 +86,8 @@ mbsrtowcs(wchar_t *pwcs, const char **s, if (ps == NULL) ps = &mbs; cc = _CurrentRuneLocale->rl_citrus_ctype; - return (*cc->cc_ops->co_mbsrtowcs)(pwcs, s, n, _ps_to_private(ps)); + return (*cc->cc_ops->co_mbsnrtowcs)(dst, src, nmc, len, + _ps_to_private(ps)); } size_t @@ -89,7 +103,18 @@ wcrtomb(char *s, wchar_t wc, mbstate_t * } size_t -wcsrtombs(char *s, const wchar_t **ppwcs, size_t n, mbstate_t *ps) +wcsrtombs(char *dst, const wchar_t **src, size_t len, mbstate_t *ps) +{ + static mbstate_t mbs; + + if (ps == NULL) + ps = &mbs; + return (wcsnrtombs(dst, src, SIZE_MAX, len, ps)); +} + +size_t +wcsnrtombs(char *dst, const wchar_t **src, size_t nwc, size_t len, +mbstate_t *ps) { static mbstate_t mbs; struct _citrus_ctype_rec *cc; @@ -97,5 +122,6 @@ wcsrtombs(char *s, const wchar_t **ppwcs if (ps == NULL) ps = &mbs; cc = _CurrentRuneLocale->rl_citrus_ctype; - return (*cc->cc_ops->co_wcsrtombs)(s, ppwcs, n, _ps_to_private(ps)); + return (*cc->cc_ops->co_wcsnrtombs)(dst, src, nwc, len, + _ps_to_private(ps)); } Index: lib/libc/citrus/citrus_ctype_local.h === RCS file: /home/mdempsky/anoncvs/cvs/src/lib/libc/citrus/citrus_ctype_local.h,v retrieving revision 1.2 diff -u -p -r1.2 citrus_ctype_local.h --- lib/libc/citrus/citrus_ctype_local.h27 Jul 2010 16:59:03 - 1.2 +++ lib/libc/citrus/citrus_ctype_local.h25 May 2012 01:36:32 - @@ -36,43 +36,45 @@ size_t _citrus_##_e_##_ctype_mbrtowc(wch const char * __restrict, size_t, \ void * __restrict); \ int_citrus_##_e_##_ctype_mbsinit(const void * __restrict); \ -size_t _citrus_##_e_##_ctype_mbsrtowcs(wchar_t * __restrict, \ - const char ** __restrict, \ - size_t, void * __restrict); \ +size_t _citrus_##_e_##_ctype_mbsnrtowcs(wchar_t * __restrict, \ +const char ** __restrict, \ +size_t, size_t,\ +void * __restrict);\ size_t _citrus_##_e_##_ctype_wcrtomb(char * __restrict, wchar_t, \ void * __restrict); \ -size_t _citrus_##_e_##_ctype_wcsrtombs(char * __restrict, \ - const wchar_t ** __restrict,\ - size_t, void * __restrict); \ +size_t _citrus_##_e_##_ctype_wcsnrtombs(char * __restrict, \ +const wchar_t ** __rest
Re: Bulk build test for mbsnrtowcs() and wcsnrtombs()?
(FYI, naddy@ already helped me with a bulk build test of this diff; I'm just waiting on code reviews from a few developers now.) On Mon, Jun 4, 2012 at 3:58 AM, Brett wrote: > In case it is helpful, stuff I used a lot since rebuilding (and all working > as before): > > xxxterm, mplayer, dnsmasq, leafpad, rxvt-unicode, dmenu, jwm, xcursor-themes, > snownews, getmail, centerim, mupdf, vitunes, sylpheed (3.2.0beta7, not the > ports version). Cool, thanks for the report. Are you testing with an ASCII or UTF-8 locale?
Re: GSlice: failed to allocate
On Sat, Jun 23, 2012 at 12:21 AM, Steven Mestdagh wrote: > just upgraded to the latest amd64 snapshot and packages. > has anyone else seen this error? Sorry, that's my fault. :( I fixed posix_memalign() in libc to handle large alignment requests. I knew glib would start taking advantage of it, but I was just thinking of it as a bugfix so I didn't think to bump the shlib version. In retrospect, that was a mistake.
Re: GSlice: failed to allocate
Also, if you can post the output from "ls /usr/lib/libc.so.*" and "ldd `which xfwm4`", we can tell you what's out of sync and how to fix it. Most likely your latest installed libc.so is libc.so.65.0 (2 days old), but some of your packages are using libc.so.64.2 still but were built within the last 5 days (when full posix_memalign() support was implemented) and the last snapshot you installed was older than that. If that's the case, the simplest fix is to wait for updated packages to be available. (Currently, at least ftp.usa.openbsd.org has a glib2 package built against libc.so.65.0, but xfwm4 is still built against libc.so.64.2.) On Sat, Jun 23, 2012 at 1:11 AM, Matthew Dempsky wrote: > On Sat, Jun 23, 2012 at 12:21 AM, Steven Mestdagh wrote: >> just upgraded to the latest amd64 snapshot and packages. >> has anyone else seen this error? > > Sorry, that's my fault. :( I fixed posix_memalign() in libc to handle > large alignment requests. I knew glib would start taking advantage of > it, but I was just thinking of it as a bugfix so I didn't think to > bump the shlib version. In retrospect, that was a mistake.
Re: [WIP] devel/eclipse4/sdk
On Wed, Jun 6, 2012 at 6:25 AM, Stefan Sperling wrote: > Any news? I just committed devel/eclipse4/sdk to the openbsd-wip repo on github: https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse4/sdk This port is based on the recent 4.2 release instead of 4.1.2. Some very quick testing looks like it works okay on amd64. I also faked building it with MACHINE_ARCH=i386 and it seemed to compile okay, so I think I've now accounted for the version discrepancies between Eclipse's x86 and x86_64 releases. I think I've fixed all of the other issues reported in this thread so far.
Re: UPDATE: GCC - update library link spec for libpthread
On Thu, Aug 16, 2012 at 7:55 AM, Brad Smith wrote: > Update the GCC ports to sync the OpenBSD LIB_SPEC with the base gcc4 > for the new libpthread handling. > > Tested with gcc 3.3/4.2/4.6 on amd64. Looks right to me. ok matthew
Re: libc.so.66.0 (system): bad major
On Sun, Aug 26, 2012 at 10:25 PM, Scott McEachern wrote: > ===> Installing groff-1.21p8 from /usr/ports/packages/amd64/all/ > Can't install groff-1.21p8 because of libraries > |library c.65.0 not found > | /usr/lib/libc.so.66.0 (system): bad major > *** Error code 1 I suspect you compiled the groff package against an older snapshot which had libc.so.65.0. The new snapshots have libc.so.66.0 now, and if you did a clean reinstall of base then you no longer have libc.so.65.0. I thought the ports tools are supposed to gracefully handle this, but maybe not. Try deleting the groff package and rebuilding it from source to see if that helps.
Fix lang/erlang
This fixes erlang to properly link its shared objects on OpenBSD, and lets at least devel/rebar now build. "make update-plist" tells me there's a new pkg/PLIST, but then fails to write it for some currently unknown reason. I don't expect the plist actually changes with this, but someone might double check that. ok? Index: Makefile === RCS file: /cvs/ports/lang/erlang/Makefile,v retrieving revision 1.51 diff -u -p -r1.51 Makefile --- Makefile30 Aug 2012 20:54:59 - 1.51 +++ Makefile5 Sep 2012 22:08:33 - @@ -7,7 +7,7 @@ V= R15B01 DISTNAME= otp_src_${V} PKGNAME= erlang-15b.01 EPOCH= 0 -REVISION= 0 +REVISION= 1 CATEGORIES=lang # Erlang Public License @@ -41,6 +41,7 @@ USE_GROFF = Yes CONFIGURE_STYLE=autoconf no-autoheader CONFIGURE_ENV= LDFLAGS="${LDFLAGS} -pthread" AUTOCONF_VERSION=2.59 +AUTOCONF_DIR= ${WRKSRC} ${WRKSRC}/erts MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/erts/autoconf \ ${WRKSRC}/lib/erl_interface/src/auxdir Index: patches/patch-erts_configure_in === RCS file: patches/patch-erts_configure_in diff -N patches/patch-erts_configure_in --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-erts_configure_in 5 Sep 2012 22:08:33 - @@ -0,0 +1,15 @@ +$OpenBSD$ +--- erts/configure.in.orig Sun Apr 1 11:15:00 2012 erts/configure.in Wed Sep 5 14:52:08 2012 +@@ -3548,6 +3548,11 @@ case $host_os in + DED_LDFLAGS="-m32 $DED_LDFLAGS" + fi + ;; ++ openbsd*) ++ DED_LD="$CC" ++ DED_LD_FLAG_RUNTIME_LIBRARY_PATH="$CFLAG_RUNTIME_LIBRARY_PATH" ++ DED_LDFLAGS="-shared" ++ ;; + osf*) + # NOTE! Whitespace after -rpath is important. + DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-rpath "
Re: lang/go build failing on i386
On Thu, Sep 13, 2012 at 11:26:39PM +0100, Stuart Henderson wrote: > Seeing this repeatably fail in my current i386 build, the go port hasn't > changed, anyone have an idea what might be doing it? As mentioned on icb, the Go linker doesn't set a PT_NOTE segment for OpenBSD identification like it does for NetBSD executables. However, it does set EI_OSABI to ELFOSABI_OPENBSD, and it probably wouldn't hurt for the kernel to skip the PT_NOTE check in that case. Please try this diff to see if it fixes lang/go. (Sorry, untested.) Index: exec_elf.c === RCS file: /cvs/src/sys/kern/exec_elf.c,v retrieving revision 1.88 diff -u -p -r1.88 exec_elf.c --- exec_elf.c 11 Sep 2012 15:44:19 - 1.88 +++ exec_elf.c 13 Sep 2012 23:07:36 - @@ -592,7 +592,8 @@ ELFNAME2(exec,makecmds)(struct proc *p, * set the ep_emul field in the exec package structure. */ error = ENOEXEC; - if (ELFNAME(os_pt_note)(p, epp, epp->ep_hdr, "OpenBSD", 8, 4) != 0) { + if (eh->e_ident[EI_OSABI] != ELFOSABI_OPENBSD && + ELFNAME(os_pt_note)(p, epp, epp->ep_hdr, "OpenBSD", 8, 4) != 0) { for (i = 0; ELFNAME(probes)[i].func != NULL && error; i++) error = (*ELFNAME(probes)[i].func)(p, epp, interp, &pos); if (error)
Changing llvm/clang++ to use libstdc++ from ports instead of base
I know the trees locked right now, but I thought I'd send this out now so it doesn't get lost. Right now, clang++ tries to use libstdc++ from base (from g++ 4.2.1), but even incredibly trivial programs fail to compile with it (e.g., hello world using iostream). Using the libstdc++ from ports (i.e., g++ 4.2.4) seems to work much better. Anyway, the hacky diff below makes a few changes: 1. Searches for C++ header files from and links against ports libstdc++ instead of base libstdc++. (Also, FWIW, libstdc++ 4.2.4 appears to still be GPL2+, not GPL3+ like the rest of GCC 4.2.4; maybe worth investigating bringing into base.) 2. When linking with -pthread, pass -lpthread to ld(1) instead of -pthread. 3. Eliminates the -L/opt/gcc4/... patch hunk that only affected AuroraUX's driver code, not OpenBSD's. I expect the literal "/usr/local" strings will need to be fixed somehow, but not sure the best solution. Also, I feel weird about adding -L/usr/local/lib to the linker line, but eg++ already has this behavior, so maybe it's okay (and should be done by default, not just for C++ code). I can't yet build Chromium with this diff (weird segmentation faults in resulting executables that I haven't investigated yet), but it at least gets further than crashing on the very first C++ file. :) Index: patches/patch-tools_clang_lib_Driver_Tools_cpp === RCS file: /cvs/ports/devel/llvm/patches/patch-tools_clang_lib_Driver_Tools_cpp,v retrieving revision 1.6 diff -N -u -p patches/patch-tools_clang_lib_Driver_Tools_cpp --- patches/patch-tools_clang_lib_Driver_Tools_cpp 13 Jan 2011 00:15:50 - 1.6 +++ patches/patch-tools_clang_lib_Driver_Tools_cpp 15 Feb 2011 18:50:21 - @@ -1,12 +1,22 @@ $OpenBSD: patch-tools_clang_lib_Driver_Tools_cpp,v 1.6 2011/01/13 00:15:50 jeremy Exp $ --- tools/clang/lib/Driver/Tools.cpp.orig Thu Sep 2 16:59:25 2010 -+++ tools/clang/lib/Driver/Tools.cpp Thu Jan 6 11:29:39 2011 -@@ -2631,7 +2631,7 @@ void auroraux::Link::ConstructJob(Compilation &C, cons tools/clang/lib/Driver/Tools.cpp Mon Feb 14 17:32:05 2011 +@@ -2778,7 +2778,8 @@ + if (!Args.hasArg(options::OPT_nostdlib) && + !Args.hasArg(options::OPT_nodefaultlibs)) { + if (D.CCCIsCXX) { +- CmdArgs.push_back("-lstdc++"); ++ CmdArgs.push_back("-L/usr/local/lib"); ++ CmdArgs.push_back("-lestdc++"); + CmdArgs.push_back("-lm"); + } - CmdArgs.push_back(Args.MakeArgString("-L/opt/gcc4/lib/gcc/" -+ getToolChain().getTripleString() -- + "/4.2.4")); -+ + "/4.2.1")); +@@ -2787,7 +2788,7 @@ + CmdArgs.push_back("-lgcc"); - Args.AddAllArgs(CmdArgs, options::OPT_L); - Args.AddAllArgs(CmdArgs, options::OPT_T_Group); + if (Args.hasArg(options::OPT_pthread)) +- CmdArgs.push_back("-pthread"); ++ CmdArgs.push_back("-lpthread"); + if (!Args.hasArg(options::OPT_shared)) + CmdArgs.push_back("-lc"); + CmdArgs.push_back("-lgcc"); Index: patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp === RCS file: /cvs/ports/devel/llvm/patches/Attic/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp,v diff -N -u -p patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp --- /dev/null 15 Feb 2011 11:50:21 - +++ patches/patch-tools_clang_lib_Frontend_InitHeaderSearch_cpp 15 Feb 2011 18:50:21 - @@ -0,0 +1,12 @@ +$OpenBSD$ +--- tools/clang/lib/Frontend/InitHeaderSearch.cpp.orig Fri Sep 3 09:45:53 2010 tools/clang/lib/Frontend/InitHeaderSearch.cpp Mon Feb 14 16:27:35 2011 +@@ -751,7 +751,7 @@ + std::string t = triple.getTriple(); + if (t.substr(0, 6) == "x86_64") + t.replace(0, 6, "amd64"); +-AddGnuCPlusPlusIncludePaths("/usr/include/g++", ++AddGnuCPlusPlusIncludePaths("/usr/local/include/c++/4.2.4", + t, "", "", triple); + break; + }
Re: Changing llvm/clang++ to use libstdc++ from ports instead of base
On Tue, Feb 15, 2011 at 11:57:44PM +0100, Marc Espie wrote: > Finding out why it doesn't work with g++ from src would be > the correct approach. Investigating further, it seems to boil down to _GLIBCXX_USE_C99_CHECK in /usr/include/g++/*/bits/os_defines.h. Including from base effectively feeds the following to the compiler: typedef unsigned long size_t; extern "C" { int snprintf(char *, size_t, const char *, ...) __attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ (3))) __attribute__((__bounded__ (__string__,1,2))); } namespace std { extern "C" int (snprintf)(char * restrict, size_t, const char * restrict, ...); using ::snprintf; } g++ doesn't mind the conflicting definitions for snprintf (it doesn't seem to care about *any* conflicts actually; you could put "int snprintf(double x)" and it's still happy), but clang++ does. We don't define anything in os_defines.h in libstdc++ from ports, so the the second chunk of code above never gets included. Perhaps we can get rid of _GLIBCXX_USE_C99_CHECK (along with the other *_CHECK defines) since it's apparently useless even with g++ and just causes compile trouble with clang++? Also, maybe useful to add _GLIBCXX_USE_C99 to ports libstdc++? (I'll test these ideas out later.)
Re: Changing llvm/clang++ to use libstdc++ from ports instead of base
On Wed, Feb 16, 2011 at 11:00 AM, Amit Kulkarni wrote: > I did as Matthew said. I just defined the checks to be 0, then > followed rebuilding gcc4 instructions in FAQ/current.html by > rebuilding the libstdc++ headers (rm -rf /usr/include/g++ etc...). I think we can just get rid of the *_{CHECK,DYNAMIC} defines altogether. E.g., Ubuntu doesn't bother putting them in their os_defines.h. Anyway, there's also at least a libc __cxa_finalize fix needed for clang++ to be usable. I'll put together some diffs to send out post unlock and try to keep the release-testing distractions to a minimum in the mean time. :)
Various WIP CAD ports (e.g., OpenSCAD, HeeksCAD, OpenCASCADE, ...)
One of my coworkers got me interested in CNC milling, so I've been looking into various 3D CAD/CAM software and working on porting them to OpenBSD. They're still very much WIP (very sloppy makefiles, require amd64-specific patches to base to add functionality, probably non-functional in some cases, etc), but I thought I'd go ahead and share in case anyone's interested: https://github.com/mdempsky/openbsd-stuff Currently there are ports for CGAL, OpenCSG, OpenSCAD, OpenCASCADE, OpenCAMLib, libarea, libactp, HeeksCAD (including HeeksCNC), and dfu-programmer. The examples bundled with OpenSCAD seem to render fine, but I can't really comment on the functionality of the others just yet except that they build and install. Anyway, if you're interested in any of these let me know and I'll work on making them more generally useful.
UPDATE: www/chromium 9.0.597.107
The diff below updates chromium to 9.0.597.107 (the latest stable channel release), which fixes multiple security issues[1]. Additionally, it removes the vestigial LINK=/usr/bin/g++ environment variable, enables SSE2 support on amd64, and fixes a bad #ifdef patch (noticed by a failed attempt to build with Clang). No immediately noticeable regressions on amd64. ok? [1] http://googlechromereleases.blogspot.com/2011/02/stable-channel-update_28.html Index: Makefile === RCS file: /cvs/ports/www/chromium/Makefile,v retrieving revision 1.25 diff -u -p Makefile --- Makefile2 Mar 2011 11:11:31 - 1.25 +++ Makefile3 Mar 2011 06:12:45 - @@ -4,11 +4,9 @@ ONLY_FOR_ARCHS=i386 amd64 COMMENT= Chromium browser -V= 9.0.597.94 +V= 9.0.597.107 DISTNAME= chromium-${V} -REVISION= 1 - CATEGORIES=www HOMEPAGE= http://sightly.net/peter/openbsd/chromium/ @@ -61,8 +59,7 @@ LIB_DEPENDS= devel/libexecinfo \ # Set BUILDTYPE to Debug (or omit it) for a debug build BUILDTYPE= Release -MAKE_ENV= BUILDTYPE=${BUILDTYPE} V=1 \ - LINK=/usr/bin/g++ +MAKE_ENV= BUILDTYPE=${BUILDTYPE} V=1 USE_GMAKE= Yes @@ -85,8 +82,10 @@ GYP_DEFS=-Duse_system_bzip2=1 \ -Duse_system_vpx=1 \ -Duse_system_zlib=0 \ -Ddisable_nacl=1 \ - -Ddisable_sse2=1 \ -DOS=openbsd +.if ${MACHINE_ARCH} != "amd64" +GYP_DEFS+= -Ddisable_sse2=1 +.endif pre-configure: @ln -sf ${MODPY_BIN} ${WRKDIR}/bin/python Index: distinfo === RCS file: /cvs/ports/www/chromium/distinfo,v retrieving revision 1.5 diff -u -p distinfo --- distinfo12 Feb 2011 10:42:43 - 1.5 +++ distinfo3 Mar 2011 06:12:45 - @@ -1,5 +1,5 @@ -MD5 (chromium-9.0.597.94.tar.bz2) = QThrPfdDV18jJcTGTW17xw== -RMD160 (chromium-9.0.597.94.tar.bz2) = WBbCjd+usxxbiqiC3iJIx4D4yww= -SHA1 (chromium-9.0.597.94.tar.bz2) = SocNpBriV4HkgG7CyVcDKC/MxNg= -SHA256 (chromium-9.0.597.94.tar.bz2) = cZTZmaA7tUgTzEn5eN2I9bCM3UDO5Ny+T/VjnAyj6NU= -SIZE (chromium-9.0.597.94.tar.bz2) = 140800844 +MD5 (chromium-9.0.597.107.tar.bz2) = RUHyuE31gWGCYu/hWJAbLw== +RMD160 (chromium-9.0.597.107.tar.bz2) = fuyAs2P8xHtGDppUwhlA0wnMB50= +SHA1 (chromium-9.0.597.107.tar.bz2) = TryT4gL4f3JO/7F0RZw/XCoQyc0= +SHA256 (chromium-9.0.597.107.tar.bz2) = H95jUBfNJ44JJCR43jRpFm3Yn5PJXOZ6z438Z93fgVk= +SIZE (chromium-9.0.597.107.tar.bz2) = 141198237 Index: patches/patch-app_gfx_gl_gl_context_egl_cc === RCS file: /cvs/ports/www/chromium/patches/patch-app_gfx_gl_gl_context_egl_cc,v retrieving revision 1.1 diff -u -p patches/patch-app_gfx_gl_gl_context_egl_cc --- patches/patch-app_gfx_gl_gl_context_egl_cc 8 Feb 2011 09:43:02 - 1.1 +++ patches/patch-app_gfx_gl_gl_context_egl_cc 3 Mar 2011 06:12:45 - @@ -15,7 +15,7 @@ $OpenBSD: patch-app_gfx_gl_gl_context_egl_cc,v 1.1 201 return true; -#ifdef OS_LINUX -+#ifdef OS_LINUX || defined(OS_OPENBSD) ++#if defined(OS_LINUX) || defined(OS_OPENBSD) EGLNativeDisplayType native_display = x11_util::GetXDisplay(); #else EGLNativeDisplayType native_display = EGL_DEFAULT_DISPLAY; Index: patches/patch-gpu_gpu_gyp === RCS file: /cvs/ports/www/chromium/patches/patch-gpu_gpu_gyp,v retrieving revision 1.2 diff -u -p patches/patch-gpu_gpu_gyp --- patches/patch-gpu_gpu_gyp 8 Feb 2011 09:43:02 - 1.2 +++ patches/patch-gpu_gpu_gyp 3 Mar 2011 06:12:45 - @@ -1,7 +1,7 @@ $OpenBSD: patch-gpu_gpu_gyp,v 1.2 2011/02/08 09:43:02 espie Exp $ gpu/gpu.gyp.orig Fri Jan 21 10:19:48 2011 -+++ gpu/gpu.gypSun Jan 23 23:27:34 2011 -@@ -180,7 +180,7 @@ +--- gpu/gpu.gyp.orig Fri Feb 18 02:22:12 2011 gpu/gpu.gypWed Mar 2 18:00:11 2011 +@@ -206,7 +206,7 @@ 'command_buffer/service/texture_manager.cc', ], 'conditions': [ Index: pkg/PLIST === RCS file: /cvs/ports/www/chromium/pkg/PLIST,v retrieving revision 1.4 diff -u -p pkg/PLIST --- pkg/PLIST 8 Feb 2011 09:43:02 - 1.4 +++ pkg/PLIST 3 Mar 2011 06:12:45 - @@ -1,7 +1,7 @@ @comment $OpenBSD: PLIST,v 1.4 2011/02/08 09:43:02 espie Exp $ bin/chrome chrome/ -chrome/chrome +@bin chrome/chrome chrome/chrome.pak chrome/ffmpegsumo_nolink chrome/libffmpegsumo.so
NEW: devel/dfu-programmer 0.5.4
Attached is a port for dfu-programmer (http://dfu-programmer.sf.net/). To build it successfully, you'll need to ensure you have r1.8 or newer of /usr/include/stdarg.h installed. I've tested on amd64 by successfully updating the 8u2 firmware on my Arduino Uno. (I know the ports tree is still locked for new directories; just sending this out in advance.) dfu-programmer.tar.gz Description: application/tar-gz
Re: emacs 23.2 (the return)
On Wed, Mar 9, 2011 at 5:07 AM, Manuel Giraud wrote: > Anyone to test on other archs (and eventually, we'll have more recent > emacs in OpenBSD 5.0) ? Seems to work on amd64. I noticed that "make port-lib-depends-check" says that the X11-xcb WANTLIB is extraneous. Also, is it correct that bin/emacs and bin/emacs-${VERSION} aren't marked as @bin in pkg/PLIST-main? It seems to be because the executables are installed with the sticky bit.
Re: emacs 23.2 (the return)
On Thu, Mar 10, 2011 at 6:46 AM, Manuel Giraud wrote: > It is an obsolete feature but it seems to be caused by the emacs install > process. Don't know if it worth the effort to fight for it upstream. post-install can easily fix it up. However, I don't understand exactly what @bin signifies, so I don't know if it's worth fixing or not either. But if so, the existing emacs ports might deserve a rev bump to fix them as well.
Re: re emacs23 update
On Tue, Mar 15, 2011 at 9:35 AM, Manuel Giraud wrote: > Here's the new version of emacs 23 port. Tested and ok on i386 GENERIC.MP In post-install, since bin/emacs and bin/emacs-${VERSION} are hard linked to the same file, you only need to chmod -t one of them. Shouldn't you get rid of the REVISION-{el,main} = 0 lines too, since it's a version bump? Building on amd64 fails because of not finding tsang-b5.el.gz. You'll need to do something like: post-install: chmod -t ${PREFIX}/bin/emacs .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "mips64" gzip -f ${PREFIX}/share/emacs/${VERSION}/leim/quail/tsang-b5.el post-extract: touch ${WRKSRC}/leim/quail/tsang-b5.el .endif
Updating Eclipse?
Is anyone working on (or have plans to work on) updating the Eclipse port? The version in tree appears to have languished behind quite a bit. FreeBSD appears to have a port for 3.6.1; haven't looked yet how useful it is for OpenBSD though: http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/eclipse-devel/
Re: boost warning fix
On Tue, Mar 29, 2011 at 8:15 AM, Federico G. Schwindt wrote: > Comments? Any OKs? I think this changes the ABI, so you should probably bump the soname if you're going to commit this. However, it seems like a deliberate decision on their part to omit the virtual tag here (not familiar with context to know why, but since it's protected, I can imagine it's safe), so I'm inclined to leave it alone.
Re: Making clang++ actually work ( WAS Re: Changing llvm/clang++ to use libstdc++ from ports instead of base)
On Fri, Apr 08, 2011 at 12:43:03PM -0500, Amit Kulkarni wrote: > I am in the process of updating llvm+clang from 2.8 ==> 2.9 > (maintainer is ports@). jsg@ already has an update for this. I believe he's just checking for broken dependencies now. > Will some guru please find time to investigate this issue? I'm hardly a guru on this topic, but I think the diff below should resolve the problem. I'm double checking now that this doesn't cause any build problems for base+xenocara, but it'd be nice if someone could test to see if it causes problems for the ports tree. (This only affects gcc4 arches.) Index: gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h --- gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h 26 May 2010 11:23:06 - 1.2 +++ gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h 8 Apr 2011 18:13:19 - @@ -35,12 +35,5 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE -typedef __builtin_va_list __gnuc_va_list; #endif
[NEW] graphics/opencsg
Attached is a port for graphics/opencsg; you can also find it at https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg The port's pretty simple, but a few things I want to check first: 1. The port only builds a shared object; should/must I patch it to build a static library too? Or mark it as only for shared arches? 2. The main code is licensed GPLv2 (with an exception for linking against the CGAL library), but it bundles GLEW (BSD) and RenderTexture (zlib). I patched the build files to use graphics/glew instead of the bundled GLEW. Is it correct to summarize this as "GPLv2 with CGAL exception"? (RenderTexture is only used internally; it's not intentionally exposed to users, though currently the symbols are still visible in the resulting .so.) 3. Should I make a separate RenderTexture port instead, and patch OpenCSG to depend on that? 4. libopencsg.so depends on symbols from libGLEW.so, but upstream doesn't actually link it against libGLEW.so, so I only added graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS. Is this correct, or should I patch it to link against libGLEW.so and/or add to LIB_DEPENDS instead? opencsg-1.3.1.tar.gz Description: application/tar-gz
Re: [NEW] graphics/opencsg
Ping? On Mon, Apr 18, 2011 at 03:08:42PM -0700, Matthew Dempsky wrote: > Attached is a port for graphics/opencsg; you can also find it at > https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg > > The port's pretty simple, but a few things I want to check first: > > 1. The port only builds a shared object; should/must I patch it to > build a static library too? Or mark it as only for shared > arches? > > 2. The main code is licensed GPLv2 (with an exception for linking > against the CGAL library), but it bundles GLEW (BSD) and > RenderTexture (zlib). I patched the build files to use > graphics/glew instead of the bundled GLEW. Is it correct to > summarize this as "GPLv2 with CGAL exception"? (RenderTexture is > only used internally; it's not intentionally exposed to users, > though currently the symbols are still visible in the resulting > .so.) > > 3. Should I make a separate RenderTexture port instead, and patch > OpenCSG to depend on that? > > 4. libopencsg.so depends on symbols from libGLEW.so, but upstream > doesn't actually link it against libGLEW.so, so I only added > graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS. Is this > correct, or should I patch it to link against libGLEW.so and/or > add to LIB_DEPENDS instead?
[NEW] math/cgal
The attached port is for the Computational Geometry Algorithms Library (see http://www.cgal.org). You can also find my port on github at https://github.com/mdempsky/openbsd-stuff/tree/master/ports/math/cgal. Be advised that this port depends on fenv.h support in libm, which martynas@ just committed / enabled. (However, vax doesn't support fenv.h, so should I add an explicit NOT_FOR_ARCHS=vax?) ok? cgal.tar.gz Description: application/tar-gz
[NEW] cad/openscad
Attached is a port for OpenSCAD, "The Programmers Solid 3D CAD Modeller". It depends on my two other outstanding ports, graphics/opencsg and math/cgal. Also, as with those, you can find the port on my github page at https://github.com/mdempsky/openbsd-stuff/tree/master/ports/cad/openscad ok? openscad.tar.gz Description: application/tar-gz
Re: [NEW] math/cgal
On Thu, Apr 28, 2011 at 3:13 PM, Landry Breuil wrote: > Yes for the latter. Will do then. > Bah, CGAL packages so many headers.. Yeah... =/ If you think that's bad, you should check out my OpenCASCADE port: https://github.com/mdempsky/openbsd-stuff/blob/master/ports/cad/opencascade/pkg/PLIST https://github.com/mdempsky/openbsd-stuff/blob/master/ports/cad/opencascade/pkg/PFRAG.shared (Still badly WIP, and I just discovered they've cranked the version twice since I last even looked at it... ugh.) > You're missing the $OpenBSD$ Rcs ids in Makefile's comment, and do we > really need bin/make_macosx_app_zomg ?? I doubt it, but I figured since it was installed by default that I'd leave it in. I'm happy to remove it. > Otherwise reads good, same comment applies to openscad. Cool. I'll fix that one up too, and then send another email with updated ports.
Re: [NEW] graphics/opencsg
On Thu, Apr 28, 2011 at 2:39 PM, Landry Breuil wrote: >> 3. Should I make a separate RenderTexture port instead, and patch >> OpenCSG to depend on that? > > That would be better, if more stuff want to depend on it later. If not.. > your call. I think I'll leave it bundled for the time being then. It's just one .cpp and one .h file, and RenderTexture upstream doesn't even bother distributing a real Makefile with it. >> 4. libopencsg.so depends on symbols from libGLEW.so, but upstream >> doesn't actually link it against libGLEW.so, so I only added >> graphics/glew to BUILD_DEPENDS rather than LIB_DEPENDS. Is this >> correct, or should I patch it to link against libGLEW.so and/or >> add to LIB_DEPENDS instead? > > It all depends if a binary linked with it fails at runtime or not. I'm > not sure if there are previous similar things with libGL*.so. > Explicitely linking with it might be safer. Will do.
Re: gtar, xz (was: Re: CVS: cvs.openbsd.org: ports)
On Wed, Jun 15, 2011 at 3:11 PM, Amit Kulkarni wrote: > devel/coccinelle? That looks awesome. Has anyone played with using it for OpenBSD code (e.g., kernel and base)?
Re: Update: ninja-1.5.1
ok with me if none of the test builds expose brokenness.
Re: devel/snappy
On Sat, Jul 9, 2011 at 8:23 PM, Piotr Sikora wrote: >> I started looking at this myself a few days ago in case it >> might be any use for hibernate support (then I spotted it was >> C++ and figured probably not) so I had half a port in my >> tree already ;-) > > It comes with C bindings (snappy-c.h), so this shouldn't be a problem, > unless there is some "no C++ in base" policy? Not strictly, but the kernel at least doesn't even support linking with C++ code.
Re: systrace problem with mkdirat and openat
On Sat, Jul 23, 2011 at 9:43 AM, Markus Lude wrote: > systrace: deny user: markus, prog: /usr/local/bin/gtar, pid: > 25619(0)[31757], policy: /usr/bin/make, filters: 197, syscall: > native-mkdirat(318), args: 24 > /usr/local/bin/gtar: git-1.7.5: Cannot mkdir: Operation not permitted This is a known limitation of USE_SYSTRACE at the moment. Until systrace(8) understands the new *at(8) system calls, you'll need to either disable USE_SYSTRACE or install from packages.
Update cad/openscad to 2011.06
Fixes a few minor Makefile issues I noticed while looking at this again: - Doesn't need cmake to build. - Pass VERSION=${V} to qmake so that the embedded version strings will be consistent rather than varying by build date. - No need to run ${SUBST_CMD} on openscad.pro; there are no substitutions to be made. - Eliminate trailing white space. ok? Index: Makefile === RCS file: /home/mdempsky/anoncvs/cvs/ports/cad/openscad/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile29 Apr 2011 18:55:37 - 1.1.1.1 +++ Makefile16 Aug 2011 16:21:49 - @@ -2,7 +2,7 @@ COMMENT = the programmer's solid 3D CAD modeller -V =2011.04 +V =2011.06 DISTNAME = openscad-${V} CATEGORIES = cad @@ -26,7 +26,6 @@ DISTFILES = openscad-${V}.src.tar.gz MODULES = x11/qt4 BUILD_DEPENDS =devel/bison \ - devel/cmake \ devel/flex \ math/eigen2 LIB_DEPENDS = devel/boost \ @@ -35,16 +34,17 @@ LIB_DEPENDS = devel/boost \ graphics/glew \ graphics/opencsg \ math/cgal - -CONFIGURE_ENV =EIGEN2DIR=${LOCALBASE}/include/eigen2 + +QMAKE_ENV =EIGEN2DIR=${LOCALBASE}/include/eigen2 +QMAKE_FLAGS = VERSION=${V} MAKE_ENV = INSTALL_ROOT=${DESTDIR} pre-configure: - ${SUBST_CMD} ${WRKSRC}/openscad.pro ln -sf ${LOCALBASE}/bin/gflex ${WRKDIR}/bin/flex ln -sf ${LOCALBASE}/bin/bison ${WRKDIR}/bin/yacc do-configure: - cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} qmake4 openscad.pro + cd ${WRKSRC} && \ + ${SETENV} ${QMAKE_ENV} qmake4 ${QMAKE_FLAGS} openscad.pro .include Index: distinfo === RCS file: /home/mdempsky/anoncvs/cvs/ports/cad/openscad/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo29 Apr 2011 18:55:37 - 1.1.1.1 +++ distinfo16 Aug 2011 16:21:59 - @@ -1,5 +1,5 @@ -MD5 (openscad-2011.04.src.tar.gz) = 8fNqSmkCinD5F71nz45hyA== -RMD160 (openscad-2011.04.src.tar.gz) = JGStMhXnSpVuek59AEghww481NI= -SHA1 (openscad-2011.04.src.tar.gz) = AicvVzoRmbBLlizm93pWNio9hP0= -SHA256 (openscad-2011.04.src.tar.gz) = BmOK6MeK62wVsVQDs09yIpiUcz6vV9SpiLZQPfU1wDY= -SIZE (openscad-2011.04.src.tar.gz) = 918915 +MD5 (openscad-2011.06.src.tar.gz) = uEAkPPGi910BEPlskmZZXA== +RMD160 (openscad-2011.06.src.tar.gz) = 1dS1JT81GS/GrQNmQfy/F/22zS0= +SHA1 (openscad-2011.06.src.tar.gz) = MPHXJmHvVTWdlbaxb9oAW7gXfks= +SHA256 (openscad-2011.06.src.tar.gz) = aTwMoDNjnFLD0tEfTVN5Y9w6O8DS46LmPaRg9omMMNs= +SIZE (openscad-2011.06.src.tar.gz) = 920506
Eliminate mention of xz/sparc issues in bsd.port.mk.5
bsd.port.mk no longer warns about xz/sparc issues, so it seems like bsd.port.mk.5 shouldn't need to either. ok? Index: bsd.port.mk.5 === RCS file: /home/mdempsky/anoncvs/cvs/src/share/man/man5/bsd.port.mk.5,v retrieving revision 1.284 diff -u -p -r1.284 bsd.port.mk.5 --- bsd.port.mk.5 15 Jul 2011 23:11:59 - 1.284 +++ bsd.port.mk.5 29 Aug 2011 16:21:56 - @@ -1130,7 +1130,7 @@ do done .Ed The use of xz archives is discouraged, as it makes things impossible to -build on vax and very annoying on sparc. +build on vax. .It Ev EXTRACT_ONLY Set if not all ${DISTFILES} should be extracted at do-extract stage. Default value is ${DISTFILES}.
Re: systrace: intercept_get_string: string too long
On Tue, Oct 18, 2011 at 12:33 AM, Stuart Henderson wrote: > nothing to do with systrace, you need to uninstall samba > and/or .libs-samba before building. Not entirely true. systrace only supports extracting strings up to 8192 bytes long, and that includes inspecting arguments to execve(2). When gmake sees a command with some shell syntax (some of Samba's Makefiles have comments at the end of their linking commands), it execve(2)s "sh", "-c", "cmd arg1 arg2 ..." instead of execve(2)ing "cmd", "arg1", "arg2", ... directly. When linking hundreds of objects into a single library, the "cmd arg1 arg2 ..." string can exceed 8192 bytes.
Re: Allow clang++ to work on OpenBSD
On Wed, Nov 23, 2011 at 9:04 AM, Mark Kettenis wrote: > Hard to tell if you don't explain what the problem is, The problem is clang++ is stricter about C and C++ rules than GCC is. E.g., it doesn't like conflicting prototypes, whereas GCC will happily ignore them in certain cases. See http://marc.info/?l=openbsd-ports&m=129783295016631&w=2 for more background.
UPDATE: math/cgal
Diff below updates CGAL from 3.8 to 3.9. A few remarks: * cgal-3.8 has to be uninstalled before cgal-3.9 can be built. The package tries to include older installed headers from /usr/local/include before the newer packaged headers, so many prototypes are missing or wrong. (I spent a little while investigating if this could be resolved somehow, but I'm pretty clueless with CMake and failed to figure it out.) * I renamed /usr/local/share/doc/CGAL-3.9 to /usr/local/share/doc/CGAL. * I bumped all the shared library versions; not sure if major bumps are really necessary, but it didn't seem worth looking into more closely. * Switched to .tar.xz since CGAL doesn't build on VAX anyway (due to IEEE floating point hardware dependencies for fenv.h). Quickly tested that OpenSCAD still compiles and runs on amd64. Index: Makefile === RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/Makefile,v retrieving revision 1.4 diff -u -p -r1.4 Makefile --- Makefile16 Sep 2011 10:31:22 - 1.4 +++ Makefile29 Nov 2011 22:09:18 - @@ -5,15 +5,14 @@ NOT_FOR_ARCHS = vax COMMENT = Computational Geometry Algorithms Library -DISTNAME = CGAL-3.8 +DISTNAME = CGAL-3.9 PKGNAME = ${DISTNAME:L} -REVISION = 1 SHARED_ONLY = Yes -SHARED_LIBS = CGAL0.0 \ - CGAL_Core 0.0 \ - CGAL_ImageIO0.0 \ - CGAL_Qt40.0 +SHARED_LIBS = CGAL1.0 \ + CGAL_Core 1.0 \ + CGAL_ImageIO1.0 \ + CGAL_Qt41.0 CATEGORIES = math @@ -29,8 +28,10 @@ PERMIT_DISTFILES_FTP = Yes WANTLIB = GL GLU ICE SM X11 Xext boost_thread-mt gmp gmpxx \ lib/qt4/QtGui lib/qt4/QtOpenGL m>=5.3 mpfr stdc++ z +EXTRACT_SUFX = .tar.xz + # Awkward hosting site; see https://gforge.inria.fr/frs/?group_id=52 for files index. -MASTER_SITES = https://gforge.inria.fr/frs/download.php/28500/ +MASTER_SITES = https://gforge.inria.fr/frs/download.php/29122/ MODULES = devel/cmake \ x11/qt4 @@ -45,5 +46,8 @@ CONFIGURE_ENV = CFLAGS="${CFLAGS post-patch: rm ${WRKSRC}/scripts/cgal_make_macosx_app + +post-install: + cd ${PREFIX}/share/doc && mv CGAL-3.9 CGAL .include Index: distinfo === RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo29 Apr 2011 17:47:50 - 1.1.1.1 +++ distinfo29 Nov 2011 21:33:52 - @@ -1,5 +1,5 @@ -MD5 (CGAL-3.8.tar.gz) = uKeeYuTYuotknYFa670cCg== -RMD160 (CGAL-3.8.tar.gz) = Xl4TI65FPZKOhbT2p2R/nW0pc9A= -SHA1 (CGAL-3.8.tar.gz) = I3SN8eYNYtoWbS45VzKuL+J0MX0= -SHA256 (CGAL-3.8.tar.gz) = se3VGIYTTPCG0XmCxQ9xAleBFWHSiLQ5rzprxjI4ntQ= -SIZE (CGAL-3.8.tar.gz) = 14112547 +MD5 (CGAL-3.9.tar.xz) = VCSQ4j0R211BmkNnkBaQCA== +RMD160 (CGAL-3.9.tar.xz) = A0CDe7V4JNvwg2HiW/u5G9AaFmg= +SHA1 (CGAL-3.9.tar.xz) = SL/4erJuATtYPuNPAhpgJcS4HN8= +SHA256 (CGAL-3.9.tar.xz) = pdUPN4ixrNNKIO+EwHH462burMXhJ2ApLW98D/BBAiw= +SIZE (CGAL-3.9.tar.xz) = 9853500 Index: pkg/PLIST === RCS file: /home/mdempsky/anoncvs/cvs/ports/math/cgal/pkg/PLIST,v retrieving revision 1.2 diff -u -p -r1.2 PLIST --- pkg/PLIST 25 Jun 2011 19:12:36 - 1.2 +++ pkg/PLIST 29 Nov 2011 21:59:53 - @@ -162,6 +162,7 @@ include/CGAL/Arr_default_dcel.h include/CGAL/Arr_default_overlay_traits.h include/CGAL/Arr_enums.h include/CGAL/Arr_extended_dcel.h +include/CGAL/Arr_extended_rational_arc_traits_d_1.h include/CGAL/Arr_face_index_map.h include/CGAL/Arr_face_map.h include/CGAL/Arr_geodesic_arc_on_sphere_partition_traits_2.h @@ -181,7 +182,6 @@ include/CGAL/Arr_geometry_traits/Conic_x include/CGAL/Arr_geometry_traits/Consolidated_curve_data_aux.h include/CGAL/Arr_geometry_traits/Curve_data_aux.h include/CGAL/Arr_geometry_traits/Hyperbolic_arc_2.h -include/CGAL/Arr_geometry_traits/One_root_number.h include/CGAL/Arr_geometry_traits/Polyline_2.h include/CGAL/Arr_geometry_traits/Rational_arc_2.h include/CGAL/Arr_geometry_traits/Segment_assertions.h @@ -223,7 +223,19 @@ include/CGAL/Arr_point_location/Trapezoi include/CGAL/Arr_point_location/Trapezoidal_decomposition_2_iostream.h include/CGAL/Arr_point_location/Trapezoidal_decomposition_2_misc.h include/CGAL/Arr_polyline_traits_2.h +include/CGAL/Arr_rat_arc/ +include/CGAL/Arr_rat_arc/Algebraic_point_2.h +include/CGAL/Arr_rat_arc/Base_rational_arc_ds_1.h +include/CGAL/Arr_rat_arc/Cache.h +include/CGAL/Arr_rat_arc/Rational_arc_d_1.h +include/CGAL/Arr_rat_arc/Rational_function.h +include
Re: memory compile sizes
On Thu, Apr 19, 2012 at 7:26 AM, Marc Espie wrote: > On Thu, Apr 19, 2012 at 02:57:57PM +0100, Stuart Henderson wrote: >> On 2012/04/19 15:42, Marc Espie wrote: >> > Yeah, the only issue so far is that the make-wrapper process is C code, so >> > it needs to be compiled and deployed on every host >> >> we ship with a wrapper in base ;) >> >> /usr/bin/time -l > > Up to a point. This means parsing the log files to find that entry. Nah, just direct time's output to a different file: $ cat logtime #!/bin/sh fn="$1"; shift exec /usr/bin/time -l sh -c 'exec "$@" 2>&9 9>&-' -- "$@" 9>&2 2>"$fn" $ ./logtime time.out sh -c 'echo stdout; echo stderr >&2' stdout stderr $ cat time.out 0.00 real 0.00 user 0.00 sys 504 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 146 minor page faults 0 major page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 0 involuntary context switches :) > It's feasible, > but not really nice... and /usr/bin/time will fail on some signals. Hm, how so?
Re: memory compile sizes
On Tue, Apr 24, 2012 at 2:42 PM, Marc Espie wrote: > Well, yuck, this makes for ways too many extra processes just for that. There are no more processes than your wrapper program, and only two more execs of /bin/sh. Considering make's primary task is forking and exec'ing /bin/sh processes, I doubt you'd notice the overhead. :P Anyway, it was a tongue-in-cheek proposal.
Re: [WIP] devel/eclipse4/sdk
Embarassingly, it turns out at some point I created a /usr/include/X11 -> /usr/X11R6/include/X11 symlink on my dev system and this masked an issue in the original Eclipse 4 tarball I sent out. Attached tarball has been corrected for this. (You still need the "eclipse-natives" distfile from the original mail.) On Fri, May 04, 2012 at 02:57:22PM -0700, Matthew Dempsky wrote: > Attached is a port for Eclipse SDK 4.1.2. I've only tested it on > amd64, but it should (might?) work on i386 too. For the time being, > there's no upstream for the "eclipse-natives" distfile, so just add > the attached copy directly to your distfiles directory. > > Once installed, Eclipse should "Just Work". The eclipse executable is > located at /usr/local/eclipse4/eclipse, and you'll need to make sure > /usr/local/jdk-1.7.0/bin is on your PATH and possibly bump your memory > limits too. > > Please let me know if you find anything that doesn't work correctly. > > > Background: > > After spending weeks of frustration trying all of the different build > options available for Eclipse SDK, I finally made a break through with > a hacky solution that actually works reasonably well IMO: simply take > the official Eclipse Linux binary distribution tarball and then swap > out the handful of Linux native code files with appropriately compiled > OpenBSD replacements. > > Because there doesn't seem to be any convenient place to fetch the > native libraries source code from, I decided to write a simple > "make-natives-snapshot.sh" that downloads the minimal code needed from > the Eclipse's git repositories and then creates a timestamped tarball. > > There are ways the package could likely be improved (e.g., install the > native libraries in /usr/local/lib/eclipse4 or something rather than > stuffing them back into Eclipse's bundled jar files, or splitting out > the xulrunner and webkit dependencies into separate subpackages so you > don't need both), but I'm erring on the side of simplicity for now. eclipse4-sdk.tar.gz Description: application/tar-gz
Re: Privoxy stable release is 3.0.8
On Wed, Apr 2, 2008 at 2:48 PM, Mike Erdely <[EMAIL PROTECTED]> wrote: > -@@ -344,7 +344,7 @@ char *strdup( const char *s ) > - > -if (result != NULL) > -{ > -- strcpy( result, s ); > -+ strlcpy( result, s, sizeof(result) ); > -} > - > -return( result ); It seems worth pointing out that this patch is an example of carelessly replacing strcpy with strlcpy. result here is a pointer, not a fixed size array, so sizeof(result) just returns 4 or 8 instead of the buffer size. (Of course, OpenBSD provides strdup in libc, so this code isn't used, patched or not.)
Re: Privoxy stable release is 3.0.8
On Wed, Apr 2, 2008 at 4:10 PM, Mike Erdely <[EMAIL PROTECTED]> wrote: > For what it's worth, that section of code was wrapped in: > #ifdef __MINGW32__ > char *strdup... > #endif /* def __MINGW32__ */ Right, that's why I said: > > (Of course, OpenBSD provides strdup in libc, so > > this code isn't used, patched or not.) I noticed the "result != NULL" check in the context before the strlcpy change while quickly reviewing the diff, and thought it was suspicious. After investigating further to confirm that it's a bug (were someone to try to use it on mingw32 after porting strlcpy...), I thought I'd just point it out as an example of how carelessly replacing strcpy with strlcpy can break ports.
Re: Update: Erlang/OTP R12B-2
This builds, installs, and runs fine on amd64 for me. On Wed, Apr 9, 2008 at 12:54 PM, Jon Olsson <[EMAIL PROTECTED]> wrote: > Attached is a patch which updates Erlang to the latest release R12B-2, for > more > info: http://www.erlang.org/download/otp_src_R12B-2.readme > > Makefile | 120 > +++ > distinfo | 30 +++ > patches/patch-lib_stdlib_src_dets_v9_erl | 13 --- > pkg/PLIST| 57 +++--- > 4 files changed, 122 insertions(+), 98 deletions(-) > > -- > Jon >
Re: Trascend Solid State Disk 1Gbyte
On Sat, Apr 12, 2008 at 11:58 PM, Marco <[EMAIL PROTECTED]> wrote: > Do you have notice, howto work fine the device in Subject? http://www.openbsd.org/faq/faq14.html#flashmem
Emacs 22 port?
Is anyone working on an Emacs 22 port? I thought I'd check before making a redundant effort.
Re: Emacs 22 port?
On Mon, Apr 14, 2008 at 12:42 PM, Eric Faurot <[EMAIL PROTECTED]> wrote: > This is a work-in-progress port of emacs 22.2 based on a post > by Fulvio Ciriaco. Contributions are most welcome. Cool. patch below adds a gtk flavor for using the gtk toolkit instead of the default one. I'm not sure about the LIB_DEPENDS part though; I just put the major versions from the system I tested on and confirmed that it works and passed "make lib-depends-check". Also, I fixed the PLIST-{main,el} files to catch a few new .el.gz files that snuck into PLIST-main. (Sorry if the Makefile diff wraps; I'm not sure how to fit 80 columns with library-specs. :-() diff -rpu emacs22/Makefile /usr/ports/editors/emacs22/Makefile --- emacs22/MakefileFri Apr 11 14:11:35 2008 +++ /usr/ports/editors/emacs22/Makefile Mon Apr 14 14:21:48 2008 @@ -26,7 +26,7 @@ MULTI_PACKAGES= -main -el USE_GMAKE= Yes -FLAVORS= no_x11 +FLAVORS= no_x11 gtk FLAVOR?= GCCARCH= ${MACHINE_ARCH}-unknown-openbsd${OPSYS_VER} @@ -51,6 +51,24 @@ SUBST_VARS= GCCARCH VERSION WANTLIB-main= c m ncurses ossaudio .if ${FLAVOR:L:Mno_x11} CONFIGURE_ARGS+= --with-x=no +.elif ${FLAVOR:L:Mgtk} +USE_X11=Yes +CONFIGURE_ARGS+= --with-x-toolkit=gtk +LIB_DEPENDS-main= gtk-x11-2.0.>=1200,gdk_pixbuf-2.0.>=1200,gdk-x11-2.0.>=1200::x11/gtk+2 \ + atk-1.0.>=2009::devel/atk \ + cairo.>=7::graphics/cairo \ + glib-2.0.>=1400,gmodule-2.0.>=1400,gobject-2.0.>=1400::devel/glib2 \ + glitz.>=2::graphics/glitz \ + iconv.>=4::converters/libiconv \ + intl.>=4::devel/gettext \ + jpeg.>=62::graphics/jpeg \ + pango-1.0.>=1400,pangocairo-1.0.>=1400,pangoft2-1.0.>=1400::devel/pango \ + png.>=6::graphics/png \ + tiff.>=38::graphics/tiff \ + ungif.>=5::graphics/libungif +WANTLIB-main+= ICE SM X11 Xau Xcomposite Xcursor Xdamage Xdmcp Xext +WANTLIB-main+= Xfixes Xft Xi Xinerama Xpm Xrandr Xrender expat fontconfig +WANTLIB-main+= freetype pthread z .else USE_X11=Yes LIB_DEPENDS-main= ungif.>=5::graphics/libungif \ diff -rpu emacs22/pkg/PLIST-el /usr/ports/editors/emacs22/pkg/PLIST-el --- emacs22/pkg/PLIST-elFri Apr 11 14:36:21 2008 +++ /usr/ports/editors/emacs22/pkg/PLIST-el Mon Apr 14 15:31:50 2008 @@ -690,6 +690,7 @@ share/emacs/${VERSION}/lisp/net/rcirc.el.gz share/emacs/${VERSION}/lisp/net/rcompile.el.gz share/emacs/${VERSION}/lisp/net/rlogin.el.gz share/emacs/${VERSION}/lisp/net/snmp-mode.el.gz +share/emacs/${VERSION}/lisp/net/socks.el.gz share/emacs/${VERSION}/lisp/net/telnet.el.gz share/emacs/${VERSION}/lisp/net/tls.el.gz share/emacs/${VERSION}/lisp/net/tramp-ftp.el.gz @@ -851,6 +852,8 @@ share/emacs/${VERSION}/lisp/progmodes/sh-script.el.gz share/emacs/${VERSION}/lisp/progmodes/simula.el.gz share/emacs/${VERSION}/lisp/progmodes/sql.el.gz share/emacs/${VERSION}/lisp/progmodes/tcl.el.gz +share/emacs/${VERSION}/lisp/progmodes/vera-mode.el.gz +share/emacs/${VERSION}/lisp/progmodes/verilog-mode.el.gz share/emacs/${VERSION}/lisp/progmodes/vhdl-mode.el.gz share/emacs/${VERSION}/lisp/progmodes/which-func.el.gz share/emacs/${VERSION}/lisp/progmodes/xscheme.el.gz @@ -910,8 +913,10 @@ share/emacs/${VERSION}/lisp/term/xterm.el.gz share/emacs/${VERSION}/lisp/terminal.el.gz share/emacs/${VERSION}/lisp/textmodes/artist.el.gz share/emacs/${VERSION}/lisp/textmodes/bib-mode.el.gz +share/emacs/${VERSION}/lisp/textmodes/bibtex-style.el.gz share/emacs/${VERSION}/lisp/textmodes/bibtex.el.gz share/emacs/${VERSION}/lisp/textmodes/conf-mode.el.gz +share/emacs/${VERSION}/lisp/textmodes/css-mode.el.gz share/emacs/${VERSION}/lisp/textmodes/dns-mode.el.gz share/emacs/${VERSION}/lisp/textmodes/enriched.el.gz share/emacs/${VERSION}/lisp/textmodes/fill.el.gz @@ -994,9 +999,13 @@ share/emacs/${VERSION}/lisp/url/url.el.gz share/emacs/${VERSION}/lisp/url/vc-dav.el.gz share/emacs/${VERSION}/lisp/userlock.el.gz share/emacs/${VERSION}/lisp/vc-arch.el.gz +share/emacs/${VERSION}/lisp/vc-bzr.el.gz share/emacs/${VERSION}/lisp/vc-cvs.el.gz +share/emacs/${VERSION}/lisp/vc-git.el.gz +share/emacs/${VERSION}/lisp/vc-hg.el.gz share/emacs/${VERSION}/lisp/vc-hooks.el.gz share/emacs/${VERSION}/lisp/vc-mcvs.el.gz +share/emacs/${VERSION}/lisp/vc-mtn.el.gz share/emacs/${VERSION}/lisp/vc-rcs.el.gz share/emacs/${VERSION}/lisp/vc-sccs.el.gz share/emacs/${VERSION}/lisp/vc-svn.el.gz diff -rpu emacs22/pkg/PLIST-main /usr/ports/editors/emacs22/pkg/PLIST-main --- emacs22/pkg/PLIST-main Mon Apr 14 11:50:27 2008 +++ /usr/ports/editors/emacs22/pkg/PLIST-main Mon Apr 14 15:31:52 2008 @@ -1298,7 +1298,6 @@ share/emacs/${VERSION}/lisp/net/rcirc.elc share/emacs/${VERSION}/lisp/net/rcompile.elc share/emacs/${VERSION}/lisp/net/rl
Re: Emacs 22 port?
On Mon, Apr 14, 2008 at 3:38 PM, Matthew Dempsky <[EMAIL PROTECTED]> wrote: > patch below adds a gtk flavor for using the gtk toolkit instead of the > default one. I'm not sure about the LIB_DEPENDS part though; I just > put the major versions from the system I tested on and confirmed that > it works and passed "make lib-depends-check". Oh, additionally moving the "CONFIGURE_ARGS+= --without-toolkit-scroll-bars" line into only the default flavor's section lets the gtk flavor use the gtk scroll bars (duh). (No diff; I figure the change is easy enough to reproduce.)
Re: New port: databases/tinycdb
On Sun, Apr 20, 2008 at 6:52 PM, <[EMAIL PROTECTED]> wrote: > I didn't see anything conclusive in that thread... just an allusion > toward a tinydns licensing problem, specifically the file format. djbdns (including tinydns) has been placed into the public domain; see http://cr.yp.to/distributors.html. > I also note that databases/py-cdb, which is already in the ports tree, > is a slightly modified version of DJB's original cdb-0.75 code plus > python glue, and relicensed as GPL. py-cdb includes cdb.c, cdb.h, cdb_make.c, cdb_make.h, and cdb_hash.c from cdb-0.75, which are all placed into the publicdomain. py-cdb does not include any copyrighted code from cdb-0.75.
Re: Modifying software written to a "Standards" document - was Re: DRM in xpdf
On Sat, Apr 26, 2008 at 6:29 PM, Zvezdan Petkovic <[EMAIL PROTECTED]> wrote: > Replacing a protection with a message of intent of the author is probably a > good idea. Maybe for the xpdf maintainer (e.g., a --soft-drm configure option), but that definitely seems way too intrusive a patch for maintainence within the ports tree. In lieu of that, a simpler solution would seem to be to title your links to the slides as "Printer-friendly sides (no animation)" and "Screen-friendly slides (animation)". Hopefully university students can read, and if not, they should learn quickly after paying for a 200 page printout. :-)
Re: Modifying software written to a "Standards" document - was Re: DRM in xpdf
On Sun, Apr 27, 2008 at 12:53 AM, Predrag Punosevac <[EMAIL PROTECTED]> wrote: > I hate to disagree with somebody who sounds like my fellow countryman but > DRM has NO use. I also teach at the University and I some time prepare > slides too which use over layers and even more fancy stuff. Any decant > software for preparing slides (in my case I use Powerdot Latex class of > presentation) has so called note mode. In note mode you can choose to put up > to 4 slides on the single sheet of the paper for purposes of printing hand > outs for your students. You may also include additional rule lines for > taking the notes. Note mode will ignore over layers (which are in essence > separate slides) or any other additional stuff. Zvezdan did say "I also always posted a 4 up version of the slides with *no* protection -- 4 slides per page with animations turned into a final picture after the last step." His use case for PDF's DRM was simply to protect students from accidentally printing the animated slides instead of the still 4-up slides.
Re: Ports with possible 64-bit problems
On Mon, Jun 30, 2008 at 8:31 AM, Christian Weisgerber <[EMAIL PROTECTED]> wrote: > A grep over a recent set of amd64 bulk build logs shows these ports > generating warnings that indicate possible 64-bit problems: I'm looking at the Erlang port's build logs, and I see some "warning: cast from pointer to integer of different size" messages. Are there any other messages to look out for?
Re: chromium comes to town
On Fri, Sep 5, 2008 at 8:54 PM, Rajneesh N. Shetty <[EMAIL PROTECTED]> wrote: > I coud'nt install Google's Chrome browser on my machine Chrome only works on Windows. Source code builds some framework stuff on some other platforms, but nothing useful yet. Give it a few months.
Re: [NEW] emacs 23.2
On Tue, Jul 27, 2010 at 2:45 AM, Manuel Giraud wrote: > New version with correct WANTLIB and LIB_DEPENDS usage and a "wishful > thinking" remove of the propolice workaround for powerpc. Any update on this port? I just built it on amd64, and it seems okay so far.
Update surf to 0.4.1
The diff below updates surf to 0.4.1, notably fixing GMail support for me. ok? Index: Makefile === RCS file: /cvs/ports/www/surf/Makefile,v retrieving revision 1.4 diff -u -p -r1.4 Makefile --- Makefile7 Jun 2010 07:24:00 - 1.4 +++ Makefile17 Sep 2010 11:54:54 - @@ -2,7 +2,7 @@ COMMENT = simple webbrowser based on webkit/gtk+ -DISTNAME = surf-0.4 +DISTNAME = surf-0.4.1 CATEGORIES = www HOMEPAGE = http://surf.suckless.org/ Index: distinfo === RCS file: /cvs/ports/www/surf/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo7 Jun 2010 07:24:00 - 1.2 +++ distinfo17 Sep 2010 11:54:54 - @@ -1,5 +1,5 @@ -MD5 (surf-0.4.tar.gz) = Gn8b8hny2guXwggCvPSYxw== -RMD160 (surf-0.4.tar.gz) = qG2unidvZ1gEzKqm6dOEc5Ygts8= -SHA1 (surf-0.4.tar.gz) = nLy88g9v05ZBjP91dED1lwoCVMo= -SHA256 (surf-0.4.tar.gz) = 9F+L6YpHiUpdk2Vu5KICZqH5ybqd+9O+0l339qxHmcU= -SIZE (surf-0.4.tar.gz) = 10089 +MD5 (surf-0.4.1.tar.gz) = KKx6bRk9JYRKprHbd/y6+g== +RMD160 (surf-0.4.1.tar.gz) = kV4y8aW4OCgMV8pEFl0kZUvBFpA= +SHA1 (surf-0.4.1.tar.gz) = L2qhnEirZh3K/Tj/c9RQydxGpZk= +SHA256 (surf-0.4.1.tar.gz) = k3Cbo+hLryEYZ26WpbLl1BdvKMNceC//2AplwKW+pUY= +SIZE (surf-0.4.1.tar.gz) = 10102
Re: allow sshguard to build on gcc 3.x
On Mon, Sep 20, 2010 at 12:01 PM, Todd C. Miller wrote: > Apparently gcc 3.x doesn't like: > > const char *restrict addresses[] > > But is OK with: > > const char **restrict addresses I'm pretty sure you want "const char * restrict * addresses" instead.
Re: potential qemu crash fix, please test
On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote: > +--- net/socket.c.origMon Jan 24 15:34:58 2011 > net/socket.c Mon Jan 24 15:35:01 2011 > +@@ -195,7 +195,7 @@ static int net_socket_mcast_create(struct sockaddr_in > + /* Force mcast msgs to loopback (eg. several QEMUs in same host */ > + val = 1; > + ret=setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP, > +- (const char *)&val, sizeof(val)); > ++ (const char *)&val, sizeof(char)); > + if (ret < 0) { > + perror("setsockopt(SOL_IP, IP_MULTICAST_LOOP)"); > + goto fail; Won't this break on sparc64, since it's a big-endian architecture?
Re: mplayer
Would it be difficult to make it instead just print a warning about userldt instead of erroring out?
Re: tint patch cleanups and wantlib fix
On Sun, May 9, 2010 at 9:28 AM, Edd Barrett wrote: > +#if defined(__OpenBSD__) > -+ if (close(apm_fd) == -1) > ++ if ((apm_fd != NULL) && (close(apm_fd) == -1)) > + warn("cannot close /dev/apm"); > +#endif It seems wrong to use NULL (a pointer value) as a file descriptor value. Can I suggest changing apm_fd's initialization from NULL to -1, and similarly comparing against -1 instead of NULL here?