Sorry for necroreply.
When *cross* compiling from Cygwin to MinGW (read: native Windows) the
different "--build" and "--host" must be used, like
--build=x86_64-pc-cygwin --host=x86_64-w64-mingw32
or
--build=x86_64-pc-cygwin --host=x86_64-pc-mingw64
as you are building is on Cygwin, not on MinGW
On Fri, 25 Jun 2021, Dietmar May wrote:
Is this a holdover from 13 year old mingw behavior? or related somehow
to running autotools in a cmd.exe environment (like Microsoft's original
NT "posix" subsystem, a port of gnu commands to run "natively" under
cmd.exe)?
Libtool was last released in 20
The build completes successfully by replacing the "cmd /c | sed"
construct with simply:
func_convert_core_msys_to_w32_result=$1
so no path translation takes place.
The function then becomes:
func_convert_core_msys_to_w32 ()
{
$debug_cmd
func_convert_core_msys_to_w32_result=$1
}
SUMMARY
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
The project builds successfully on msys2 +
Tor Lillqvist <[EMAIL PROTECTED]> 写道： Bruno Haible writes: > You appear to be using mingw as a development environment. I don't know > whether libtool supports that.If with mingw one combines MSYS, it certainly does. Using MSYS withauto* and libtool is IMHO much more reliable than using Cygwin, MSY
Bob Friesenhahn writes:
> Libtool does support using the MinGW compiler via Cygwin or
> MSYS (I have only tried MSYS). Both of these support Unix type paths
> and automatically convert to Windows paths for MinGW.
I don't think Cygwin does that to the same extent as MSYS. Isn't that
the exact
Bruno Haible writes:
> You appear to be using mingw as a development environment. I don't know
> whether libtool supports that.
If with mingw one combines MSYS, it certainly does. Using MSYS with
auto* and libtool is IMHO much more reliable than using Cygwin, MSYS
gets less in the way and causes
On Fri, 4 Aug 2006, Bruno Haible wrote:
...
I was able to complete the compiles and generate a version of
wvware-1.2.1 that worked standalone on windows.
You appear to be using mingw as a development environment. I don't know
whether libtool supports that.
MinGW is not a development environme
Matthew McGillis wrote:
> found that by simply
> editing the libtool used in both of the above cases and adding:
>
> case $deplib in
>/home*) deplib="c:/cygwin"$deplib;;
> esac
>
> ...
> I was able to complete the compiles and generate a version of
> wvware-1.2.1
Exactly. Did you compile GCC yourself but installed it in MSYS /bin?
I think that was the thing not to do, as it inhibits the automatic
path translation. See
http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys for more info.
The gcc used comes from mingw.
I installed MinGW by Downloading th
Hello Matthew,
* [EMAIL PROTECTED] wrote on Fri, Aug 04, 2006 at 08:12:20PM CEST:
>
> This is not exactly a bug in a strict since but it is a complication
> of building software with MinGW.
> gcc -g -O2 -Wl,--disable-auto-import -o .libs/test-names.exe test-
> names.o -Lc:/progra~1/wv libuni
This is not exactly a bug in a strict since but it is a complication
of building software with MinGW. Just a little back ground I was
looking to build the latest version of wvware so that I end up with a
windows stand alone binary.
The environment that I was working on was:
Windows 2003
12 matches
Mail list logo
