Static linking against libpcre?

[nathansobo]

Hi Geoff,

We're hoping to embed ag into an application (as it's own binary, that we interact with as a child process when needed). We've noticed it depends on the pcre dynamic library being available on the system. Presumably it's possible to statically link against libpcre.a instead? I'm completely unversed in GNU autotools, but I started reading about it last night. If it's a simple change to statically link, maybe you could just tell me what to change? But otherwise I'll keep studying :-). Are there any other obstacles you can think of that would preclude redistributing a binary that runs on modern versions of OS X? Thanks!

[ggreer]

Assuming you have a libpcre.a somewhere in your LDPATH, shouldn't CFLAGS="-static" ./build.sh do the trick? (Be sure to make clean before this.)

[nathansobo]

CFLAGS="-static" ./build.sh on OS X yields the following error:

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/nathansobo/code/the_silver_searcher':
configure: error: C compiler cannot create executables
See `config.log' for more details

The relevant section of config.log seems to be:

...
configure:2308: checking whether the C compiler works
configure:2330: gcc -static   conftest.c  >&5
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
...

This seems to be due to the fact that no static version of crt0.o is provided. From man gcc on OS X:

...
       -static
           On systems that support dynamic linking, this prevents linking with the shared libraries.  On other systems, this
           option has no effect.

           This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static.
           Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
...

So it seems as if I can't flag the entire executable to be static. I'd have to statically link only against libpcre.a, which is available in the same directory as the dynamic library so presumably on my link path.

Thanks Geoff for taking the time to respond.

[ggreer]

I assumed you were on Linux. You've reached the extent of my knowledge on this subject.

I think if you just want to link to .a files, you can add them to the gcc command. So instead of

gcc  -g -O2   -Wall -Wextra -std=c89 -D_GNU_SOURCE   -o ag src/ignore.o src/log.o src/options.o src/print.o src/search.o src/util.o src/main.o -lpcre

it would be

gcc  -g -O2   -Wall -Wextra -std=c89 -D_GNU_SOURCE   -o ag src/ignore.o src/log.o src/options.o src/print.o src/search.o src/util.o src/main.o /path/to/libpcre.a

(Scroll all the way to the end of that line to see the difference. -lpcre was replaced with /path/to/libpcre.a

[ggreer]

This isn't a bug in Ag and I can't help anymore, so I'm closing this issue.

[nathansobo]

Okay... I figured out. Here's my solution:

PCRE_LIBS="/usr/local/Cellar/pcre/8.30/lib/libpcre.a" ./build.sh

It looks like the binary is statically linked to PCRE, based on this:

otool -L ./ag 
./ag:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

And I brew uninstalled PCRE and the binary still worked. Thanks for your time!

[ggreer]

Cool beans.

[lifenjoiner]

Comment for anyone looks up ...

Came across the 'same' thing on Windows: static link pcre.

-static doesn't help.
Try add -DPCRE_STATIC to your CFLAGS. It is a trick of PCRE ;p

Read pcre.h, you will see:

#if defined(_WIN32) && !defined(PCRE_STATIC)
#  ifndef PCRE_EXP_DECL
#    define PCRE_EXP_DECL  extern __declspec(dllimport)
#  endif
#  ifdef __cplusplus
#    ifndef PCRECPP_EXP_DECL
#      define PCRECPP_EXP_DECL  extern __declspec(dllimport)
#    endif
#    ifndef PCRECPP_EXP_DEFN
#      define PCRECPP_EXP_DEFN  __declspec(dllimport)
#    endif
#  endif
#endif

/* By default, we use the standard "extern" declarations. */

#ifndef PCRE_EXP_DECL
#  ifdef __cplusplus
#    define PCRE_EXP_DECL  extern "C"
#  else
#    define PCRE_EXP_DECL  extern
#  endif
#endif