Re: [Opencxx-users] OpenC++ 2.8 is out!

[Grzegorz J. <ja...@ac...>]

Hi Yann!

Yann Dirson wrote:
> Thanks for your great work, Grzegorz !

Great things are still to come!... (OpenC++ Core Lib)

> Unfortunately, we're no out of libtool woes...
> 
> On current Debian unstable using g++ 3.3, the configure script shows a
> couple of strange things:
> 
> | checking dlfcn.h usability... yes
> | checking dlfcn.h presence... no
> | configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor!
> | configure: WARNING: dlfcn.h: proceeding with the preprocessor's result
> | configure: WARNING:     ## ------------------------------------ ##
> | configure: WARNING:     ## Report this to bug...@gn.... ##
> | configure: WARNING:     ## ------------------------------------ ##
> | checking for dlfcn.h... no
> [...]
> | checking whether to use garbage collector... no
> 
> and in the end, the shared library is named libocc.0 (note the missing .so).
> 
> Let's start with the latter since I've met him already.  Although I
> don't remember the gory details, IIRC it comes from a version mismatch
> between ltmain.sh and some other part used to produce the ./libtool
> script.
> 
> Sync'ing libtool files with the version on my system (1.5.6-2) using
> libtoolize, and subsequently regenerating all auto* stuff solves the
> problem for me.  Incidentally, it seems to solve the first issue as
> well:
> 
> | checking dlfcn.h presence... no
> | configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor!
> | configure: WARNING: dlfcn.h: proceeding with the compiler's result
> | checking for dlfcn.h... yes
> 
> I'm not sure what we can do to fix the problem for good...

The best we can do is to make 'bootstrap' fail for libtool earlier than 
1.5.6-2 on Debian (I don't know how it works on other Linux distros).

> Now for the gc issue.  In configure.in the code seems to assume
> $enable_gc is empty if no --*able-gc flag was passed.  However, the
> generated configure script starts by setting it to "no" if it was
> empty.  This seems to explain that the gc is never selected.  

Oouuuu....

> Adding
> "enable_gc=yes" before AC_ARG_ENABLE fixes the problem.

Cool, but this means gc test were fakes :-(

> But now, or if I just force it to yes using --enable-gc I get:
> 
> | checking whether to use garbage collector... yes
> | checking whether -lgc provides GC_malloc... yes
> | checking gc.h usability... no
> | checking gc.h presence... no
> | checking for gc.h... no
> | configure: error: gc.h not found; set up paths or --disable-gc
> 
> It is apparently not looking for <gc/gc.h>, which would have allowed
> to find it.  

I think it should look for <gc.h>, not <gc/gc.h> (and it does, 
configure.in:188). Why do you think it should be <gc/gc.h> ???

> OTOH, it does not seem to be used, so this particular
> test can possibly be dropped.

I am not sure I understand. Do you mean that testing for <gc/gc_cpp.h> 
is enough? If this is really the case, I agree.

> Any objections to these changes ?

No. Could you apply?

Thanks!
Grzegorz