Menu
▾
▴
log4cpp-devel
|
From: Harald W. <Har...@gm...> - 2002-08-24 08:43:06
|
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. 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. 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. Regards, Harald |
|
From: Harald W. <Har...@gm...> - 2002-08-24 10:50:06
|
Hello again, the short story is: log4cpp is running on QNX 6.1 without significant changes, and it passes all tests. 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. 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. - 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::. - 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. - 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. - 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. 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.... Any feedback is welcome! Regards, Harald |
|
From: Bastiaan B. <Bas...@li...> - 2002-09-03 16:34:58
|
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 |
|
From: Bastiaan B. <Bas...@li...> - 2002-09-03 16:19:13
|
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
|
Thanks for helping keep SourceForge clean.
X