Bob Rossi wrote:
> On Sat, Apr 14, 2007 at 10:40:49AM -0400, Sheri wrote:
>
>> I don't really care too much if the coff functionality is not made
>> available to everyone, though I do not want to have to use the Microsoft
>> toolchain myself to get it. Windres is part of the Gnu toolchain. If you
>> can provide a makefile.in that allows me to add my own coff file(s),
>> I'll be happy. Or if turns out to be easily added when/if
>> --alternate-win32-dll-names is done it is something that Windows users
>> will appreciate (and would certainly be nice for me if the version
>> numbers and strings came from build variables). I know that Philip said
>> he did not want 7.1 to remove functionality for Windows users. He also
>> didn't want to wait to see how CMake was going to pan out in this
>> regard. Since I've discovered that I can use those few extra commands to
>> get what I want in 7.1, its really the rest of the Windows user
>> community that's affected. So my vote would be, add a configure option
>> that creates shared libraries that are functionally compatible with 7.0.
>> If easily done, creation and linking of a coff file.
>>
>>>> What does everyone think?
>>>>
>
> Hi Sheri,
>
> This is sort of what I'm thinking is the best alternative as well. That
> would provide you with a pcre.dll filename. It could also provide you
> with the coff information.
>
> If you want to be completely backwards compatible, we'd have to stop
> creating 2 dll's, one for pcre and one for pcreposix. I don't think this
> would be as trivial to duplicate.
>
> Does anyone think we should combine pcre.dll and pcreposix.dll on
> windows and pcre.so and pcreposix.so on unix?
>
> Thanks,
> Bob Rossi
>
>
Hi again Bob,
I would point out that just running those few extra commands (which
would be associated only with the the new configure option and should
not affect anybody else) *does* make completely backward compatible
(shared c) libraries (at least pcre.dll).
> $ rm -f libpcre.la
>
> $ /bin/sh ./libtool --mode=link gcc -export-symbols-regex '^[^_]' -I.
> -I. -rpath /usr/local/lib -version-info \
> '0:1:0' -o libpcre.la pcre_chartables.lo pcre_compile.lo
> pcre_config.lo pcre_dfa_exec.lo pcre_exec.lo pcre_fullinfo.lo
> pcre_get.lo pcre_globals.lo pcre_info.lo pcre_maketables.lo
> pcre_newline.lo pcre_ord2utf8.lo pcre_refcount.lo pcre_study.lo
> pcre_tables.lo pcre_try_flipped.lo pcre_ucp_searchfuncs.lo
> pcre_valid_utf8.lo pcre_version.lo pcre_xclass.lo pcreposix.lo
>
> $ gcc -O3 -s -shared -o .libs/pcre.dll ../pcre.coff \
> -Wl,--whole-archive .libs/libpcre.a \
> -Wl,--out-implib,.libs/libpcre.dll.a \
> -Wl,--output-def,.libs/pcre.dll-def \
> -Wl,--export-all-symbols \
> -Wl,--no-whole-archive
>
> # ========don't know what this part is for but it doesn't alter the
> pcre.dll file========
> $ sed -e "s#dlname=''#dlname='../bin/pcre.dll'#" \
> -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/pcre.dll'#" \
> -e "s#library_names=''#library_names='libpcre.dll.a'#" \
> < libpcre.la > libpcre.la.tmp && \
> mv -f libpcre.la.tmp libpcre.la
notice the pcreposix.lo at the end of libtool command.
I never tried to make a functionally equivalent pcreposix.dll using 7.1
-- there are a few more lines in the old Makefile.in that I think would
do it tho).
I have no interest in the cpp library. AFAIC anyone who wants to use the
cpp library should not use the new --alternate-win32-dll-names option
if there is currently a dependency. The cpp library is huge when built
under Msys/mingw -- about 800K (both 7.0 and also 7.1) . They may
already be functionally equivalent, I do not know. In contrast,
pcreposix.dll (7.0) is larger than libpcreposix-0.dll (120K vs 17K using
my CFLAG options). We did initially try to use the cpp library in our
project, but couldn't make the g++ version work with our app, and
couldn't get the library to build natively in MSVC.
Have you had a chance to look further into the failure of make check
under Msys/mingw and whether it is cause by those libtool scripts that
get exe extensions in the build directory?
Regards,
Sheri
