Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70529 - sparc and amd64 keywords on 1.0.10-r1 (was log4c ebuilds 1.0.11 and 1.0.12 fail self test - config file reading trouble)
Summary: sparc and amd64 keywords on 1.0.10-r1 (was log4c ebuilds 1.0.11 and 1.0.12 fa...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Daniel Black (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-08 19:11 UTC by Lee Thompson
Modified: 2005-01-04 17:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild for log4c v1.0.10 which works okay for amd_64 and i386 (log4c-4-gcc-3.3.4.patch,4.88 KB, patch)
2004-11-08 19:15 UTC, Lee Thompson
Details | Diff
should work for gcc 3.4 (log4c.patch,5.21 KB, patch)
2004-11-16 10:17 UTC, Lee Thompson
Details | Diff
1.0.10 ebuild with getenv("HOME") fix (log4c.patch,6.58 KB, patch)
2004-11-16 21:29 UTC, Lee Thompson
Details | Diff
compiler warning patch for 1.0.10 and keywords stability as I see it (log4c.patch,3.31 KB, patch)
2004-11-30 18:35 UTC, Lee Thompson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lee Thompson 2004-11-08 19:11:45 UTC
Couldn't get log4c working with latest gentoo with gcc 3.3.4.
Created a new ebuild for log4c 1.0.10 which is working for me on amd_64 and i386.

Reproducible: Always
Steps to Reproduce:
1.emerge log4c


Actual Results:  
log4c has compiler warnings and does not route application logs when run

Expected Results:  
logs should have routed
Comment 1 Lee Thompson 2004-11-08 19:15:31 UTC
Created attachment 43573 [details, diff]
ebuild for log4c v1.0.10 which works okay for amd_64 and i386

v1.0.11 and v1.0.12 don't work at all for me on gentoo.  works fine on redhat
AS 3.2.

Started to debug v1.0.12 and abandoned it because problem is in bison created
'C' code and the bison code is not distributed!!!!   How about them apples?
Comment 2 Daniel Black (RETIRED) gentoo-dev 2004-11-14 05:54:37 UTC
1.0.10 failed for me with:
depfile='.deps/test_rc.Po' tmpdepfile='.deps/test_rc.TPo' \
depmode=gcc3 /bin/sh ../../config/depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src -DSRCDIR="\".\""    -march=athlon-xp -O2 -pipe -Wall -c `test -f test_rc.c || echo './'`test_rc.c
test_category.c: In function `test4':
test_category.c:114: error: parse error before string constant
test_category.c:116: error: parse error before string constant
test_category.c:118: error: parse error before string constant
distcc[3489] ERROR: compile test_category.c on localhost failed
make[3]: *** [test_category.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/tests/log4c'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10'
make: *** [all] Error 2

!!! ERROR: dev-libs/log4c-1.0.10-r1 failed.
!!! Function src_compile, Line 37, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message

(no symbol trace defined see files/log4c_1.0.11_test.patch - could be a kernel headers problem)

emerge info
Portage 2.0.51-r2 (default-linux/x86/2004.2, gcc-3.4.1, glibc-2.3.4.20040808-r1, 2.6.8-gentoo-r10 i686)
=================================================================
System uname: 2.6.8-gentoo-r10 i686 AMD Athlon(tm) XP 1900+
Gentoo Base System version 1.4.16
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.14.90.0.8-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -O2 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache cvs distcc distlocks sandbox sfperms sign userpriv usersandbox"

can you define "don't work at all"? - I've got 1.0.11 and 1.0.12 compiled fine.
Comment 3 Lee Thompson 2004-11-14 18:01:15 UTC
I tried the 1.0.10 ebuild on an Athlon-XP box it worked for me.  I think the biggest difference in your set up and my boxes is I haven't setup distcc.  Can you try putting a "-j1" on the ebuild src_compile() routine?

      emake -j1 || die

The problem with 1.0.11 and 1.0.12 I'm seeing is it will not load the /etc/log4crc file to redirect the application output to different output log appenders.  I'd debug 1.0.12 but all the source code isn't distributed with log4c after the 1.0.10 release.
Comment 4 Lee Thompson 2004-11-16 09:32:19 UTC
I don't think it's distcc now.  Your gcc 3.4 compiler is picking up problems that gcc 3.3 doesn't (which I'm using).  Apparently this problem is fixed in 1.0.12.  I'll back port the 1.0.12 "trace" to "info" change and submit a new patchfile.



portage # diff log4c-1.0.10-r1/work/log4c-1.0.10/tests/log4c/test_category.c log4c-1.0.12/work/log4c-1.0.12/tests/log4c/test_category.c
1c1
< static const char version[] = "$Id: test_category.c,v 1.6 2002/11/20 15:38:34 legoater Exp $";
---
> static const char version[] = "$Id: test_category.c,v 1.5 2004/08/16 13:38:21 legoater Exp $";
6,7c6
<  * Copyright 2001-2002, Meiosys SA (www.meiosys.com). All rights reserved.
<  * Copyright 2001-2002, Cedric Le Goater <legoater@meiosys.com>. All rights reserved.
---
>  * Copyright 2001-2003, Meiosys (www.meiosys.com). All rights reserved.
42a42,53
> static int test00(sd_test_t* a_test, int argc, char* argv[])
> {
>     int p;
>     log4c_category_t* cat = log4c_category_get("a category");
>
>     for (p = 0; p < LOG4C_PRIORITY_UNKNOWN; p++)
>       log4c_category_log(cat, p * 100, "this is a %s event",
>                          log4c_priority_to_string(p * 100));
>     return 1;
> }
>
> /******************************************************************************/
114c125
<     foo(root, trace);
---
>     foo(root, info);
116c127
<     foo(sub1, trace);
---
>     foo(sub1, info);
118c129
<     foo(sun1sub2, trace);
---
>     foo(sun1sub2, info);
129a141
>     sd_test_add(t, test00);
Comment 5 Lee Thompson 2004-11-16 10:17:37 UTC
Created attachment 44081 [details, diff]
should work for gcc 3.4

This patch should work for gcc 3.4.

Looks pretty promising as it includes essentially the log4c 1.0.11 patch,
however,  I don't have a gcc 3.4 box
Comment 6 Lee Thompson 2004-11-16 20:14:16 UTC
Here are how to repeat the problems with 1.0.11 and 1.0.12.
1) Add --enable-debug=yes to "econf" in the ebuild
2) ebuild log4c-1.0.12.ebuild compile
3) cd /var/tmp/portage/log4c-1.0.12/work/log4c-1.0.12/tests/log4c
4) export SD_ERROR=yes
5) cp /etc/log4crc.sample /etc/log4crc
6) ./rc_test
[ERROR] __sd_domnode_xml_parse() at /usr/share/bison/bison.simple:799 parse error
[ERROR] log4c_init() at init.c:61 loading /etc/log4crc failed
[ERROR] log4c_init() at init.c:61 loading /root/.log4crc failed
[ERROR] log4c_init() at init.c:61 loading ./log4crc failed
r/tmp/portage/log4c-1.0.12/work/log4c-1.0.12/tests/log4c/.libs/lt-test_rc: => test #0 :



=> test #0 :  passed
+=> test #1 :
=> test #1 :  failed
-=> test #2 :
=> test #2 :  passed
+ 2/3  failed.


Notice how the sample config fail fails to read!!!



On 1.0.10 included with this patch
1) Add --enable-debug=yes to "econf" in the ebuild
2) ebuild log4c-1.0.10.ebuild compile
3) cd /var/tmp/portage/log4c-1.0.12/work/log4c-1.0.10/tests/log4c
4) export SD_DEBUG=yes
5) cp /etc/log4crc.sample /etc/log4crc
6) ./rc_test
./test_rc 
[DEBUG] config_load() at rc.c:95 activating log4c debugging. level = 0
[DEBUG] config_load() at rc.c:87 using dynamic allocated buffer
[DEBUG] log4c_init() at init.c:58 loading /etc/log4crc succeeded
[ERROR] log4c_init() at init.c:56 loading /root/.log4crc failed
[ERROR] log4c_init() at init.c:56 loading ./log4crc failed
lt-test_rc: +-+ 2/3  failed.
[DEBUG] log4c_fini() at init.c:85 cleaning up

Notice the /etc/log4crc configuration file load succeeded.
For this reason I think 1.0.11 and 1.0.12 should not be marked stable.
Comment 7 Lee Thompson 2004-11-16 21:29:22 UTC
Created attachment 44137 [details, diff]
1.0.10 ebuild with getenv("HOME") fix

resubmitted.  Found log4c 1.0.10 cores when run under gentoo apache.   Gentoo's
Apache init.d startup clears the environment varibles and log4c doesn't check
for NULL for getenv("HOME");  Added this fix to the patch.
Comment 8 Daniel Black (RETIRED) gentoo-dev 2004-11-19 17:08:46 UTC
1.0.10-r1 added. Fixes to newer versions welcome.
Comment 9 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-20 05:11:31 UTC
I tried things discribed in #6 myself with current 1.0.10-r1 ebuild and this is what happend:

root (dev-libs/log4c): ebuild log4c-1.0.10-r1.ebuild compile
>>> md5 src_uri ;-) log4c-1.0.10.tar.gz
>>> Checking log4c-1.0.10.tar.gz's mtime...
>>> WORKDIR is up-to-date, keeping...
 * econf: updating /var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/config/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating /var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/config/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-test --enable-debug=yes
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gawk... (cached) gawk
checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-linux-gnu-gcc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of i686-pc-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... i686-pc-linux-gnu-gcc -E
checking for a BSD-compatible install... /bin/install -c
checking whether ln -s works... yes
checking whether make sets ${MAKE}... (cached) yes
checking for ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r
checking for BSD-compatible nm... nm
checking how to recognise dependant libraries... pass_all
checking command to parse nm output... ok
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for i686-pc-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-linux-gnu-strip... no
checking for strip... strip
checking for objdir... .libs
checking for i686-pc-linux-gnu-gcc option to produce PIC... -fPIC
checking if i686-pc-linux-gnu-gcc PIC flag -fPIC works... yes
checking if i686-pc-linux-gnu-gcc static flag -static works... yes
checking if i686-pc-linux-gnu-gcc supports -c -o file.o... yes
checking if i686-pc-linux-gnu-gcc supports -c -o file.lo... yes
checking if i686-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for ANSI C header files... (cached) yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdint.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking for i686-pc-linux-gnu-gcc option to accept ANSI C... none needed
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... (cached) yes
checking for working malloc... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether utime accepts a null argument... yes
checking for vprintf... yes
checking for _doprnt... no
checking for gettimeofday... yes
checking for memset... yes
checking for munmap... yes
checking for nl_langinfo... yes
checking for strdup... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for utime... yes
checking for EXPAT - version >= 1.95.1... yes
checking for doxygen... /usr/bin/doxygen
configure: creating ./config.status
config.status: creating Makefile
config.status: creating log4c-config
config.status: creating log4crc.sample
config.status: creating log4c.spec
config.status: creating config/Makefile
config.status: creating src/Makefile
config.status: creating src/log4c/Makefile
config.status: creating src/log4c/version.h
config.status: creating src/sd/Makefile
config.status: creating tests/Makefile
config.status: creating tests/log4c/Makefile
config.status: creating src/config.h
config.status: src/config.h is unchanged
config.status: executing default-1 commands
config.status: executing default commands
make  all-recursive
make[1]: Entering directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10'
Making all in config
make[2]: Entering directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/config'
Making all in src
make[2]: Entering directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src'
cd .. \
  && CONFIG_FILES= CONFIG_HEADERS=src/config.h \
     /bin/sh ./config.status
config.status: creating src/config.h
config.status: src/config.h is unchanged
config.status: executing default-1 commands
config.status: executing default commands
make  all-recursive
make[3]: Entering directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src'
Making all in sd
make[4]: Entering directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src/sd'
source='malloc.c' object='malloc.lo' libtool=yes \
depfile='.deps/malloc.Plo' tmpdepfile='.deps/malloc.TPlo' \
depmode=gcc3 /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src     -O3 -march=i686 -funroll-loops -pipe -Wall -D__SD_DEBUG__ -D__LOG4C_DEBUG__ -c -o malloc.lo `test -f malloc.c || echo './'`malloc.c
source='domnode.c' object='domnode.lo' libtool=yes \
depfile='.deps/domnode.Plo' tmpdepfile='.deps/domnode.TPlo' \
depmode=gcc3 /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src     -O3 -march=i686 -funroll-loops -pipe -Wall -D__SD_DEBUG__ -D__LOG4C_DEBUG__ -c -o domnode.lo `test -f domnode.c || echo './'`domnode.c
rm -f .libs/domnode.lo
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src -O3 -march=i686 -funroll-loops -pipe -Wall -D__SD_DEBUG__ -D__LOG4C_DEBUG__ -c domnode.c -MT domnode.lo -MD -MP -MF .deps/domnode.TPlo  -fPIC -DPIC -o .libs/domnode.lo
rm -f .libs/malloc.lo
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I../../src -O3 -march=i686 -funroll-loops -pipe -Wall -D__SD_DEBUG__ -D__LOG4C_DEBUG__ -c malloc.c -MT malloc.lo -MD -MP -MF .deps/malloc.TPlo  -fPIC -DPIC -o .libs/malloc.lo
domnode.c: In function `udata_push_cdata':
domnode.c:116: error: syntax error before "__FUNCTION__"
domnode.c: In function `sd_domnode_fread':
domnode.c:243: warning: assignment from incompatible pointer type
domnode.c:248: warning: passing arg 1 of `XML_SetStartElementHandler' from incompatible pointer type
domnode.c:249: warning: passing arg 1 of `XML_SetEndElementHandler' from incompatible pointer type
domnode.c:250: warning: passing arg 1 of `XML_SetCharacterDataHandler' from incompatible pointer type
domnode.c:251: warning: passing arg 1 of `XML_SetCommentHandler' from incompatible pointer type
domnode.c:252: warning: passing arg 1 of `XML_SetUserData' from incompatible pointer type
domnode.c:259: warning: passing arg 1 of `XML_GetBuffer' from incompatible pointer type
domnode.c:269: warning: passing arg 1 of `XML_ParseBuffer' from incompatible pointer type
domnode.c:270: error: syntax error before "__FUNCTION__"
domnode.c:302: warning: passing arg 1 of `XML_ParserFree' from incompatible pointer type
domnode.c: In function `sd_domnode_read':
domnode.c:317: warning: assignment from incompatible pointer type
domnode.c:322: warning: passing arg 1 of `XML_SetStartElementHandler' from incompatible pointer type
domnode.c:323: warning: passing arg 1 of `XML_SetEndElementHandler' from incompatible pointer type
domnode.c:324: warning: passing arg 1 of `XML_SetCharacterDataHandler' from incompatible pointer type
domnode.c:325: warning: passing arg 1 of `XML_SetCommentHandler' from incompatible pointer type
domnode.c:326: warning: passing arg 1 of `XML_SetUserData' from incompatible pointer type
domnode.c:328: warning: passing arg 1 of `XML_Parse' from incompatible pointer type
domnode.c:329: error: syntax error before "__FUNCTION__"
domnode.c:356: warning: passing arg 1 of `XML_ParserFree' from incompatible pointer type
make[4]: *** [domnode.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
malloc.c: In function `fixup_null_alloc':
malloc.c:51: error: syntax error before "__FUNCTION__"
malloc.c:57: error: syntax error before "__FUNCTION__"
make[4]: *** [malloc.lo] Error 1
make[4]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src/sd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/log4c-1.0.10-r1/work/log4c-1.0.10'
make: *** [all] Error 2

!!! ERROR: dev-libs/log4c-1.0.10-r1 failed.
!!! Function src_compile, Line 40, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Without the --enable-debug=yes flag the ebuild installs just fine...

root (dev-libs/log4c): emerge info
Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r4 i686)
=================================================================
System uname: 2.6.9-gentoo-r4 i686 Pentium III (Coppermine)
Gentoo Base System version 1.6.6
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.92.0.2-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=i686 -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=i686 -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://mir.zyrianes.net/gentoo/ http://gentoo.inode.at/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa apache2 arts avi berkdb bitmap-fonts boundschecking cdb cdr crypt cups dba devmap encode esd f77 fam fbcon flac foomaticdb fortran gd gd-external gdbm gif gphoto2 gpm gtk2 icc imagemagick imlib java jikes jpeg junit kde libg++ libwww mad mcal mikmod mmx motif mpeg mysql ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl png pnp postgres python qt quicktime readline samba sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usb winbind x86 xml2 xprint xv zlib linguas_de"
Comment 10 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-20 05:33:24 UTC
seems like the gcc 3.4.3 is the problem for me...
I switched back to the gcc 3.3.4 and it compiles fine.

But still I get warnings with gcc 3.3.4 that hints to me why 3.4.3 isn't working anymore:

malloc.c:51: warning: concatenation of string literals with __FUNCTION__ is deprecated
malloc.c:57: warning: concatenation of string literals with __FUNCTION__ is deprecated
Comment 11 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-20 05:59:59 UTC
sorry for being this annoying, but I got past this problem quite easy.
here is a patch that needs to be applied to src/sd/error.h :

--- error.h.org 2004-11-20 14:57:44.261071112 +0100
+++ error.h     2004-11-20 14:56:59.493876760 +0100
@@ -14,13 +14,13 @@
 #ifdef __SD_DEBUG__

 #   define __sd_str(n) #n
-#   define __sd_location(n) __FUNCTION__"() at " __FILE__":" __sd_str(n)
+#   define __sd_location(n) "() at " __FILE__":" __sd_str(n)
 #   define sd_location  __sd_location(__LINE__)

 #   define sd_debug(a_format, ...) \
-       (getenv("SD_DEBUG") ? fprintf(stderr, "[DEBUG] "sd_location" "a_format"\n", ##__VA_ARGS__ ) : 0)
+       (getenv("SD_DEBUG") ? fprintf(stderr, "[DEBUG] %s"sd_location" "a_format"\n", __FUNCTION__,##__VA_ARGS__ ) : 0)
 #   define sd_error(a_format, ...) \
-       (getenv("SD_ERROR") ? fprintf(stderr, "[ERROR] "sd_location" "a_format"\n", ##__VA_ARGS__ ) : 0)
+       (getenv("SD_ERROR") ? fprintf(stderr, "[ERROR] %s"sd_location" "a_format"\n", __FUNCTION__,##__VA_ARGS__ ) : 0)
 #   define sd_oserror(afunc, aparam) \
         (sd_error("%s(%s): #%d %s", afunc, aparam, errno, strerror(errno)), -1)
Comment 12 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-20 06:04:37 UTC
this also applies for log4c 1.0.11 and 1.0.12 ebuild (which still contain the same problem in src/sd/error.h )
Comment 13 Daniel Black (RETIRED) gentoo-dev 2004-11-21 00:59:15 UTC
thanks for the patches added - do you want to submit them upstream?
Comment 14 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-21 03:01:58 UTC
I added a bugreport about the problem and a patch on the log4c bugtracker on sourceforge. I think we can consider it as submitted to upstream that way.
Comment 15 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-21 03:10:45 UTC
Having a quick look at the ebuilds it seems to me you added my patch only to the 1.0.11 and 1.0.12 ebuild. Maybe I haven't said it clear enough when I said it's also needed for those, I implicit ment it's also needed for 1.0.10-r1 (where i first discovered this problem)
Comment 16 Lee Thompson 2004-11-22 15:13:05 UTC
Olaf, we're you able to reproduce the problem I'm seeing in regards to loading a /etc/rclog4crc configuration on versions 1.0.11 and 1.0.12?  I'm still showing that v1.0.11 and v1.0.12 do not load config files.

I think 1.0.11 and 1.0.12 should be not be marked stable for two reasons.
1) Can not load config files which makes it unuseable or at best very limited
2) Developers have not released all source code (specifically the bison code) which makes it questionable as far as open source.
Comment 17 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-22 18:15:01 UTC
yes, I'm experiencing the same problems as you... and I don't have a single clue were to start searching for the reason...

and as a sidenote....
and I'm still waiting to see the error.h patch applied in 1.0.10-r1 ebuild...
Comment 18 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-22 19:14:06 UTC
I debuged the xml-parser a bit (by enabling lots of debug output) and realized it fails on the comments in the /etc/log4crc file
I tried removing them and the parser silently accepted the file - BUT no log levels were initialised afterwards... So the xml parser is also experiencing other heavy problems...
I don't think we can get past this problem without taking a look at the bison stuff to see where in the grammar the problem resides....
Comment 19 Lee Thompson 2004-11-22 23:06:47 UTC
I made the same debugging attempt and gave up.  Version 1.0.10 used expat without the bison stuff and seems to work okay.  I imagine there was a reason why the developers went away from expat, but the removal attempt doesn't like the gcc v3.3 and v3.4 compilers.

The v1.0.10-r1 with Olaf's patch works nice on amd_64. and i386.
Comment 20 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-11-24 23:47:37 UTC
as I just found the problem with coments in XML we detected had allready been filed in log4c bugtracker in febuary:

http://sourceforge.net/tracker/index.php?func=detail&aid=893587&group_id=38627&atid=422931
Comment 21 Lee Thompson 2004-11-30 18:35:39 UTC
Created attachment 45034 [details, diff]
compiler warning patch for 1.0.10 and keywords stability as I see it

Here is how see log4c at this point in patch format.
Comment 22 Daniel Black (RETIRED) gentoo-dev 2004-12-02 13:07:53 UTC
log4c-1.0.10-r1.ebuild fixed as requested.
Comment 23 Lee Thompson 2004-12-02 15:25:55 UTC
Not yet Daniel!  Re-read comment #16 through #19.
Both Olaf and I can not get log4c 1.0.11 working and we can't debug it as the log4c tarball doesn't have all the source code (missing bison code).  So 1.0.10-r1 works on x86_64 and i386.  1.0.11 doesn't work on i386 (verified by two users).  

Two more things are needed to close this out.
1) Mark 1.0.10-r1 stable on x86_64
2) Mark 1.0.11 experimental on i386

Have no idea about sparc.

Thanks, appreciate you looking into this.
Comment 24 Daniel Black (RETIRED) gentoo-dev 2004-12-03 20:02:14 UTC
package masked >=dev-libs/log4c-1.0.11 (package.mask) added ~x86 and ~sparc keywords.

keyword request sparc and amd64 on 1.0.10-r1 please.
Comment 25 Gustavo Zacarias (RETIRED) gentoo-dev 2004-12-06 07:04:30 UTC
I'm getting a sandbox violation with USE="doc" for 1.0.10-r1 on sparc.

/bin/install -c -m 644 log4c.pdf /var/tmp/portage/log4c-1.0.10-r1/image//usr/share/doc/log4c-1.0.10
cp -r html /usr/share/doc/log4c-1.0.10
ACCESS DENIED  mkdir:     /usr/share/doc/log4c-1.0.10
cp: cannot create directory `/usr/share/doc/log4c-1.0.10': Permission denied

Comment 26 f5d8fd51ed1e804c9e8d0357e8614e0493b06e96 2004-12-06 14:11:52 UTC
well... looks like things have been changed and tweaked somehow 
and files/log4c-1.0.10-nodocs.patch contains more than just the plain nodocs patch.

it also contains a patch to get log4c-1.0.10 to compile with gcc 3.4.x (the same things as in files/log4c_1.0.11_test.patch)

unfortunatly the log4c-1.0.10-nodoc.patch isn't applied anymore with USE='DOC' and thus things aren't compiling with gcc 3.4.x and I can't even try to fix the sandbox violation without switching my gcc...

I would ask to get the log4c-1.0.10-nodoc patch seperated into a nodoc part and into a gcc-3.4.x compat part (maybe make the log4c_1.0.11_test.patch a common patch for 1.0.10 and 1.0.11)

also I wonder why there is a log4c-1.0.11-function.patch and a identical log4c-1.0.12-function.patch
Comment 27 Lee Thompson 2004-12-07 21:47:57 UTC
When I wrote the 1.0.10-r1 ebuild I didn't have a DOCS options as I couldn't figure out what the DEPEND would be so I hacked the log4c makefile to exclude docs.  http://bugs.gentoo.org/attachment.cgi?id=43573&action=view.  As it stands now, turning on USE=docs will have missing dependencies so you might want to remove it from the ebuild.

It would definitely be cleaner to separate the nodocs and the gcc 3.4 patch but I saw them as two things needed to get a working version of log4c into portage.

I'm not too conerned with 1.0.12 as it needs lots of work on the XML parser.
Comment 28 Daniel Black (RETIRED) gentoo-dev 2005-01-01 18:52:39 UTC
I hope I've got this fixed now. *wimper*
Comment 29 Gustavo Zacarias (RETIRED) gentoo-dev 2005-01-03 08:00:54 UTC
sparc tasty, move along ;-)
Comment 30 Lee Thompson 2005-01-03 16:32:45 UTC
looks good!  Thanks.
Comment 31 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-01-04 17:52:49 UTC
1.0.10-r1 has already been marked stable on amd64 by someone else. I have tested it and multiple sandbox violations are registered with USE=doc set, and it stops at a prompt. I don't think these errors are specific to amd64, but should be corrected. It compiles without any problems when USE=-doc is set.