Re: [Gnash-dev] Incorrect message when AGG is old...

[Alfred M. Szmidt]

   >    s> Anyway, still interested in attempts to bild with an older AGG
   >    s> ...
   > 
   >    As long as the particular 2.4 version contains the
   >    render_scanlines_compound_layered template/class (normally
   >    defined in agg_renderer_scanline.h) the AGG version should be
   >    OK, so you could check for that if that's possible.
   > 
   >    Not sure if the compatibility layer is still worth it since
   >    2.5 is now the current version.
   > 
   > It should be very trivial to do such a check:
   > 
   > AC_LANG([C++])
   > AC_CHECK_LIB([some_crucial_function_in_libagg], [libagg], [],
   >   AC_MSG_ERROR([you are missing libagg, please install it]))
   > AC_CHECK_FUNC([render_scanlines_compound_layered], [],
   >   AC_MSG_ERROR([you are using a version of libagg that does not work with 
gnash]))
   > 
   > I don't know if this will work with C++'s template system though.

   Hardly, as the macro would try to link, w/out including any header.

Which doesn't matter, autoconf uses a dummy prototype of the function
when testing if a symbol exists in a library. 

Autoconf compiles a program that looks similar to this:

| char gh_eval_str ();
| char (*f) () = gh_eval_str;
|
| int
| main ()
| {
|   return f != gh_eval_str;
|   return 0;
| }

And then tries to compile it and link it against a library, say
-lguile:

~ $ gcc f.c -lguile
~ $ 

If the symbol does not exist in the library, we would get an error:

~ $ gcc f.c -lmp
/tmp/ccEUSPcX.o: In function `main':f.c:(.text+0x22): undefined reference to 
`gh_eval_str'
/tmp/ccEUSPcX.o:(.data+0x0): undefined reference to `gh_eval_str'
collect2: ld returned 1 exit status
~ $