From: Dean E. <dea...@gm...> - 2011-02-27 03:15:38
|
I'm building swig 2.0.2 on linux and would like to enable pcre support, but the binary will be distributed to a number of in-house systems which cannot be guaranteed to have the pcre lib installed on them. To get around that I would like to have swig link to the static version of libpcre rather than the shared lib, but I don't see any option for that in ./configure. I tried setting the PCRE_LIBS envariable to /usr/lib64/libpcre.a before doing the configure and make, but the resulting swig binary was still linked to the shared lib. Any ideas on how to achieve what my goal? Thanx. -- -deane |
From: Vadim Z. <vz...@ze...> - 2011-02-27 12:12:18
|
On Sat, 26 Feb 2011 19:15:30 -0800 Dean Edmonds <dea...@gm...> wrote: DE> I'm building swig 2.0.2 on linux and would like to enable pcre DE> support, but the binary will be distributed to a number of in-house DE> systems which cannot be guaranteed to have the pcre lib installed on DE> them. To get around that I would like to have swig link to the static DE> version of libpcre rather than the shared lib, but I don't see any DE> option for that in ./configure. DE> DE> I tried setting the PCRE_LIBS envariable to /usr/lib64/libpcre.a DE> before doing the configure and make, but the resulting swig binary was DE> still linked to the shared lib. DE> DE> Any ideas on how to achieve what my goal? Hello, Looking at Tools/config/ax_path_generic.m4 PCRE_LIBS seems to be indeed ignored. AFAICS the only workaround would be to create your own shell script which would output the wanted values for it, e.g. (this is untested) $ cat > ~/static-pcre-config #!/bin/sh usage="Usage: static-pcre-config --{libs,cflags}" if [ $# -neq 1 ]; then echo "$usage" 1>&2 exit 1 fi case $1 in --cflags) ;; --libs) echo "/usr/lib64/libpcre.a" ;; *) echo "$usage" 1>&2 exit 1 ;; esac ^D $ swig/configure PCRE_CONFIG=$HOME/static-pcre-config Or maybe you could just edit the makefile generated by configure if it's a one off build. Regards, VZ |
From: William S F. <ws...@fu...> - 2011-02-27 16:09:41
|
On 27/02/11 11:38, Vadim Zeitlin wrote: > On Sat, 26 Feb 2011 19:15:30 -0800 Dean Edmonds<dea...@gm...> wrote: > > DE> I'm building swig 2.0.2 on linux and would like to enable pcre > DE> support, but the binary will be distributed to a number of in-house > DE> systems which cannot be guaranteed to have the pcre lib installed on > DE> them. To get around that I would like to have swig link to the static > DE> version of libpcre rather than the shared lib, but I don't see any > DE> option for that in ./configure. > DE> > DE> I tried setting the PCRE_LIBS envariable to /usr/lib64/libpcre.a > DE> before doing the configure and make, but the resulting swig binary was > DE> still linked to the shared lib. > DE> > DE> Any ideas on how to achieve what my goal? > > Hello, > > Looking at Tools/config/ax_path_generic.m4 PCRE_LIBS seems to be indeed > ignored. AFAICS the only workaround would be to create your own shell > script which would output the wanted values for it, e.g. (this is untested) > > $ cat> ~/static-pcre-config > #!/bin/sh > usage="Usage: static-pcre-config --{libs,cflags}" > if [ $# -neq 1 ]; then > echo "$usage" 1>&2 > exit 1 > fi > > case $1 in > --cflags) > ;; > --libs) > echo "/usr/lib64/libpcre.a" > ;; > *) > echo "$usage" 1>&2 > exit 1 > ;; > esac > ^D > $ swig/configure PCRE_CONFIG=$HOME/static-pcre-config > > Or maybe you could just edit the makefile generated by configure if it's a > one off build. > Vadim, any chance we can fix the autotools to allow this easily? Can ax_path_generic.m4 be fixed for future releases? Dean, another alternative, is to rebuild pcre to generate just the static libs. If you put the pcre tarball in the top level SWIG directory, this can be done very easily using a helper script in Tools/pcre-build.sh and hopefully the help is enough to explain all: ~/swig/swig-2.0.2$ Tools/pcre-build.sh --help Helper script to build PCRE as a static library from a tarball just for use during the SWIG build. It does not install PCRE for global use on your system. Usage: pcre-build.sh [--help] [args] args - optional additional arguments passed on to the PCRE configure script (leave out unless you are an expert at configure) --help - Display this help information. Instructions: - Download the latest PCRE source tarball from http://www.pcre.org and place in the directory that you will configure and build SWIG. - Run this script in the same directory that you intend to configure and build SWIG in. - Afterwards run the SWIG configure scrip which will then find and use the PCRE static libraries in the pcre/pcre-swig-install subdirectory. Another alternative is to force gcc/g++, assuming you are using this compiler, to use the static libs by setting -static in CXXFLAGS. William |
From: Dean E. <dea...@gm...> - 2011-02-27 18:43:03
|
On Sun, Feb 27, 2011 at 08:09, William S Fulton <ws...@fu...> wrote: > On 27/02/11 11:38, Vadim Zeitlin wrote: >> On Sat, 26 Feb 2011 19:15:30 -0800 Dean Edmonds<dea...@gm...> wrote: >> >> DE> I'm building swig 2.0.2 on linux and would like to enable pcre >> DE> support, but the binary will be distributed to a number of in-house >> DE> systems which cannot be guaranteed to have the pcre lib installed on >> DE> them. To get around that I would like to have swig link to the static >> DE> version of libpcre rather than the shared lib, but I don't see any >> DE> option for that in ./configure. [...] >> Or maybe you could just edit the makefile generated by configure if it's a >> one off build. That's what I ended up doing as it seemed the simplest and least disruptive to my system configuration. > Another alternative is to force gcc/g++, assuming you are using this > compiler, to use the static libs by setting -static in CXXFLAGS. If you're talking about setting CXXFLAGS for the swig configure and build, that didn't work as it meant that the link was looking for static versions of libc, etc, as well, which aren't installed. And I'd rather not bloat the binary by using static versions of them. Thanx for your help everyone. -- -deane |
From: Vadim Z. <vz...@ze...> - 2011-03-06 17:41:11
|
On Sun, 27 Feb 2011 16:09:30 +0000 William S Fulton <ws...@fu...> wrote: WSF> Vadim, any chance we can fix the autotools to allow this easily? Can WSF> ax_path_generic.m4 be fixed for future releases? It's simple to change the macro to allow these variables override its results, of course, and I've opened a ticket with the patch doing this: https://savannah.gnu.org/patch/index.php?7490 But I don't know if it's going to be accepted into the official version nor if SWIG wants to use the modified version. If you don't think this is going to be a problem I can commit this patch into SWIG svn, of course, just please let me know. Regards, VZ |
From: William S F. <ws...@fu...> - 2011-03-09 20:40:54
|
On 06/03/11 17:40, Vadim Zeitlin wrote: > On Sun, 27 Feb 2011 16:09:30 +0000 William S Fulton<ws...@fu...> wrote: > > WSF> Vadim, any chance we can fix the autotools to allow this easily? Can > WSF> ax_path_generic.m4 be fixed for future releases? > > It's simple to change the macro to allow these variables override its > results, of course, and I've opened a ticket with the patch doing this: > > https://savannah.gnu.org/patch/index.php?7490 > > But I don't know if it's going to be accepted into the official version nor > if SWIG wants to use the modified version. If you don't think this is going > to be a problem I can commit this patch into SWIG svn, of course, just > please let me know. > Please commit to the SWIG svn repository and then commit the official version if it is accepted and is different in any way. Thanks William |
From: Vadim Z. <vz...@ze...> - 2011-03-20 23:28:29
|
On Wed, 09 Mar 2011 20:40:13 +0000 William S Fulton <ws...@fu...> wrote: WSF> On 06/03/11 17:40, Vadim Zeitlin wrote: WSF> > On Sun, 27 Feb 2011 16:09:30 +0000 William S Fulton<ws...@fu...> wrote: WSF> > WSF> > WSF> Vadim, any chance we can fix the autotools to allow this easily? Can WSF> > WSF> ax_path_generic.m4 be fixed for future releases? WSF> > WSF> > It's simple to change the macro to allow these variables override its WSF> > results, of course, and I've opened a ticket with the patch doing this: WSF> > WSF> > https://savannah.gnu.org/patch/index.php?7490 WSF> > WSF> > But I don't know if it's going to be accepted into the official version nor WSF> > if SWIG wants to use the modified version. If you don't think this is going WSF> > to be a problem I can commit this patch into SWIG svn, of course, just WSF> > please let me know. WSF> > WSF> Please commit to the SWIG svn repository and then commit the official WSF> version if it is accepted and is different in any way. Sorry for the delay but finally it was better this way because the patch to autoconf archive was applied with minor changes so thanks to my farsighted laziness I was able to directly apply the final official version instead of applying mine first and then correcting it. Anyhow, setting PCRE_LIBS to use the static build of PCRE works for me now and I added a note about it to the README file. I wanted to modify the Windows build instructions too but they don't speak about PCRE at all and as I've never built SWIG under Windows so far (I cross-compile it from Linux) I didn't want to write them blindly. Please let me know if I forgot to update anything else, VZ |