Re: sigwait - differences between Linux & FreeBSD
On Thu, Oct 8, 2009 at 10:38 PM, Matthias Andree wrote: > Stephen Hocking schrieb: >> Hi all, >> >> In my efforts to make the xrdp port more robust under FreeBSD, I have >> discovered that sigwait (kind of an analogue to select(2), but for >> signals rather than I/O) re-enables ignored signals in its list under >> Linux, but not FreeBSD. > > If the application relies on sigwait() to wait for and extract an ignored > signal > (SIG_IGN), it is non-portable, as it expects non-POSIX semantics, and should > be > fixed by the upstream maintainer (I haven't checked that). > > Note: Linux has the same semantics, quoting its manual page (on Ubuntu 9.10 > beta): > > sigwait suspends the calling thread until one of the signals in set is > delivered to the calling thread. It then stores the number of the sig‐ >> nal received in the location pointed to by sig and returns. The signals >> in set must be blocked and not ignored on entrance to sigwait. If the > delivered signal has a signal handler function attached, that function > is not called. > >> The sesman daemon uses SIGCHLD to clean up after a session has exited. Under >> Linux this works OK, under FreeSBD it doesn't. > > Not sure I understand. How can it clean up if it's not made aware of child's > termination? Or do some Linux kernels behave in another way? It appears as if the documentation does not match up with the reality in Linux's case. That's what the empirical evidence suggests anyway. The code does does a waitpid after receiving the SIGCHLD to determine what child process has exited and then searches its list of sessions looking for that particular pid, so as to tidy up. I can to some degree understand that implementation of sigwait, as if you state your intention to wait for a particular signal, that means that you don't wish to ignore it. > > Setting SIGCHLD to SIG_IGN (default) means that the kernel will let go of the > child processes as they exit, rather than turn them into zombies. You cannot > wait() for them though. > >> I have worked around it in a very hackish manner (define a >> dummy signal handler and enable it using signal, which means that the >> sigwait call can then be unblocked by it), but am wondering if anyone >> else has run across the same problem, and if so, if they fixed it in >> an elegant manner. Also, does anyone know the correct semantics of >> sigwait under this situation? > > That is not a hackish workaround, but one of the few safe ways to sigwait() > for > SIGCHLD. A version fixed thus should still work on Linux, so that fix should > be > made by xrdp upstream. > > > The canonical reference would be the POSIX standard (IEEE Std 1003.1). > > 2008: http://www.opengroup.org/onlinepubs/9699919799/ > > 2001, 2004 edition: http://www.opengroup.org/onlinepubs/95399/ > > The latter is also known as the Single Unix Specification v3 (SUSv3). Thanks for the references. ___ 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"
sigwait - differences between Linux & FreeBSD
Hi all, In my efforts to make the xrdp port more robust under FreeBSD, I have discovered that sigwait (kind of an analogue to select(2), but for signals rather than I/O) re-enables ignored signals in its list under Linux, but not FreeBSD. The sesman daemon uses SIGCHLD to clean up after a session has exited. Under Linux this works OK, under FreeSBD it doesn't. I have worked around it in a very hackish manner (define a dummy signal handler and enable it using signal, which means that the sigwait call can then be unblocked by it), but am wondering if anyone else has run across the same problem, and if so, if they fixed it in an elegant manner. Also, does anyone know the correct semantics of sigwait under this situation? Stephen ___ 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"
Building QT4 - traps for old players.
Hi all, After some months of not being able to build qt4, with errors that made little sense, I finally tracked the cause down - I had set the environment variables QTDIR, QTLIB & QTBIN to point to directories in /usr/X11R6. Once this was removed, I was able to remake everything without errors. Stephen ___ 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"
QT4 build errors under RELENG_7
Hi all, Have had a long-standing problem building QT4 under 7.2. Basically it errors out with some undefined constants (which one can find in qplatformdefs.h), but this file is apparently being included in the file in question. Most puzzling. Here's the build failure: c++ -c -O2 -fno-strict-aliasing -pipe -fno-exceptions -O2 -fno-strict-aliasing -pipe -Wall -W -DQT_BOOTSTRAPPED -DQT_MOC -DQT_NO_CODECS -DQT_LITE_UNICODE -DQT_NO_LIBRARY -DQT_NO_STL -DQT_NO_COMPRESS -DQT_NO_DATASTREAM -DQT_NO_TEXTSTREAM -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_THREAD -DQT_NO_REGEXP -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO_GEOM_VARIANT -DQT_NO_USING_NAMESPACE -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt/mkspecs/freebsd-g++ -I. -I../../corelib/arch/generic -I../../../include -I. -I../../../include/QtCore -I. -I.uic/release-shared -I/usr/local/include -o release-shared/qfsfileengine.o ../../corelib/io/qfsfileengine.cpp ../../corelib/io/qfsfileengine.cpp: In member function 'bool QFSFileEnginePrivate::openFh(QFlags, FILE*)': ../../corelib/io/qfsfileengine.cpp:305: error: 'QT_FSEEK' was not declared in this scope ../../corelib/io/qfsfileengine.cpp: In member function 'qint64 QFSFileEnginePrivate::posFdFh() const': ../../corelib/io/qfsfileengine.cpp:518: error: 'QT_FTELL' was not declared in this scope ../../corelib/io/qfsfileengine.cpp: In member function 'bool QFSFileEnginePrivate::seekFdFh(qint64)': ../../corelib/io/qfsfileengine.cpp:548: error: 'QT_OFF_T' was not declared in this scope ../../corelib/io/qfsfileengine.cpp:548: error: 'QT_FSEEK' was not declared in this scope ../../corelib/io/qfsfileengine.cpp: In member function 'qint64 QFSFileEnginePrivate::readFdFh(char*, qint64)': ../../corelib/io/qfsfileengine.cpp:623: error: 'QT_FTELL' was not declared in this scope ../../corelib/io/qfsfileengine.cpp:623: error: 'QT_FSEEK' was not declared in this scope ../../corelib/io/qfsfileengine.cpp: In member function 'qint64 QFSFileEnginePrivate::readLineFdFh(char*, qint64)': ../../corelib/io/qfsfileengine.cpp:694: error: 'QT_OFF_T' was not declared in this scope ../../corelib/io/qfsfileengine.cpp:694: error: expected `;' before 'oldPos' ../../corelib/io/qfsfileengine.cpp:699: error: 'oldPos' was not declared in this scope ../../corelib/io/qfsfileengine.cpp:699: error: 'QT_FTELL' was not declared in this scope *** Error code 1 Stop in /src/FreeBSD/ports/devel/qt4-moc/work/qt-x11-opensource-src-4.4.3/src/tools/moc. *** Error code 1 Stop in /src/FreeBSD/ports/devel/qt4-moc/work/qt-x11-opensource-src-4.4.3/src/tools/moc. *** Error code 1 Stop in /src/FreeBSD/ports/devel/qt4-moc. *** Error code 1 Stop in /src/FreeBSD/ports/accessibility/qt4-accessible. *** Error code 1 Stop in /src/FreeBSD/ports/devel/qt4. ___ 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"
Xorg update breaks nvidia driver?
Hi, After the recent update to Xorg, the nvidia binary driver now complains about an ABI mismatch, which can be worked around with the --ignoreABI commandline option. Is anyone willing to come upwith a patch (which probably involves hacking around with the Xorg doco to find out what's actually changed) or waiting for nvidia to ptach it. Sigh. Can't wait until the guys get on the recently released ATI specificatiions. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Keeping /dev/dsp in digital out mode?
Hi, All of my systems are connected to a home theatre amp via an analogue connection except for one, which used an optical connection. Unsuprisingly, the digital connection sounds better (less noise etc). Has anyone experimented with keeping the output in digital mode all the time? I guess that some things would have to be resampled (I'm thinking of some games that only use 22KHz output etc, and some cards will only output digital at 48KHz). Any ideas? Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Recreating /usr/ports/share/xml/catalog.ports
Hi all, Recently, owing to space problems, my catalog.ports got trashed, and now various ports (such as gdm & scrollkeeper) are complaining that they can't find the Docbook XML DTD in it when configuring. Reinstalling docbook doesn't seem to do any good. Does anyone have a sequence of steps to recreate this file? Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Error when attempting to build gcc 4.2 within math/blas on 6.2 stable
Hi all, I've been getting this error for quite some time when blas attempts to build itself a compiler Has anyone else seen and hopefully solved it? /src/FreeBSD/ports/lang/gcc42/work/build/gcc/gcj -B/src/FreeBSD/ports/lang/gcc42 /work/build/i386-portbld-freebsd6.2/libjava/ -B/src/FreeBSD/ports/lang/gcc42/wor k/build/gcc/ -ffloat-store -fomit-frame-pointer -g -O2 -o .libs/jv-convert --mai n=gnu.gcj.convert.Convert -shared-libgcc -pthread -L/src/FreeBSD/ports/lang/gcc 42/work/build/i386-portbld-freebsd6.2/libjava -L/src/FreeBSD/ports/lang/gcc42/wo rk/build/i386-portbld-freebsd6.2/libjava/.libs ./.libs/libgcj.so -L/src/FreeBSD/ ports/lang/gcc42/work/build/i386-portbld-freebsd6.2/libstdc++-v3/src -L/src/Free BSD/ports/lang/gcc42/work/build/i386-portbld-freebsd6.2/libstdc++-v3/src/.libs - lz -L/src/FreeBSD/ports/lang/gcc42/work/build/./gcc -lgcc_s -lgcc_s -Wl,--rpath -Wl,/usr/local/lib/gcc-4.2.0 /usr/bin/ld: .libs/jv-convert: hidden symbol `__eprintf' in /src/FreeBSD/ports/l ang/gcc42/work/build/./gcc/libgcc.a(_eprintf.o) is referenced by DSO collect2: ld returned 1 exit status gmake[3]: *** [jv-convert] Error 1 gmake[3]: Leaving directory `/src/FreeBSD/ports/lang/gcc42/work/build/i386-portb ld-freebsd6.2/libjava' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/src/FreeBSD/ports/lang/gcc42/work/build/i386-portb ld-freebsd6.2/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/src/FreeBSD/ports/lang/gcc42/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 2 Stop in /src/FreeBSD/ports/lang/gcc42. *** Error code 1 Stop in /src/FreeBSD/ports/math/blas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Errors building math/R under RELENG_6...
Hi Eric, I've been having an error for some time building R under 6.2 - it errors out as below. mkdir /src/FreeBSD/ports/math/R/work/R-2.3.1/bin/exec mkdir /src/FreeBSD/ports/math/R/work/R-2.3.1/lib cc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -fpic -O2 -fno-strict-aliasing -pipe -c Rmain.c -o Rmain.o cc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o -L../../lib -lR Rmain.o(.text+0x19): In function `main': : undefined reference to `R_running_as_main_program' *** Error code 1 Stop in /src/FreeBSD/ports/math/R/work/R-2.3.1/src/main. *** Error code 1 Stop in /src/FreeBSD/ports/math/R/work/R-2.3.1/src/main. *** Error code 1 Stop in /src/FreeBSD/ports/math/R/work/R-2.3.1/src. *** Error code 1 Stop in /src/FreeBSD/ports/math/R/work/R-2.3.1. *** Error code 1 Stop in /src/FreeBSD/ports/math/R. Any chance of having a fix comitted anytime soon (looks fairly straightforward to sort out). Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
