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