On Mon, 2 Apr 2007, Sheri wrote:
> I did it both ways, first with addition of pcre.def file, then with all
> three def files present in the RC3 dir. Each time started fresh. The end
> result each way is that pcretest still has all those memory
> disagreements. So the mere presence of the def files has no effect at
> all. Make is not using them per my console output (whereas it did in 7.0).
I see that in the 7.0 Makefile.in, we have this:
.libs/@WIN_PREFIX@??? : libpcre.la
$(CC) $(CFLAGS) -shared -o $@ \
-Wl,--whole-archive .libs/libpcre.a \
-Wl,--out-implib,.libs/libpcre.dll.a \
-Wl,--output-def,.libs/@WIN_PREFIX@??? \
-Wl,--export-all-symbols \
-Wl,--no-whole-archive
sed -e "s#dlname=''#dlname='../bin/@WIN_PREFIX@???'#" \
-e "s#library_names=''#library_names='libpcre.dll.a'#" \
< .libs/libpcre.lai > .libs/libpcre.lai.tmp && \
mv -f .libs/libpcre.lai.tmp .libs/libpcre.lai
sed -e "s#dlname=''#dlname='../bin/@WIN_PREFIX@???'#" \
-e "s#library_names=''#library_names='libpcre.dll.a'#" \
< libpcre.la > libpcre.la.tmp && \
mv -f libpcre.la.tmp libpcre.la
and I notice stuff like --outpuf-def and --export-all-symbols which
could be relevant. In 7.1, the Makefile is created dynamically, so I
can't see what happens on Windows. Could you send me the Makefile that
you end up with? Maybe some of these flags are getting lost. Maybe
there's something we can tweak...
> It sounds like it will be awhile yet before the Cmake approach supports
> shared dlls for Windows. I hope (but never expect) anything new to go
> smoothly.
Me too. I knew this would be bumpy, but I hope for more smoothness
later. It was around Christmas when this exercise started - I had hoped
to get 7.1 out by Easter... getting tight now.
On Mon, 2 Apr 2007, Bob Rossi wrote:
> Just curious, what environment are you in that is causing you all of
> this trouble? (compiler, shell, ...)
If you can help, Bob (as someone who knows an immeasurable about more
than I do about Windows), I'd be most grateful!
Folks, I just about have -RC4 ready to go, apart from this problem of
Sheri's. If we can fix that I think we could go with it as a 7.1 release
after a short test period, and let Daniel's subsequent upgrades to cmake
come later. I want to get 7.1 out as there are now some bug fixes in the
code itself.
Philip
--
Philip Hazel, University of Cambridge Computing Service.
