log4cpp-devel — technical discussions about the development of log4cpp

Re: [Log4cpp-devel] missing .dsp files in 0.3.2rc5

[Bastiaan B. <bas...@li...>]

On Thu, 2002-10-03 at 04:05, ms...@po... wrote:
> hi!
> 
> When opening up the .dsw in vc6 the following .dsp are missing.  I looked 
> in the .zip and didn't see them there.
> 
> log4cppDLL
> testDLL
> testMain
> testNTEventLog
> testPattern
> testPropConfig
> 
> 
> revision control mishap? :-)
>

No, a MSVC6 vs automake disconnect: the win32 developers sometimes
forget to add new files to EXTRA_DIST in Makefile.am and I won't notice
because 'make distcheck' doesn't complain. Thanks for reporting it.
I've added the necessary Makefiles to build a complete tarball. In the
meanwhile you can get the missing files by checking out from CVS. 
 
> 
> 
> 
> Any word when 0.3.2 is going to be released? :-)

Today :-)
I had planned to have more documentation in 0.3.2, but I don't want to
hold up the 0.3.2 release any longer.

Regards,

Bastiaan Bakker

> 
> 
> 
> thanks!
> 
> ~msew
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] xml support

[<ms...@po...>]

Hi! :-)

Are there any plans to have xml configuration files ala log4j ? :-)


thanks!

~msew

[Log4cpp-devel] missing .dsp files in 0.3.2rc5

[<ms...@po...>]

hi!

When opening up the .dsw in vc6 the following .dsp are missing.  I looked 
in the .zip and didn't see them there.

log4cppDLL
testDLL
testMain
testNTEventLog
testPattern
testPropConfig


revision control mishap? :-)




Any word when 0.3.2 is going to be released? :-)



thanks!

~msew

[Log4cpp-devel] aCC support HP-UX?

[Stuart S. <ssi...@ya...>]

I'm trying to get log4cpp compiled on the following compiler:
aCC: HP ANSI C++  B3910B A.02.25

This compiler doesn't seem to have an STL implementation which is
obviously causing me problems.  Have there been any workarounds for
this platform?


Thanks.

=====


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Derek A. <wa...@MI...>]

Bastiaan Bakker <Bas...@li...> writes:

> Can you find out what's going wrong? 

Actually, nothing -- it was me not understanding the interface.  When
I set the facility to "16" I got my logs at mail.* (where one would
expect), so it is working, just confusing.

> The 'name' variant will not be ready for 0.3.2, but a fix for your
> problem will.

No worries.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       wa...@MI...                        PGP key available

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-09-18 at 16:24, Derek Atkins wrote:
> Bastiaan Bakker <Bas...@li...> writes:
> 
> > The assumption is that in the RemoteSyslogAppnder one specifies the
> > facility using its defined constant, eg. LOG_NEWS, rather than an
> > explicit numeric value. All the constants are already multiplied by 8.  
> > This is what openlog(3) expects as well. 
> 
> True...
> 
> > > A side note: it appears that the PropertyConfigurator is not properly
> > > reading the facility number for a "SyslogAppender" from the
> > > configuration file.
> > 
> > Hmm, yes, that's a bug. I'll add the multiplication. Ideally the
> > .facility property should accept names as well as values.
> 
> I was having the problem that the getInt() was returning the default
> even if I put a valid number in there..  Although providing a name
> would be usefule.
> 

Can you find out what's going wrong? 
The 'name' variant will not be ready for 0.3.2, but a fix for your
problem will.


> PS_ Thanks for all your work on log4cpp!

Thanks. 

Bastiaan Bakker

> 
> > Cheers,
> > 
> > Bastiaan Bakker
> > LifeLine Networks bv
> 
> -derek
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        wa...@MI...                        PGP key available

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Derek A. <wa...@MI...>]

Bastiaan Bakker <Bas...@li...> writes:

> The assumption is that in the RemoteSyslogAppnder one specifies the
> facility using its defined constant, eg. LOG_NEWS, rather than an
> explicit numeric value. All the constants are already multiplied by 8.  
> This is what openlog(3) expects as well. 

True...

> > A side note: it appears that the PropertyConfigurator is not properly
> > reading the facility number for a "SyslogAppender" from the
> > configuration file.
> 
> Hmm, yes, that's a bug. I'll add the multiplication. Ideally the
> .facility property should accept names as well as values.

I was having the problem that the getInt() was returning the default
even if I put a valid number in there..  Although providing a name
would be usefule.

PS_ Thanks for all your work on log4cpp!

> Cheers,
> 
> Bastiaan Bakker
> LifeLine Networks bv

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       wa...@MI...                        PGP key available

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-09-18 at 15:45, Derek Atkins wrote:
> Thanks.  I realized (after I went to bed) that this patch assumes you
> supply a valid facility number for remote logging (i.e. you supply
> facility * 8).  A (slightly) better "patch" would be:
> 
>         int facility = ((_facility & 7) ? (_facility<<3) : _facility);
>         int priority = facility + toSyslogPriority(event.priority);
> 
> This way if you supply a facility of '1' (for log_user) it will still
> do the right thing (by converting it to '8').  Unfortunately this will
> fail for people who supply an '8' for log_uucp or '16' for log_local0,
> but it should work for all other log facilities.
> 

The assumption is that in the RemoteSyslogAppnder one specifies the
facility using its defined constant, eg. LOG_NEWS, rather than an
explicit numeric value. All the constants are already multiplied by 8.  
This is what openlog(3) expects as well. 
 
> A side note: it appears that the PropertyConfigurator is not properly
> reading the facility number for a "SyslogAppender" from the
> configuration file.

Hmm, yes, that's a bug. I'll add the multiplication. Ideally the
.facility property should accept names as well as values.

Cheers,

Bastiaan Bakker
LifeLine Networks bv

> 
> -derek
> 
> Bastiaan Bakker <Bas...@li...> writes:
> 
> > Hi Derek,
> > 
> > Thanks for the report. This bug appears to be present in all log4cpp
> > versions. Merged your patch, 0.3.2 final should be OK.
> > 
> > Cheers,
> > 
> > Bastiaan
> > 
> > 
> > On Wed, 2002-09-18 at 03:16, Derek Atkins wrote:
> > > The RemoteSyslogAppender in both 0.3.2rc4 and rc5 fail to log
> > > to the proper facility.  In fact, it will always log to LOG_KERN
> > > (which is not what I want).
> > > 
> > > This patch fixes the code to log properly (given a valid facility):
> > > 
> > > --- src/RemoteSyslogAppender.cpp~       Tue Jul  2 18:14:37 2002
> > > +++ src/RemoteSyslogAppender.cpp        Tue Sep 17 20:41:39 2002
> > > @@ -125,7 +125,7 @@
> > >         std::string message(_getLayout().format(event));
> > >         int len = message.length() + 16;
> > >         char *buf = new char [len];
> > > -        int priority = toSyslogPriority(event.priority);
> > > +        int priority = _facility + toSyslogPriority(event.priority);
> > >         int len2 = sprintf (buf, "<%d>", priority);
> > >         memcpy (buf + len2, message.data(), len - 16);
> > >         sockaddr_in sain;
> > > 
> > > Thanks,
> > > 
> > > -derek
> > > -- 
> > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > >        Member, MIT Student Information Processing Board  (SIPB)
> > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> > >        wa...@MI...                        PGP key available
> > 
> > 
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        wa...@MI...                        PGP key available

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Derek A. <wa...@MI...>]

Thanks.  I realized (after I went to bed) that this patch assumes you
supply a valid facility number for remote logging (i.e. you supply
facility * 8).  A (slightly) better "patch" would be:

        int facility = ((_facility & 7) ? (_facility<<3) : _facility);
        int priority = facility + toSyslogPriority(event.priority);

This way if you supply a facility of '1' (for log_user) it will still
do the right thing (by converting it to '8').  Unfortunately this will
fail for people who supply an '8' for log_uucp or '16' for log_local0,
but it should work for all other log facilities.

A side note: it appears that the PropertyConfigurator is not properly
reading the facility number for a "SyslogAppender" from the
configuration file.

-derek

Bastiaan Bakker <Bas...@li...> writes:

> Hi Derek,
> 
> Thanks for the report. This bug appears to be present in all log4cpp
> versions. Merged your patch, 0.3.2 final should be OK.
> 
> Cheers,
> 
> Bastiaan
> 
> 
> On Wed, 2002-09-18 at 03:16, Derek Atkins wrote:
> > The RemoteSyslogAppender in both 0.3.2rc4 and rc5 fail to log
> > to the proper facility.  In fact, it will always log to LOG_KERN
> > (which is not what I want).
> > 
> > This patch fixes the code to log properly (given a valid facility):
> > 
> > --- src/RemoteSyslogAppender.cpp~       Tue Jul  2 18:14:37 2002
> > +++ src/RemoteSyslogAppender.cpp        Tue Sep 17 20:41:39 2002
> > @@ -125,7 +125,7 @@
> >         std::string message(_getLayout().format(event));
> >         int len = message.length() + 16;
> >         char *buf = new char [len];
> > -        int priority = toSyslogPriority(event.priority);
> > +        int priority = _facility + toSyslogPriority(event.priority);
> >         int len2 = sprintf (buf, "<%d>", priority);
> >         memcpy (buf + len2, message.data(), len - 16);
> >         sockaddr_in sain;
> > 
> > Thanks,
> > 
> > -derek
> > -- 
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        wa...@MI...                        PGP key available
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       wa...@MI...                        PGP key available

[Log4cpp-devel] Re: Patch for RemoteSyslogAppender to log facility

[Bastiaan B. <Bas...@li...>]

Hi Derek,

Thanks for the report. This bug appears to be present in all log4cpp
versions. Merged your patch, 0.3.2 final should be OK.

Cheers,

Bastiaan


On Wed, 2002-09-18 at 03:16, Derek Atkins wrote:
> The RemoteSyslogAppender in both 0.3.2rc4 and rc5 fail to log
> to the proper facility.  In fact, it will always log to LOG_KERN
> (which is not what I want).
> 
> This patch fixes the code to log properly (given a valid facility):
> 
> --- src/RemoteSyslogAppender.cpp~       Tue Jul  2 18:14:37 2002
> +++ src/RemoteSyslogAppender.cpp        Tue Sep 17 20:41:39 2002
> @@ -125,7 +125,7 @@
>         std::string message(_getLayout().format(event));
>         int len = message.length() + 16;
>         char *buf = new char [len];
> -        int priority = toSyslogPriority(event.priority);
> +        int priority = _facility + toSyslogPriority(event.priority);
>         int len2 = sprintf (buf, "<%d>", priority);
>         memcpy (buf + len2, message.data(), len - 16);
>         sockaddr_in sain;
> 
> Thanks,
> 
> -derek
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        wa...@MI...                        PGP key available

[Log4cpp-devel] Patch for RemoteSyslogAppender to log facility

[Derek A. <wa...@MI...>]

The RemoteSyslogAppender in both 0.3.2rc4 and rc5 fail to log
to the proper facility.  In fact, it will always log to LOG_KERN
(which is not what I want).

This patch fixes the code to log properly (given a valid facility):

--- src/RemoteSyslogAppender.cpp~       Tue Jul  2 18:14:37 2002
+++ src/RemoteSyslogAppender.cpp        Tue Sep 17 20:41:39 2002
@@ -125,7 +125,7 @@
        std::string message(_getLayout().format(event));
        int len = message.length() + 16;
        char *buf = new char [len];
-        int priority = toSyslogPriority(event.priority);
+        int priority = _facility + toSyslogPriority(event.priority);
        int len2 = sprintf (buf, "<%d>", priority);
        memcpy (buf + len2, message.data(), len - 16);
        sockaddr_in sain;

Thanks,

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       wa...@MI...                        PGP key available

Re: [Log4cpp-devel] Patch for QNX Neutrino 6.1.0

[Bastiaan B. <bas...@li...>]

On Thu, 2002-09-05 at 18:48, Harald Wellmann wrote:
> I've submitted a patch for QNX 6.1 via the patch area on the log4cpp project
> page.
> 
> See my comments there for details.

Great. Since you were so quick, I couldn't resist and started merging it
for 0.3.2. This also means an rc5 release in the next few days instead
of 0.3.2 final. Haven't had time to finish yet, hopefully tomorrow
night. 

Regards,

Bastiaan Bakker
LifeLine Networks bv
 

> 
> The changes are minimal (but I had a lot of "fun" with autoconf), and I hope
> they don't break anything on other platforms, but I haven't checked any, not
> even Linux...
> 
> Regards,
> 
> Harald
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Patch for QNX Neutrino 6.1.0

[Harald W. <Har...@gm...>]

I've submitted a patch for QNX 6.1 via the patch area on the log4cpp project
page.

See my comments there for details.

The changes are minimal (but I had a lot of "fun" with autoconf), and I hope
they don't break anything on other platforms, but I haven't checked any, not
even Linux...

Regards,

Harald

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

[Log4cpp-devel] Additivity patch

[Brodie, R (R. <R.B...@rl...>]

I've uploaded a trivial patch to allow additivity to be set in a properties
file. Have I missed something? It seems to work OK.

Richard Brodie.

Re: [Log4cpp-devel] Porting log4cpp to QNX Neutrino 6.1

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-09-04 at 10:16, Harald Wellmann wrote:
>  Bastiaan Bakker  schrieb am 03.09.02 18:34:55:
> > On Sat, 2002-08-24 at 12:53, Harald Wellmann wrote:
> > >
> > > the short story is: log4cpp is running on QNX 6.1 without significant
> > > changes, and it passes all tests.
> > >
> >
> > That's good to hear. Which version are you talking about? 0.2.7 or
> > 0.3.x?
> >
> 
> I've been working on the 0.3.2rc4 tarball.
> 
> 
> > > Now here's a summary of the changes I had to make:
> > >
> > > - With the -pedantic compiler option, gcc gets so pedantic it refuses to
> > > compile anything at all, so I turned it off.
> > >
> > I believe I already turned off -pedantic for g++ 2.96 to get rid of this
> > endless stream of warnings about code in the iostreams lib. Maybe I
> > should turn it off completely by default and only enable it for testing.
> >
> 
> Yes, I've found that in m4/PETI_PEDANTIC_GCC.m4. It's turned off for
> 2.96*, but 2.95* is covered by the default case. We could simply add
> another case for 2.95.
> 
Yes. I'll switch main log4cpp development to gcc 3.2 soon anyway, so
being less pedantic for older gcc version would be wise.

> 
> > > - Optimization -O2 produces internal compiler errors on some sources, so
> > > I removed that as well.
> > >
> 
> Is that m4 file also the "right" place to disable -O2 for QNX 6.1.0?
> 

Well, if we promote this macro to a generic 'tune gcc' thing, then it's
the right place. Can you check what the right platform identifier is for
QNX? Then we can add the appropiate check. Run config/config.guess to
obtain the identifier.
 

> 
> > > - gcc by default simply ignores the std:: namespace (at least in
> > > versions <= 2.95.3; I don't know about the most recent versions), but
> > > not in the QNX variant with the Dinkum libs. In most files, I had to
> > > insert "using namespace std;" or prefix a few function calls with std::.
> > >
> >
> > g++ < 3.0 is lax in enforcing proper namespace usage. However, 3.0 and
> > higher do complain, so any place where log4cpp is missing a necessary
> > 'std::' is a bug that should be fixed. Please report any occurrences you
> > encounter. BTW, I prefer to avoid 'using namespace ..' because it tends
> > to defeat the purpose of namespaces.
> >
> 
> Yes, I agree. And since "using std::map;" (i.e. single identifiers instead
> of the
> complete namespace) does not work on WinCE 3.0, I'd better use explicit
> prefixes for all occurrences.
> 
> 
> > > - A similar problem is the syntax of standard C header includes. On QNX,
> > > you have to write #include instead of #include , or
> > > you will get lots of symbol redefinition errors.
> > >
> >
> > Yes, we'll have to change these as well, instead of
> > is the 'proper' C++ way.
> >
> 
> Exactly, and <> brackets are reserved for system includes, so you we should
> never write #include but use "" instead. Someone has started
> cleaning that up between 0.2.* and 0.3.* but you still see the angular
> brackets
> in a few places.
>

This is a misconception. <> brackets are not reserved for system
includes. The only thing the ISO C++ standard says (in par. 16.2) about
the differences between "" and <> is that for "" the preprocessor will
search in 'an implementation dependent manner' and will fall back to
searching like a #include <> if this fails. Gcc has implemented this as
searching in the directory of the original source file for "" and
searching in the standard directories (/usr/include, etc.) and those
specified with '-I' for <>. This is also what Stroustrup specifies in
his reference manual (par. 16.3.2c).
Therefore the convention in log4cpp is: if a header file is part of its
interface, that is, its in include/log4cpp/ or subdirectory include it
with #include<>. If on the other hand it's internal (e.g. in src/)
#include it with #include""
 
 
> > > - Some of the global Makefile settings are different, of course. The
> > > compiler and linker is called QCC, and you don't link any external
> > > libraries. pthread_* stuff is available by default.
> >
> > The compiler and linker can be changed by setting environment variables
> > CC and LD prior to invoking ./configure. E.g. with the bash shell:
> >
> > CC=QCC LD=QCC ./configure --prefix=...
> >
> > The pthread detection M4 macro has been rather quickly hacked together
> > to get pthread support in. We should be able check we need -lpthread or
> > not for pthread support.
> > If you remove the '-lpthread' from 'LIBS="$LIBS -lpthread"' in
> > ./configure, does ./configure still recognize the pthread support?
> >
> 
> I'll try that and let you know the results.
> 
> 
> > >
> > > - libtool refused to produce libraries. I installed a newer libtool
> > > version and I got archived libraries, but I haven't found out how to
> > > produce shared libs yet.
> > >
> >
> > OK, so '--disable-shared' is recommended for now? Something to put in
> > the build documentation.
> >
> 
> It works without --disable-shared, libtool simply prints a warning that it
> won't generate shared libraries. Anyway, the problem is somewhere else,
> because shared libraries as such are no problem at all on QNX.
> 
> I don't know enough about libtool, but my guess it that it might work
> if I installed the newest autoconf/automake/libtool stuff and rerun
> autoconf and automake.

I use autoconf 2.53, automake 1.6.2 and 1.4.2. Should be new enough! 
Maybe the libtool FAQ or mailinglist have some clues...
 
> 
> I don't understand how the libtool generated by configure in the log4cpp
> root directory relates to the libtool installed on your platform, but simply
> using the installed one instead of the generated one (that what I did to
> make it work at all) is not the best way, I suppose.

If you don't run ./autogen.sh before running ./configure (and for a
log4cpp from a tar ball you don't need to), the libtool installed on
your platform won't be used at all. 

> 
> So it seems I'm going to learn more about autoconf and friends than I
> ever wanted to know...
>

Heheh, before you know it you're sucked into the tar pit of M4
bastardizations :-)

Regards,

Bastiaan

 
> Regards,
> Harald
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] Porting log4cpp to other platforms

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-09-04 at 10:14, Harald Wellmann wrote:
> Thanks for the information about log4cpp project management, if that's
> what you call it. Maybe you can just cut'n'paste the corresponding section
> from your email into the project homepage or the log4cpp README, then
> you won't have to answer this question agian ;-)
> 

Good idea.

> The CVS and patch handling is clear and makes sense; the only problem I
> see - and again, this question has probably been asked by many sourceforge
> contributors before - is how to access the repository across a company
> firewall.
> 
> We can only do HTTP and FTP over a Squid proxy, and that's it, no SSH and
> certainly no cvs pserver on port 2401. Is there some way of tunneling cvs
> over HTTP?

Probably there is, but SourceForge doesn't provide such a tunnel.

> 
> Probably not, so I'll either have to coax our sysadmin to open the ssh port
> or do my cvs work from home, as a last resort...

Getting that ssh port open will be useful for other purposes as well, so
it's worth a try.
Alternatively there is an alternative that should work well enough: at
http://cvs.sourceforge.net/cvstarballs/log4cpp-cvsroot.tar.gz you can
download a tar ball of log4cpp's CVS repository. With that it's trivial
to set up a local CVS repository copy and work with that instead of the
real CVS repository.

> 
> Anyway, I'll brush up my results and send in patches for QNX and WinCE,
> hopefully some time next week.
> 

OK, I'm looking forward to them. Looks like the QNX stuff easily can be
included for 0.3.3 (if you don't mind I go ahead with the 0.3.2 release
later this week). 
For the WinCE stuff we'll have to work out the best way to fit it in (or
not).

> Going by your definition, I'm afraid that WinCE doesn't qualify as a
> "decent"
> platform, but alas, it's what our customers want.... And the core parts of
> log4cpp
> do work, after some more or less tricky hacks (the biggest problem is
> exception
> handling, or the lack of it). The question is whether or not you want to see
> them
> on the log4cpp main trunk.
> 

I'm afraid the restrictions imposed by WinCE would make work on log4cpp
too unpleasant for developers on more 'decent' platforms, but I won't
judge before I see the details. 

> I'll post more details on the WinCE thread of this list.
> 

OK.

Regards,

Bastiaan

> Regards,
> 
> Harald
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

RE: [Log4cpp-devel] Configuration file

[David R. <dre...@mo...>]

Hello,=20

You can find some sample properties files in the tests directory, for
use with the PropertyConfigurator available in the latest development
release. XML configuration is not supported.

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: Slimane Amar [mailto:sa...@ge...]=20
Sent: Tuesday, September 03, 2002 17:11
To: log...@li...
Subject: [Log4cpp-devel] Configuration file


Hi all,

I'm new to log4cpp and I need some help to use a configuration file=20
(xml or other format).=20
Can someone give me an example of file.=20

Thanks=20
=20


--------------------------------------------------
Slimane AMAR         Mail: sa...@ge...
GENIGRAPH            URL : http://www.genigraph.fr
104, rue Castagnary  Tel : +33 01 45 33 64 63
F-75015 PARIS FRANCE Fax : +33 01 45 33 89 63
--------------------------------------------------



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell
phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Durceforge1&refcode1=3D3390
_______________________________________________
Log4cpp-devel mailing list
Log...@li...
https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] Missing file in 0.3.2rc4?

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-09-04 at 10:36, Harald Wellmann wrote:
> Bastiaan,
> 
> Having read your remarks on the autoconf pthread check, 
> I tried to locate the stuff in the code.
> 
> But the file m4/BB_CHECK_PTHREADS.m4 is missing in the
> rc4 tarball. Actually, this file only has the following CVS Tags:
> REL_0_3_2_RC2, HEAD.
> 
> Did you remove it from RC3 and higher intentionally?
> 

No, this must have been checkout/update goof up by me: probably RC2 has
been released from my computer at work and RC4 from the one at home or
vice versa. 
Thanks for pointing it out!

Regards,

Bastiaan


> Regards,
> Harald
> 
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Missing file in 0.3.2rc4?

[Harald W. <Har...@gm...>]

Bastiaan,

Having read your remarks on the autoconf pthread check, 
I tried to locate the stuff in the code.

But the file m4/BB_CHECK_PTHREADS.m4 is missing in the
rc4 tarball. Actually, this file only has the following CVS Tags:
REL_0_3_2_RC2, HEAD.

Did you remove it from RC3 and higher intentionally?

Regards,
Harald


-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Log4cpp-devel] Porting log4cpp to QNX Neutrino 6.1

[Harald W. <Har...@gm...>]

 Bastiaan Bakker  schrieb am 03.09.02 18:34:55:
> On Sat, 2002-08-24 at 12:53, Harald Wellmann wrote:
> >
> > the short story is: log4cpp is running on QNX 6.1 without significant
> > changes, and it passes all tests.
> >
>
> That's good to hear. Which version are you talking about? 0.2.7 or
> 0.3.x?
>

I've been working on the 0.3.2rc4 tarball.


> > Now here's a summary of the changes I had to make:
> >
> > - With the -pedantic compiler option, gcc gets so pedantic it refuses to
> > compile anything at all, so I turned it off.
> >
> I believe I already turned off -pedantic for g++ 2.96 to get rid of this
> endless stream of warnings about code in the iostreams lib. Maybe I
> should turn it off completely by default and only enable it for testing.
>

Yes, I've found that in m4/PETI_PEDANTIC_GCC.m4. It's turned off for
2.96*, but 2.95* is covered by the default case. We could simply add
another case for 2.95.


> > - Optimization -O2 produces internal compiler errors on some sources, so
> > I removed that as well.
> >

Is that m4 file also the "right" place to disable -O2 for QNX 6.1.0?


> > - gcc by default simply ignores the std:: namespace (at least in
> > versions <= 2.95.3; I don't know about the most recent versions), but
> > not in the QNX variant with the Dinkum libs. In most files, I had to
> > insert "using namespace std;" or prefix a few function calls with std::.
> >
>
> g++ < 3.0 is lax in enforcing proper namespace usage. However, 3.0 and
> higher do complain, so any place where log4cpp is missing a necessary
> 'std::' is a bug that should be fixed. Please report any occurrences you
> encounter. BTW, I prefer to avoid 'using namespace ..' because it tends
> to defeat the purpose of namespaces.
>

Yes, I agree. And since "using std::map;" (i.e. single identifiers instead
of the
complete namespace) does not work on WinCE 3.0, I'd better use explicit
prefixes for all occurrences.


> > - A similar problem is the syntax of standard C header includes. On QNX,
> > you have to write #include instead of #include , or
> > you will get lots of symbol redefinition errors.
> >
>
> Yes, we'll have to change these as well, instead of
> is the 'proper' C++ way.
>

Exactly, and <> brackets are reserved for system includes, so you we should
never write #include but use "" instead. Someone has started
cleaning that up between 0.2.* and 0.3.* but you still see the angular
brackets
in a few places.

> > - Some of the global Makefile settings are different, of course. The
> > compiler and linker is called QCC, and you don't link any external
> > libraries. pthread_* stuff is available by default.
>
> The compiler and linker can be changed by setting environment variables
> CC and LD prior to invoking ./configure. E.g. with the bash shell:
>
> CC=QCC LD=QCC ./configure --prefix=...
>
> The pthread detection M4 macro has been rather quickly hacked together
> to get pthread support in. We should be able check we need -lpthread or
> not for pthread support.
> If you remove the '-lpthread' from 'LIBS="$LIBS -lpthread"' in
> ./configure, does ./configure still recognize the pthread support?
>

I'll try that and let you know the results.


> >
> > - libtool refused to produce libraries. I installed a newer libtool
> > version and I got archived libraries, but I haven't found out how to
> > produce shared libs yet.
> >
>
> OK, so '--disable-shared' is recommended for now? Something to put in
> the build documentation.
>

It works without --disable-shared, libtool simply prints a warning that it
won't generate shared libraries. Anyway, the problem is somewhere else,
because shared libraries as such are no problem at all on QNX.

I don't know enough about libtool, but my guess it that it might work
if I installed the newest autoconf/automake/libtool stuff and rerun
autoconf and automake.

I don't understand how the libtool generated by configure in the log4cpp
root directory relates to the libtool installed on your platform, but simply
using the installed one instead of the generated one (that what I did to
make it work at all) is not the best way, I suppose.

So it seems I'm going to learn more about autoconf and friends than I
ever wanted to know...

Regards,
Harald

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Log4cpp-devel] Porting log4cpp to other platforms

[Harald W. <Har...@gm...>]

Thanks for the information about log4cpp project management, if that's
what you call it. Maybe you can just cut'n'paste the corresponding section
from your email into the project homepage or the log4cpp README, then
you won't have to answer this question agian ;-)

The CVS and patch handling is clear and makes sense; the only problem I
see - and again, this question has probably been asked by many sourceforge
contributors before - is how to access the repository across a company
firewall.

We can only do HTTP and FTP over a Squid proxy, and that's it, no SSH and
certainly no cvs pserver on port 2401. Is there some way of tunneling cvs
over HTTP?

Probably not, so I'll either have to coax our sysadmin to open the ssh port
or do my cvs work from home, as a last resort...

Anyway, I'll brush up my results and send in patches for QNX and WinCE,
hopefully some time next week.

Going by your definition, I'm afraid that WinCE doesn't qualify as a
"decent"
platform, but alas, it's what our customers want.... And the core parts of
log4cpp
do work, after some more or less tricky hacks (the biggest problem is
exception
handling, or the lack of it). The question is whether or not you want to see
them
on the log4cpp main trunk.

I'll post more details on the WinCE thread of this list.

Regards,

Harald

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Log4cpp-devel] Porting log4cpp to QNX Neutrino 6.1

[Bastiaan B. <Bas...@li...>]

On Sat, 2002-08-24 at 12:53, Harald Wellmann wrote:
> Hello again,
> 
> the short story is: log4cpp is running on QNX 6.1 without significant 
> changes, and it passes all tests.
>

That's good to hear. Which version are you talking about? 0.2.7 or
0.3.x?
 
> The long story: you may actually be wondering what the heck QNX is, and 
> I do admit I had never heard of it until last year... It's a real-time 
> embedded operating system, and a major player in that somewhat 
> fragmented market. More details on www.qnx.com.
>

I remember them from a few years ago when they released this 1 floppy
distribution, containing a complete GUI with webbrowser. I thought that
was rather neat.
 
> QNX does have some specialities, but it is more or less POSIX compatible 
> and uses the gcc compiler suite, so you wouldn't expect any real trouble 
> compiling any GNU compatible configure-make-install package.
> 
> The biggest issue is the fact that although they use gcc, it doesn't 
> come with the GNU libstdc++ but with the Dinkumware libraries instead. I 
> can't tell which of these two "Standard" C++ Library implementations is 
> closer to the ISO C++ standard, but the fact is that most of the free 
> stuff you get is developed on GNU, and most of it (going by the dozen or 
> so packages I've tried) fails to compile against the Dinkum libs. To be 
> fair, most of the errors are std:: namespace issues, and those are 
> fairly easy to fix.
> 
> Now here's a summary of the changes I had to make:
> 
> - With the -pedantic compiler option, gcc gets so pedantic it refuses to 
> compile anything at all, so I turned it off.
> 
I believe I already turned off -pedantic for g++ 2.96 to get rid of this
endless stream of warnings about code in the iostreams lib. Maybe I
should turn it off completely by default and only enable it for testing.
 
> - Optimization -O2 produces internal compiler errors on some sources, so 
> I removed that as well.
> 
> - gcc by default simply ignores the std:: namespace (at least in 
> versions <= 2.95.3; I don't know about the most recent versions), but 
> not in the QNX variant with the Dinkum libs. In most files, I had to 
> insert "using namespace std;" or prefix a few function calls with std::.
> 

g++ < 3.0 is lax in enforcing proper namespace usage. However, 3.0 and
higher do complain, so any place where log4cpp is missing a necessary
'std::' is a bug that should be fixed. Please report any occurrences you
encounter. BTW, I prefer to avoid 'using namespace ..' because it tends
to defeat the purpose of namespaces.

> - A similar problem is the syntax of standard C header includes. On QNX, 
> you have to write #include <cstdio> instead of #include <stdio.h>, or 
> you will get lots of symbol redefinition errors.
> 

Yes, we'll have to change these as well, <cstdio> instead of <stdio.h>
is the 'proper' C++ way.
 
> - The int64 stuff in PatternLayout doesn't compile, not even with the 
> workaround, so I disabled it. Maybe there's a solution, I haven't looked 
> at it closely.

> 
> - Some of the global Makefile settings are different, of course. The 
> compiler and linker is called QCC, and you don't link any external 
> libraries. pthread_* stuff is available by default.

The compiler and linker can be changed by setting environment variables
CC and LD prior to invoking ./configure. E.g. with the bash shell:

CC=QCC LD=QCC ./configure --prefix=...

The pthread detection M4 macro has been rather quickly hacked together
to get pthread support in. We should be able check we need -lpthread or
not for pthread support. 
If you remove the '-lpthread' from 'LIBS="$LIBS -lpthread"' in
./configure, does ./configure still recognize the pthread support?
 
> 
> - libtool refused to produce libraries. I installed a newer libtool 
> version and I got archived libraries, but I haven't found out how to 
> produce shared libs yet.
> 

OK, so '--disable-shared' is recommended for now? Something to put in
the build documentation.

> 
> That's it, more or less. No big issues. I can post a patch for someone 
> to review the changes, and if the community decides to accept them into 
> the standard distribution, the final step (and for me, the most 
> difficult one) would be to set up all the autoconf and automake input.
> So far, I've simply edited the generated Makefiles, which is not the 
> proper way, I know, but I have very limited experience with the auto* 
> tools, and I find them rather hairy....

They are rather hairy indeed. When Cedric introduced me to autoconf/make
I was quite intimidated by them myself. Maybe some day some bright
individual with too much time will code something much cleaner to
replace it. But maybe not.... :-/

Good luck,

Bastiaan Bakker
LifeLine Networks bv

 
> 
> Any feedback is welcome!
> 
> Regards,
> Harald
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] Porting log4cpp to other platforms

[Bastiaan B. <Bas...@li...>]

On Sat, 2002-08-24 at 10:46, Harald Wellmann wrote:
> I'm new to this list, so let me say hello first of all.
> 
> I came across log4cpp when I was searching Sourceforge for a C++ logging 
> library. I was familiar with log4j, so I was pleased to find a more or 
> less 1:1 port of log4j in log4cpp, and personally, I prefer it over the 
> other log4c* ports, but that may be a matter of taste.
> 
> Anyway, I think that excellent work has been done on this project so 
> far, and maybe I could contribute a little to it, because log4cpp does 
> not currently support all the platforms I'm working on, e.g. QNX and 
> Windows CE.

Support for new platforms is always welcome as long as they do have a
decent C++ compiler, where decent is ambiguously defined as 'it
implements the ISO C++ language features I like to use'. E.g. it has to
support namespaces and have a recent STL implementation. 
 
> 
> This message is just a general question about the best way to contribute 
> to log4cpp development and to add support for new platforms without 
> interfering with any upcoming releases and, hopefully, without 
> introducing new bugs ;-)
> 
> If this has been asked and answered before, please send me a link to the 
> appropriate place.

Heh, you got me there. I have answered similar questions before but
never have taken the time to add a section the documentation on how to
contribute to log4cpp. 
Well, basically the procedure is like this:
* Announce on this list that you want to port platform X or implement
feature Y. This will help avoid multiple people doing the same work and
allows for constructive feedback.
* check out the log4cpp HEAD revision from CVS.If you absolutely cannot
work with CVS for some reason, take the latest 'log4cpp development' tar
ball and work against that. 
* work on the code until your happy with the result (and you feel other
s will be happy with it too). Using the default coding style (= Java
style) and documenting your changes in the ChangeLog will help to keep
me happy :-) 
* cvs update and check whether everything still works.
* create a patch file with 'cvs diff -uNr' or diff against a pristine
source tree if you used a tar ball.
* send in the patch. If it's large and/or unlikely to be merged in the
main tree soon, use the patch tracker provided by the SourceForge
project page. Else you can send it to the mailing list. 

Of course feel free to mail the list if you have any questions or
remarks about log4cpp development.

Generally I invite regular contributors to become a project member so
they can commit directly to CVS. Since log4cpp is a small project this
rather unregulated style has worked without problems sofar.
    
> 
> I'm going to post two separate messages with my results and ideas so far 
> for QNX and CE, assuming that different audiences will be interested in
> these discussion threads.

> 
> Maybe someone else has started work on these platforms already. In that 
> case, of course, I'd like to hook up with them.
> 

I haved heard yet of other people using log4cpp on QNX or CE, but that
does not mean there aren't any....


Regards,

Bastiaan Bakker
LifeLine Networks bv

> Regards,
> Harald
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Configuration file

[Slimane A. <sa...@ge...>]

Hi all,

I'm new to log4cpp and I need some help to use a configuration file 
(xml or other format). 
Can someone give me an example of file. 

Thanks 
 


--------------------------------------------------
Slimane AMAR         Mail: sa...@ge...
GENIGRAPH            URL : http://www.genigraph.fr
104, rue Castagnary  Tel : +33 01 45 33 64 63
F-75015 PARIS FRANCE Fax : +33 01 45 33 89 63
--------------------------------------------------

[Log4cpp-devel] Porting log4cpp to Windows CE 3.0

[Harald W. <Har...@gm...>]

And finally: Windows CE 3.0, with Embedded Visual C++ 3.0 (eVC++).
Now that's a hard one...

I haven't hacked my way through it yet, essentially you just have to 
work around all the things that WinCE doesn't support, and the most 
difficult question is how to integrate the changes into the standard 
distribution. This will definitely require a lot of new HAVE_SOMETHING
macros for autoconf.

Of course, the first point to decide is whether or not support for such 
a limited platform should be added at all. If the log4cpp community 
don't want to uglify the code base by lots of new configuration 
switches, I could always go and create a log4wince project in 
Sourceforge, or worst of all, just do it for myself....


Special "features" of WinCE:
- no iostream
- no STL
- no exceptions
- no getenv


The biggest trouble is missing stream support. Does anyone know an open 
source iostream implementation that compiles on WinCE out of the box? I 
tried STLport and gave up on it; there is no automatic configuration and 
  little documentation. Allegedly it works on CE, but I have not clue 
how to set it up.

So I assume the "easiest" way would be to rewrite all iostream dependent 
parts of log4cpp in terms of traditional stdio.h functions.

You definitely need a HAVE_IOSTREAM macro to disable all iostream code 
on WinCE (or other platforms that don't support it). But then you 
probably also need a HAVE_STDIO macro to enable the parts using stdio.h, 
because when you have streams, you probably don't want to be bothered 
with alternative implementations that would just serve to increase your 
library size.

I'm not an autoconf expert, but we're really looking at two different 
things here. When we don't have iostream.h, we can't use it, but even 
when we have stdio.h, we may decide not to use it. Maybe this shoulf be 
a command line option --with-stdio for configure, which defaults to no.

Where streams occur as method parameters, we'd have to add equivalent 
methods using FILE* parameters, e.g.

class Properties
{
#if LOG4CPP_HAVE_IOSTREAM
         virtual void load(std::istream& in);
         virtual void save(std::ostream& out);
#endif
#if LOG4CPP_HAVE_STDIO
         virtual void load(FILE* in);
         virtual void save(FILE* out);
#endif
};


What about methods using streams internally only? Should we _add_ an 
alternative stdio based implementation, or simply _replace_ the current 
iostream based implementation by stdio stuff, possibly causing extreme 
grief to all C++ purists?

STL shouldn't be too difficult. I have had good results with the STL for 
CE port from http://users.libero.it/g.govi/index.html so far, at least 
with the container classes. I haven't tried the string class yet...

Disabling exceptions - this is similar to the stream issue. First of 
all, would you throw(!) them out completely, or make them conditional 
and configurable? What's the alternative - return codes or errno/errstr 
or something else?

getenv - well, that's easy. It's only used in Properties.cpp, and we can 
simply make it conditional with HAVE_GETENV. No replacement.

Finally, which Appenders should be supported? To start with, I'd be 
fully satisfied with the Win32DebugAppender, but we'd have to make it 
thread-safe, because OutputDebugString isn't.

Please post your opinions.

Regards,
Harald