Patch updated with soname detection.

(file #19919)

This does not work either:

search.o: In function `load_pcre':
/home/rrt/repo/grep-dlopen-pcre/src/search.c:71: undefined reference to `dl_pcre_compile'
/home/rrt/repo/grep-dlopen-pcre/src/search.c:71: undefined reference to `dl_pcre_study'
/home/rrt/repo/grep-dlopen-pcre/src/search.c:71: undefined reference to `dl_pcre_exec'
/home/rrt/repo/grep-dlopen-pcre/src/search.c:71: undefined reference to `dl_pcre_maketables'
search.o: In function `Pexecute':
/home/rrt/repo/grep-dlopen-pcre/src/search.c:812: undefined reference to `dl_pcre_exec'
search.o: In function `Pcompile':
/home/rrt/repo/grep-dlopen-pcre/src/search.c:762: undefined reference to `dl_pcre_compile'
/home/rrt/repo/grep-dlopen-pcre/src/search.c:762: undefined reference to `dl_pcre_maketables'
/home/rrt/repo/grep-dlopen-pcre/src/search.c:766: undefined reference to `dl_pcre_study'
collect2: ld returned 1 exit status

This I do understand, because now dl_pcre_exec &c. is never actually defined. I can't see how your solution is going to work without defining the variable, copying out the type...

I'm aware that typeof is non-ISO (but it is supported by at least Metrowerks as well as GCC), hence my test in configure.ac. I propose to be happy to fail on those systems that support dlopen but don't have a compiler with typeof.

However, another reason was that I couldn't think of another way of doing it without writing all the types out again.

So, I tried your suggestion, and I get:

search.c:71: error: lvalue required as left operand of assignment
search.c:72: error: lvalue required as left operand of assignment
search.c:73: error: lvalue required as left operand of assignment
search.c:74: error: lvalue required as left operand of assignment

I confess I do not understand this error, I thought your idea would work (though unfortunately it was not susceptible to a macro, as mine is).

Thanks for the outline, I'll attempt to fill in the blanks.

yes, that configure.ac check looks correct, but that is certainly not in any of the posted patches so far.

ldd is a host test, so that wouldnt work (i.e. it implicitly invokes the host ldso to find things out).  you could use `readelf -d` and assume ELF format, but that seems like it'll break on non-ELF systems (OS X comes to mind).

a --with-pcre-soname=SONAME option would push the issue onto distro packagers who would probably be annoyed as then they'll have to implement the things i'm talking about, but would provide a way of grep washing its hand of possibly buggy code.

so if you wanted, you could do something like:
AC_ARG_WITH([pcre-soname], [...], with_pcre_soname=$withval, [
AS_IF([test "$ac_cv_lib_dl_dlopen" = "yes"], [
<link simple app against -lpcre>
with_pcre_soname=`readelf -d <simple app> 2>/dev/null | grep NEEDED.*libpcre | awk '{print $NF}'
if test -z "$with_pcre_soname" ; then
    AC_MSG_ERROR([unable to detect libpcre SONAME; please use --with-pcre-soname])
fi
])])

this would satisfy most distro people while providing a fallback for the non-ELF freaks

I believe the configure.ac test is correct. Here is the code:

# support for dlopen
AC_ARG_WITH(dl,
        AC_HELP_STRING([--without-dl], [Don't try to use libdl]))
if test "$with_dl" != "no"; then
    AC_CHECK_LIB([dl], [dlopen])
    AC_C_TYPEOF
fi
AM_CONDITIONAL(USING_LIBDL, [test x$ac_cv_lib_dl_dlopen = xyes])

Here, USING_LIBDL is only set if ac_cv_lib_dl_dlopen is set to yes, which itself can only happen if --without-dl is not passed to configure AND libdl is found. Is there something wrong with this logic?

As for dlopening the library, is there a simple way to find out which library is picked up by a link? I suppose I can compile a test, link against the file, then ldd it to get the SONAME?

I am tempted, in any case, to do something simpler: dlopen("libpcre.so"), but allow the soname to be specified by a configure-time parameter.

The two stools I am trying to balance between here are on the one hand you (reasonably) want me to provide something that works on any system, while Paolo says I can't use libltdl (which would otherwise simplify matters, I think). I want to avoid reimplementing any significant functionality which I would otherwise get from libtool, libltdl, or similar.

The reason I think my suggestion is reasonable is that there are, I think, two main classes of users I'm trying to cater to:

1. Those who build grep on their own systems. They will have the development sources of PCRE installed, so a default of libpcre.so will work. Those on systems with different naming conventions can give a --with-pcre-soname= argument.

2. Those who are packaging grep. They won't mind giving the --configure argument.

Of course, if there's a really simple way portably to obtain the correct soname, I'm all for it.

I have fixed configure.ac to check the actual result of the test.

For dlopening libpcre, I have changed the name to libpcre.so.3. This is better, because it ensures the correct version of the API, and works when the development sources are absent.

What else is needed to make this patch fly?

(file #19905)

Attached, an updated version of the patch that uses dlopen if available and desired, and cleans up the code somewhat, in
particular making the use of dlopen simpler, and adding support for all cases to configure.ac and src/Makefile.am.

(file #19900)

As I said above, I need to know which dynamic loading mechanism to use first.

This patch dlopens libpcre, allowing PCRE support on systems with grep in /bin and libpcre in /usr/lib. Patch is against current git head.

Still to be finalised: the exact dlopening mechanism preferred. Currently uses dlopen directly.