Even though it runs on Windows, Cygwin uses UNIX paths.
The _WIN32 macro may still be defined when using Win32 APIs
however.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
build-aux/ltmain.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-aux/ltmain.in
On 3/9/20 9:01 PM, Simon Marchi wrote:
>> Hello libtool folks,
>> Any ideas about this? Something confused the file magic command?
>> dlltool --identify does show libdl.a is associated with cygwin1.dll for
>> example.
>
> Hi,
>
> I stumbled on this and dug into libtool, here's what I found.
>
>
On 3/1/20 11:00 AM, Marco Atzeri wrote:
>>
>> Last file checked: /lib/libpthread.a
>>
>> Is that correct? Do you have the complete command line? Is this
>> happening on both archs or just i686?
>>
>
> both archs.
> The error is likely coming from libtool and it is valid for all the 3
> libraries
On 4/19/2014 09:22, Evgeny Grin wrote:
19.04.2014, 04:45, JonY:
On 4/19/2014 03:31, Evgeny Grin wrote:
For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll,
all of 4 depend on zlib1.dll, but each one on specific zlib version. And
with some zlib versions some
On 4/19/2014 03:31, Evgeny Grin wrote:
18.04.2014, 19:25, Bob Friesenhahn bfrie...@simple.dallas.tx.us:
For Win32 builds on my Windows system, I see that it is normal for
DLLs to be named according to the major interface number. For
example, zlib (not created using libtool) is named
On 9/10/2013 02:12, Ozkan Sezer wrote:
*** Warning: linker path does not have real file for library -lole32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which
On 7/22/2012 00:43, Peter Rosin wrote:
On 2012-07-21 14:49, Vincent Torri wrote:
On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote:
On 2012-07-21 13:16, Vincent Torri wrote:
another solution is to just kill the stupid .la file. There is
I don't think the .la file is
On 2/1/2010 01:18, Roumen Petrov wrote:
JonY wrote:
On 1/31/2010 02:14, Roumen Petrov wrote:
I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a
Also note that makefiles the macros(variables) are libfoo_.
Did
On 1/30/2010 06:55, Ralf Wildenhues wrote:
That would be fine with me. But I suggest that any policy decision for
such a naming change should be done by those projects (MinGW-W64, MinGW,
or both), documented there, a flag day announced, and then libtool
should follow suit, not the other way
On 1/30/2010 22:56, Ralf Wildenhues wrote:
If any of the Libtool users come and complain about libtool not linking
against their old (or new) libraries after we've made the change, I want
to be able to point to your documentation site and tell them we had no
choice, upstream had a flag day,
On 1/31/2010 02:14, Roumen Petrov wrote:
I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a
Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to
On 1/29/2010 10:29, Bob Friesenhahn wrote:
On Fri, 29 Jan 2010, JonY wrote:
Another solution it to stop installing DLLs to bindir and follow unix
style installs into libdir, right beside the import libs, let the user
set the PATH. That way, we don't need a bin32 and bin64 directory
On 1/29/2010 20:16, Dave Korn wrote:
So I think what I'd conclude is that MinGW-W64 should have its own prefix,
but it should be the same one for 32-bit and 64-bit W64 DLLs.
Hi,
I'm not entirely sure how to avoid 64bit vs 32bit mingw-w64 clashing if
both use the same DLL naming scheme.
On 1/28/2010 13:46, Ralf Wildenhues wrote:
* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET:
Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
and MinGW based systems uses the lib prefix.
This works fine, until mingw-w64 showed up with 64bit dlls. This
problem
On 1/28/2010 19:30, Tor Lillqvist wrote:
The issue is that libtool
uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
and mingw-w64.
Well, my take is that except for people working on the *tools
themselves* (meaning gcc, binutils etc), this is not really a problem.
Sure,
On 1/29/2010 04:07, Ralf Wildenhues wrote:
My proposal has the same rationale as using the cyg and lib prefix
on Cygwin and MinGW, so no DLLs can clash.
No, that is not the same thing. The Cygwin runtime system actually
looks for libraries named cygNAME.dll; see 'info ld WIN32'. The
GNU libc
On 1/27/2010 18:02, Peter Rosin wrote:
Den 2010-01-26 16:26 skrev JonY:
I suggest the following naming scheme.
mingw.org: libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64): lib64name-major.dll
mingw-w64(32): lib32name-major.dll
But then mingw-w64 invades
Hi,
Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
and MinGW based systems uses the lib prefix.
This works fine, until mingw-w64 showed up with 64bit dlls. This
problem is especially apparent with trying to build mingw-w64 cross
compilers.
For example, both mingw and
On 1/26/2010 23:52, Alon Bar-Lev wrote:
On Tue, Jan 26, 2010 at 5:26 PM, JonYjo...@users.sourceforge.net wrote:
Hi,
Currently, on Win32 platforms, Cygwin uses the cyg prefix for dlls,
and MinGW based systems uses the lib prefix.
This works fine, until mingw-w64 showed up with 64bit dlls.
19 matches
Mail list logo
