Re: [Mingw-users] regex package; [was: GPL license question].

[Julien L. <ju...@fa...>]

Keith MARSHALL wrote:
> Julien Lecomte wrote, quoting me:
>>> I've imported Tor's original package into CVS, and made a number
>>> of changes to the build/packaging system.
>> I've checked-out the package and ran a couple of tests, and have
>> these following comments:
>>
>> - Under MSYS I get from 'make' this final output that looks like
>> an error message to me, even if it's not. It's not very clear:
>> "MSVC program 'lib' not available; not building MSVC components
>> Not executing command: lib -def:libgnurx.def -out:gnurx.lib"
> 
> That's my workaround, to avoid the even more catastrophic looking
> `make: Error...' diagnostics thrown out by Tor's original, if you
> don't have MSVC, (or at least a compatible `lib'), installed.  It
> isn't an error; just a note to the effect that no import lib for
> MSVC is being built.  If you think it isn't sufficiently clear,
> can you suggest alternative wording?  Perhaps
> 
> ---------------
> 
>   Not executing command: lib -def:libgnurx.def -out:gnurx.lib
> 
>   MSVC program 'lib' not available; continuing without building
>   an import library for MSVC.  This is not a problem, unless you
>   specifically require such an import library; if this is the
>   case, then you must install MSVC, and ensure that its `lib'
>   command can be found in your PATH.
> 
> ---------------
> 

I just also thought of the fact that I have 
"MAKEFLAGS=--no-print-directory" by default on my systems; thus maybe 
that's why it was less clear to me.
Anyway, it's a MSVC specific warning message that's shown to MinGW users 
that don't use MSVC in that specific configure case. For me it would be 
clearer not to even have a warning. Did I mention I didn't really like 
MSVC anyway? ;-)

>> - What's the real use of testing for 'tune=pentium3' in the 
>> configure file? or of mthreads for that matter?
> 
> Tor's original Makefile specified these unconditionally.  I started
> out testing my modified build infrastructure, compiling natively on
> GNU/Linux, where GCC chokes on `-mthreads'.  Since I already had the
> autoconf macro to test for portability of CC options, I used it; it
> lets the native compile on GNU/Linux go one step further.
> 
> Of course, it then falls over on the the next step -- DLL creation,
> so it didn't buy me much.  I guess it would be cleaner to rip it out
> again, and leave these as unconditional addenda to the CC definition.

I don't see where regex needs threads anywhere anyway.

>> Under MinGW, compilation fails with missing ctype reference, so I 
>> guess regex isn't suppose to be compiled for MinGW.
> Are you saying that the compilation of gnurx-0.dll itself fails?
...
> Or are you saying that you can't deploy it with your own programs?

I found the reason that compilation failed under MinGW for me:
- I had first issued a './configure --prefix=/usr && make" under a MSYS 
shell in my regex src dir (/var/src/regex)
- I then issued a './configure --prefix=/mingw && make' under MinGW shell

Since I didn't issue a 'make clean' in the MinGW shell, "make" thought 
that the objects were up to date even if config.* files had changed. I 
believed that if config.h had changed, then "make" would be smart enough 
to recompile objects; at least that's how it works with 'automake' ;>

Julien