PCRE package for consideration

[Charles Wilson]

Gerrit P. Haase wrote:

> Hallo,
> 
> today is not my day...
> cygpcreposix-0.dll is linked against /bin/cygpcre.dll which is the
> old, installed pcre DLL, it is weird, libtool should handle this
> without fault, also the executables are linked against the lib in
> /bin, very strange, I have no idea how to fix it.  I removed the old
> pcre installation for now and it seems to work then (well, kind of,
> grep.exe is linked against cygpcre.dll and the script requires
> grep.exe ..., so just remove everything from pcre besides the DLL).

I don't see this behavior during build phase. Here's the link command 
for cygpcreposix:

/bin/bash ./libtool --mode=link gcc -O2 -I. -I/tmp/pcre/pcre-4.2 -rpath 
/usr/lib -L. -lpcre -no-undefined -version-info \
         '0:0:0' -o libpcreposix.la pcreposix.lo

Now, this is not correct: -L. -lpcre doesn't help. However, the actual 
gcc command generated by libtool is

gcc -shared  .libs/pcreposix.o  -L/tmp/pcre/pcre-4.2/.build 
/tmp/pcre/pcre-4.2/.build/.libs/libpcre.dll.a  -o 
.libs/cygpcreposix-0.dll -Wl,--image-base=0x10000000 
-Wl,--out-implib,.libs/libpcreposix.dll.a

Which is just dandy.  Further, pcretest and pcregrep:

/bin/bash ./libtool --mode=link gcc -O2 -I. -I/tmp/pcre/pcre-4.2   -o 
pcretest.exe  pcretest.o \
         -lpcre libpcreposix.la

I don't like the "bare" -lpcre, but here's the actual link command 
generated by libtool:

gcc -O2 -I. -I/tmp/pcre/pcre-4.2 -o .libs/pcretest.exe pcretest.o 
./.libs/libpcreposix.dll.a -L/tmp/pcre/pcre-4.2/.build 
/tmp/pcre/pcre-4.2/.build/.libs/libpcre.dll.a

Which, again, is just fine.  Ditto pcregrep:

/bin/bash ./libtool --mode=link gcc -O2 -I. -I/tmp/pcre/pcre-4.2 -o 
pcregrep.exe pcregrep.o -lpcre
gcc -O2 -I. -I/tmp/pcre/pcre-4.2 -o .libs/pcregrep.exe pcregrep.o 
/tmp/pcre/pcre-4.2/.build/.libs/libpcre.dll.a

It sure looks to me as if the link is truly against the local, new, 
libpcre import library.  Now, you do know that DLLs are resolved at 
runtime, right?  'cygcheck foo.exe' can give various results, depending 
on what DLLs are in the same directory with foo.exe, and the value of 
$PATH...

Now, the "bad" (but apparently harmless) ./libtool -mode=link commands 
above should probably be modified somewhat...

Ah HA!  It ain't harmless, because the problem actually occurs during 
the 'make install DESTDIR=' phase, not the build phase!

libtool has special hacks, so that when it's linking a .la file and SEES 
another .la file in the dependency list, it "knows" to do special things 
when it relinks.  But, if you put -l<the first lib> and not lib<the 
first lib>.la in the dep list, those hacks don't get activated.

So, with the attached patch -- applied on top of Gerritt's patches -- 
you get the following relink command during make install DESTDIR=:

(cd /tmp/pcre/pcre-4.2/.build; /bin/bash ./libtool --mode=relink gcc -O2 
-I. -I/tmp/pcre/pcre-4.2 -rpath /usr/lib libpcre.la -no-undefined 
-version-info 0:0:0 -o libpcreposix.la pcreposix.lo -inst-prefix-dir 
/tmp/pcre/pcre-4.2/.inst)

Note the '-inst-prefix-dir /tmp/.....' stuff?  That's the "libtool 
understands DESTDIR" hack. It leads to the following actual link command:

gcc -shared  .libs/pcreposix.o  -L/usr/lib 
-L/tmp/pcre/pcre-4.2/.inst/usr/lib -lpcre  -o .libs/cygpcreposix-0.dll 
-Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libpcreposix.dll.a

See?  "-L/tmp/pcre/pcre-4.2/.inst/usr/lib -lpcre" is exactly the correct 
relink.

In the future, please do not blindly assume that libtool-1.5 is broken 
because it doesn't act like you think it should on your very first try. 
  It didn't go thru two years of beta testing for nothing...

The mistake corrected in the patch below REALLY IS user error -- and has 
been for a long time; it's not a new "wrinkle" dreamed up by 1.5. 
libtool libraries should NEVER be passed to libtool by "-lfoo" names; 
whenever possible they should be specifies as "libfoo.la".

--Chuck


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile.in.diff
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20030429/5c89fa48/attachment.ksh>