Your message dated Sat, 9 Aug 2014 11:48:34 +0200
with message-id <[email protected]>
and subject line Re: Bug#748690: mingw-w64: Some libraries are archive static
instead of archive import
has caused the Debian Bug report #748690,
regarding mingw-w64: Some libraries are archive static instead of archive import
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
748690: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748690
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: mingw-w64
Version: 3.1.0-1
Severity: normal
Hi Stephen,
Thank you for maintaining mingw-w64 for debian!
I try to compile ekiga using mingw-w64 and the problem is that it
generates only a .a, not a .dll. The reason is that libtool gives
errors like this:
*** Warning: linker path does not have real file for library -luuid.
*** 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 you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/usr/i686-w64-mingw32/lib/libuuid.a
I pinned down the problem to the fact that some libraries are
recognised as archive static by libtool instead of aarchive import. I
put some echo in libtool and it shows for example:
func_win32_libid
/usr/lib/gcc/i686-w64-mingw32/4.9/../../../../i686-w64-mingw32/lib/../lib/libdsound.a
x86 archive import
but
func_win32_libid
/usr/lib/gcc/i686-w64-mingw32/4.9/../../../../i686-w64-mingw32/lib/libuuid.a
x86 archive static
The problem is with the ones recognised as archive static. The
following files have this problem in my case:
libdxerr9.a, libdxguid.a, libstrmiids.a, libuuid.a.
Do you know why the above files have this problem? Feel free to ask me
more information if needed.
Cheers,
Eugen
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mingw-w64 depends on:
ii g++-mingw-w64 4.9.0-2+13
ii gcc-mingw-w64 4.9.0-2+13
mingw-w64 recommends no packages.
mingw-w64 suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Eugen,
On Fri, 08 Aug 2014 16:33:04 +0200, Eugen Dedu <[email protected]>
wrote:
> On 08/08/14 12:29, Eugen Dedu wrote:
> > On 08/08/14 08:06, Stephen Kitt wrote:
> >> Hi Eugen,
> >>
> >> On Wed, 06 Aug 2014 13:12:18 +0200, Eugen Dedu
> >> <[email protected]>
> >> wrote:
> >>> I made some insight in this issue. I can reproduce on a simple example.
> >>
> >> Excellent, thanks for taking the time to figure this out.
> >>
> >>> Take a libtool file you created from a mingw build. I tested with one
> >>> generated this month, and another one generated one year ago, where the
> >>> build worked. Both exhibit the bug, so libtool does not have any
> >>> problem, it seems. I attach a libtool in case you need one.
> >>
> >> Do you know what version of mingw-w64 you were using when the build
> >> worked?
> >> I've tried with various versions going back to 2.0.8-1 (from May 2013)
> >> and
> >> the error message always appears.
> >
> > I do not know what to say, since I am confused about all this.
No worries, it's not easy to figure out where things are going wrong,
especially when multiple projects change and still need to work together!
> > Those flags (-dxerr9 and all the libraries which pose problems) are
> > found in ptlib.pc, Libs: line, so they get used by ekiga. I think this
> > is an error, which triggers also the bug.
> >
> > If I remove those flags during ekiga linking, there is no warning and
> > libekiga.dll is generated.
> >
> > In previous versions of ptlib, those flags were put in Libs.private:
> > line, hence they were not used during linking of *ekiga*, that's why it
> > worked.
> >
> > An alternative solution for me is to move those flags from Libs: back to
> > Libs.private, but I fear it gives errors in other places/programs.
>
> I did this and it compiled well! Hope it does not break elsewhere.
That explains everything, and I see you've committed the change to ptlib.
I'll close this bug, feel free as always to re-open it if you discover
something's wrong in mingw-w64!
Regards,
Stephen
signature.asc
Description: PGP signature
--- End Message ---
