dansguardian fails to start when compiled against uclibc++. It complais about missing permissions on logfile /var/log/dansguardian/access.log, even if permissions are correct. strace reveals that dansguardian dont even *try* to open the logfile. When I disable the logfile test in dansguardian.cpp here below, it just works without any problems at all. Strange thing is that it seems like the real log files are opened in exactly the same way. around line 198: if (o.no_logger == 0) { ofstream logfiletest(o.log_location.c_str(), ios::app); if (logfiletest.fail()) { syslog(LOG_ERR, "%s","Error opening/creating log file. (check ownership and access rights)."); std::cout << "Error opening/creating log file. (check ownership and access rights)." << std::endl; std::cout << "I am running as " << o.daemon_user_name << " and I am trying to open " << o.log_location << std::endl; return 1; // opening the log file for writing failed } logfiletest.close(); } hardened dansguardian-2.8.0.6 # emerge --info Portage 2.1 (uclibc/x86/hardened, gcc-3.4.6, uclibc-0.9.28-r0, 2.6.16-gentoo-r10 i686) ================================================================= System uname: 2.6.16-gentoo-r10 i686 Intel(R) Pentium(R) D CPU 3.00GHz Gentoo Base System version 1.6.14 distcc 2.18.3 i386-gentoo-linux-uclibc (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-gentoo-linux-uclibc" CFLAGS="-march=i386 -Os -pipe -fomit-frame-pointer" CHOST="i386-gentoo-linux-uclibc" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-Os -pipe" DISTDIR="/var/cache/distfiles" FEATURES="autoconfig buildpkg distlocks metadata-transfer nodoc noinfo noman sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/var/cache/packages/default" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/alpine-portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X509 bitmap-fonts bri bzip2 cli cracklib dri encode expat hardened iproute2 ipv6 jpeg mad minimal ncurses netboot ogg oss pci pcmcia pic png pppd readline reflection rrdtool sensord session snmp speex spl ssl tdb truetype truetype-fonts type1-fonts uclibc udev usb userlocales winbind xorg zlib elibc_uclibc kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
maybe one of the following directories don't have the right permissions: / /var /var/log /var/log/dansguardian Please check them by running "ls -ld $dir" for every directory in the above list.
They are all correct(In reply to comment #1) > maybe one of the following directories don't have the right permissions: > / > /var > /var/log > /var/log/dansguardian > > Please check them by running "ls -ld $dir" for every directory in the above > list. they are all corred (drwxr-xr-x) and the owner fo the dir is correct. I have tried to use 'nobody', 'dansguardian' and 'dansguar'. I have changed the ownership of directory and modified /etc/dansguardian/dansguardian.conf to pick correct user. However, dansguardian is not even trying open the logfile (i see that with strace) So it logfiletest().fail() is true for some reason. I suspect that there might be a problem with uclibc++ or a bug in the dansguardian string code.
Here is the output of strace: ~ $ strace dansguardian ... open("/etc/passwd", O_RDONLY) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x5d2f55bc) = -1 ENOTTY (Inappropriate ioctl for device) read(4, "root:$1$rxju5vTp$wiUAJEZmsG0pyLr"..., 4096) = 1869 close(4) = 0 setgid(500) = 0 setresuid(-1, 500, -1) = 0 rt_sigaction(SIGPIPE, {0x4fe5bb37, [], SA_RESTORER, 0x4fe5ff88}, {SIG_DFL}, 8) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 4 connect(4, {sa_family=AF_FILE, path="/dev/log"}, 10) = 0 time([1150974485]) = 1150974485 write(4, "<11>Jun 22 11:08:05 syslog: Erro"..., 98) = 98 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 write(1, "Error opening/creating log file."..., 70Error opening/creating log file. (check ownership and access rights). ) = 70 write(1, "I am running as dansguar and I a"..., 82I am running as dansguar and I am trying to open /var/log/dansguardian/access.log ) = 82 munmap(0x4e8db000, 22376448) = 0 _exit(1) = ? As you can see, it switches user to uid 500 sucessfully (I have a user named 'dansguardian' instead of 'nobody') Next thing that happens is a rt_sigaction (what that is I dont know, but I'd guess its related to c++) and then it opens a socket to log device to log the error that it failed to create the access.log file. There are no open("/var/log/dansguardian/access.log" ...) so dansguardian is failing before trying to open it - so its clear that its not the premissions that are wrong.
Try this test program: --- 8< --- #include <iostream> #include <fstream> int main(int argc, char*argv[]) { std::ofstream testFile("test.txt", std::ios::app); if (testFile.fail()) { std::cout << "Oh no...." << std::endl; } else { testFile<<"hello"; testFile.close(); } } --- 8< ---- If you compile it with gcc's g++, it works. If its compiled with uclibc++, g++-uc, it will fail.
are you using the latest uclibc++ library (0.2.0)?
(In reply to comment #5) > are you using the latest uclibc++ library (0.2.0)? yes. sys-libs/uclibc++-0.2.0
This is uclibc++ problem. Reassigned to embedded team.
Please report this upstream with the testcase from comment #4 http://cxx.uclibc.org/contact.html
btw... I cannot compile on my gcc-4.1 x86_64 host: ncopa@nc ~/tmp $ g++-uc test.cpp /tmp/cc8Ql6F7.o: In function `main': test.cpp:(.text+0xc0): undefined reference to `_Unwind_Resume' /tmp/cc8Ql6F7.o: In function `std::ios_base::~ios_base()': test.cpp:(.text._ZNSt8ios_baseD2Ev[std::ios_base::~ios_base()]+0x4f): undefined reference to `_Unwind_Resume' /tmp/cc8Ql6F7.o: In function `std::ios_base::ios_base()': test.cpp:(.text._ZNSt8ios_baseC2Ev[std::ios_base::ios_base()]+0x79): undefined reference to `_Unwind_Resume' /tmp/cc8Ql6F7.o: In function `std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf()': test.cpp:(.text._ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev[std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf()]+0xd2): undefined reference to `_Unwind_Resume' /tmp/cc8Ql6F7.o: In function `std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf()': test.cpp:(.text._ZNSt13basic_filebufIcSt11char_traitsIcEED0Ev[std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf()]+0xac): undefined reference to `_Unwind_Resume' /tmp/cc8Ql6F7.o:test.cpp:(.text._ZNSt13basic_filebufIcSt11char_traitsIcEED1Ev[std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf()]+0xac): more undefined references to `_Unwind_Resume' follow collect2: ld returned 1 exit status
the example compiles correctly if you do it right it seems that you compiled uClibc++ w/ a gcc version != 4.1 and try to compile later stuff w/ g++-4.1, that wont work The only way you currently may use uClibc++ is to compile it w/ one version of gcc and use the same version to compile all apps against libuClibc++
(In reply to comment #10) [ this is getting offtopic... sorry ] > the example compiles correctly if you do it right > it seems that you compiled uClibc++ w/ a gcc version != 4.1 and try to compile > later stuff w/ g++-4.1, that wont work > The only way you currently may use uClibc++ is to compile it w/ one version of > gcc and use the same version to compile all apps against libuClibc++ Yes. I am aware of that. Let me try once again. ncopa@nc ~/tmp $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1) ncopa@nc ~/tmp $ sudo emerge uclibc++ Calculating dependencies ... done! >>> Emerging (1 of 1) sys-libs/uclibc++-0.2.0 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking uClibc++-0.2.0.tbz ;-) >>> Unpacking source... >>> Unpacking ./uClibc++-0.2.0.tbz2 to /var/tmp/portage/uclibc++-0.2.0/work * * uClibc++ Configuration * Target Architecture 1. alpha (TARGET_alpha) (NEW) 2. arm (TARGET_arm) (NEW) > 3. i386 (TARGET_i386) (NEW) Oh... here is the problem... Why is it compiled as i386 on my CHOST=x86_64-pc-linux-gnu? 4. mips (TARGET_mips) (NEW) 5. parisc (TARGET_parisc) (NEW) 6. powerpc (TARGET_powerpc) (NEW) 7. x86_64 (TARGET_x86_64) (NEW) choice[1-7?]: 3 It should have been 7. I take a look at the ebuild: ... export CTARGET=${CTARGET:-${CHOST}} ... CTARGET is set to x86_64-pc-linux-gnu. Later (from line 36): case $(tc-arch ${CTARGET}) in alpha) target="alpha";; amd64) target="x86_64";; arm) target="arm";; hppa) target="hppa";; mips) target="mips";; ppc) target="powerpc";; x86) target="i386";; *) die "$(tc-arch ${CTARGET}) lists no defaults :/";; esac So it means that tc-arch is telling the src_unpack that my x86_64-pc-linux-gnu is an x86? Sounds like a bug to me. I dig a litte bit deeper. tc-arch are in toolchain-funcs.eclass. I look there and there it looks correct. In tc-ninja_magic_to_arch() I see this (line 139): x86_64*) ninj x86_64 amd64;; Everything looks like it *should* work. Strange. This is offtopic here. Should I file a new bugreport? Should I try on the forums to get some help to find out whats going on here? Thanks for your help so far, Peter.
The gentoo ebuild is buggy, I do not use it On another note, only uClibc++-svn can be used (if at all) properly with gcc>4.0, I have provided some changes to the buildsystem applied upstream to support gcc-4.1 and newer, but havent gotten the time to really test it, because there are other problems related to the use of gcc4 combined with uClibc++. It can work though on a glibc host, but combined w/ uClibc even svn is faulty.
(In reply to comment #12) > The gentoo ebuild is buggy, I do not use it Why do you prefer that instead of simply fixing its bugs? Just derive your own ebuild and, when you are happy with the result, submit it here.
You are right, but you dont know that I provided the update already to the initial 0.1.8 release and that was not applied, so I am not interested in enforcing the use of my ebuilds. My ebuild cant be used as it is in gentoo env, because it creates a gcc profile to link against libuClibc++ instead of libstdc++. The support has to
Came upon commit ot early, sorry The proper support has to be done in toolchain.eclass, but I do not really know how, because it is a fundamental change.
Created attachment 95078 [details, diff] files/uclibc++-0.2.0-ios_app.patch I couldn't wait for the upstream 0.2.1 release so I checked out a patch from svn. I post it here so you have the possibility to create an uclibc++-0.2.0-r1 release while waiting if you want.
Created attachment 95079 [details] uclibc++-0.2.0-r1.ebuild ...and the ebuild. Just in case... ;-) It works for me.
