Re: Problems building Maildrop on a Macintosh

Sam Varshavchik <[email protected]> Fri, 30 Nov 2018 22:33:14 -0500
Newsgroups	gmane.mail.maildrop
Message-ID	<[email protected]>
Larry Stone writes:

> >
> > On Nov 30, 2018, at 4:35 PM, Sam Varshavchik <[email protected]> wrote:
> >
> > Larry Stone writes:
> >
> >> checking for pcre/pcre.h... no
> >> configure: error: pcre.h not found - install PCRE from www.pcre.org
> >> (/usr/local/include/pcre.h exists
> >> A search turned up lots of other incidents of pcre.h not found but none  
> with a solution that seems to fit me)
> >
> > Just because it exists there doesn't mean that the compiler knows to  
> search for it by default. That's one possible explanation.
>
> Well, configure —help tells me the default include directory is  
> PREFIX/include and the default for PREFIX is /usr/local so it should be  
> seeing the pcre.h in /usr/local/include. But just to be sure, I tried:
> ./configure --prefix=/usr/local --includedir=/usr/local/include --enable-utf
> and got the same pcre.h not found.

These options specify where the application will install various kinds of  
its files, if the application had any. So, if maildrop installs any header  
files, that's where they would go.

maildrop does not install any header files, so this option has no effect.

This has nothing to do with specifying where the compiler searches for  
header files, when compiling code.

> Nothing I can see in the log gives me any hint of where it’s looking and not  
> finding pcre.h.
>
> configure:12065: checking pcre.h usability
> configure:12065: gcc -c -g -O2  conftest.c >&5
> conftest.c:54:10: fatal error: 'pcre.h' file not found
> #include <pcre.h>
>          ^

That's pretty much cut and dry. The compiler did not find the pcre.h header  
file. Full stop.

A little bit of Googling finds some useful information here:

https://stackoverflow.com/questions/344317/where-does-gcc-look-for-c-and-c-header-files

You will likely find that your gcc oddly does not search /usr/local/include  
by default.

This is fairly easy to remedy, but it was necessary to confirm this, first;  
that this was your problem, by checking config.log. Quite often the test  
compilation fails for other reasons when searching for a particular header  
file; failing with a claim that it's not found when the actual reason was  
something else.

But the compiler definitely didn't find it. Which simply means your compiler  
does not search /usr/local/include, by default. As simple as that.

So, you will need to add additional compilation options. This is done by  
using CPPFLAGS and LDFLAGS:

./configure [any other options] CPPFLAGS='-I/usr/local/include'

This writes a Makefile that passes the

-I/usr/local/include

option to gcc when compiling code, telling the compiler to add this  
directory to the list where header files are searched.

It's fairly likely that you will have a similar problem with linking  
libraries from /usr/local/lib. If the compiler doesn't use  
/usr/local/include by default, the linker probably doesn't search  
/usr/local/lib either. So:

LDFLAGS='-L/usr/local/lib'

This will search the directory when linking. But the linked executable will  
also need to be able to load the library from that directory when executed.  
This will also likely have the same problem.

You will need to do some research to figure out which additional options add  
a directory to the shared library search directory, at runtime. On Linux  
it's '-rpath <directory>' that needs to be passed to the linker, and gcc  
doesn't have a native forwarding option, so the -Wl passthrough option is  
needed:

LDFLAGS='-L/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib'

_______________________________________________
Courier-maildrop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/courier-maildrop
signature.asc (application/pgp-signature, 801 B)