GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Dear list,

I am trying to use the MSYS2 distributed mingw32 GTK+ DLLs in a VS2013 project.

I have `cairo' and `pango_cairo' API calls in my code, requiring that the following import libraries are added to the VS project option, "Linker->Additional Dependencies":
  • libcairo.dll.a
  • libpangocairo-1.0.dll.a
After a successful build, I get an `Entry Point Not Found' error at run-time.

If `libcairo.dll.a' is above `libpangocairo-1.0.dll.a' in the `Additional Dependencies' list, then the error is:

"The procedure entry point pango_cairo_create_layout could not be located in the dynamic link library libcairo-2.dll"

If  `libpangocairo-1.0.dll.a' is above `libcairo.dll.a', then the error is:

"The procedure entry point cairo_create could not be located in the dynamic link library libpangocairo-1.0-0.dll"

I used the `nm' command to see where the above entry points exist, but they only exist in their expected libraries.

i.e. `pango_cairo_create_layout' is exported in `libpangocairo-1.0.dll.a', as expected, and vice versa for the cairo API call.

I do not know why these entry points are being sought in the incorrect DLLs.

Any ideas how to resolve this linker conflict? Has anyone used the official MSYS2 GTK+ distribution in a Visual Studio project before?

Jeff.

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Update:

I generated my own `.LIB' files using `gendef' and `dlltool' (e.g. https://github.com/Automattic/node-canvas/wiki/Installation---Windows-(with-MSYS2) ).

After disabling `/SAFESH' in the MSVC Linker options, I was able to build my project. However, no text is being rendered by Pango-Cairo API calls.

I am trying to build against the official GTK mingw32 release, as I have compatibility issues across machines/environments with DLLs built with the `gvsbuild' project.

I will see if I can get any useful debug information out of the offical GTK libs at runtime.

Has anyone built against the official GTK libs successfully with MSVC?

On 4 September 2017 at 17:54, Jeffrey Sheen <[hidden email]> wrote:
Dear list,

I am trying to use the MSYS2 distributed mingw32 GTK+ DLLs in a VS2013 project.

I have `cairo' and `pango_cairo' API calls in my code, requiring that the following import libraries are added to the VS project option, "Linker->Additional Dependencies":
  • libcairo.dll.a
  • libpangocairo-1.0.dll.a
After a successful build, I get an `Entry Point Not Found' error at run-time.

If `libcairo.dll.a' is above `libpangocairo-1.0.dll.a' in the `Additional Dependencies' list, then the error is:

"The procedure entry point pango_cairo_create_layout could not be located in the dynamic link library libcairo-2.dll"

If  `libpangocairo-1.0.dll.a' is above `libcairo.dll.a', then the error is:

"The procedure entry point cairo_create could not be located in the dynamic link library libpangocairo-1.0-0.dll"

I used the `nm' command to see where the above entry points exist, but they only exist in their expected libraries.

i.e. `pango_cairo_create_layout' is exported in `libpangocairo-1.0.dll.a', as expected, and vice versa for the cairo API call.

I do not know why these entry points are being sought in the incorrect DLLs.

Any ideas how to resolve this linker conflict? Has anyone used the official MSYS2 GTK+ distribution in a Visual Studio project before?

Jeff.


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Emmanuele Bassi
On 5 September 2017 at 13:01, Jeffrey Sheen
<[hidden email]> wrote:

> Has anyone built against the official GTK libs successfully with MSVC?

Look at gvsbuild: https://github.com/wingtk/gvsbuild

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Thank you Emmanuele, but as above, I've observed `gvsbuild' project a having variable compatibility with the ecosystem of target machines/environments.

I would like to build against the official release, to establish a benchmark of compatibility.

Has anyone built against the official mingw GTK+ DLLs with MSVC?

On 5 September 2017 at 13:12, Emmanuele Bassi <[hidden email]> wrote:
On 5 September 2017 at 13:01, Jeffrey Sheen
<[hidden email]> wrote:

> Has anyone built against the official GTK libs successfully with MSVC?

Look at gvsbuild: https://github.com/wingtk/gvsbuild

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Emmanuele Bassi
On 5 September 2017 at 17:15, Jeffrey Sheen
<[hidden email]> wrote:
> Thank you Emmanuele, but as above, I've observed `gvsbuild' project a having
> variable compatibility with the ecosystem of target machines/environments.
>
> I would like to build against the official release, to establish a benchmark
> of compatibility.

What's an "official release"?

Ciao,
 Emmanuele.

> On 5 September 2017 at 13:12, Emmanuele Bassi <[hidden email]> wrote:
>>
>> On 5 September 2017 at 13:01, Jeffrey Sheen
>> <[hidden email]> wrote:
>>
>> > Has anyone built against the official GTK libs successfully with MSVC?
>>
>> Look at gvsbuild: https://github.com/wingtk/gvsbuild
>>
>> Ciao,
>>  Emmanuele.
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Binaries built and distributed with mingw, distributed through MSYS2, are declared official here:

https://www.gtk.org/download/windows.php

Has anyone built against these binaries with MSVC?

On 5 September 2017 at 17:19, Emmanuele Bassi <[hidden email]> wrote:
On 5 September 2017 at 17:15, Jeffrey Sheen
<[hidden email]> wrote:
> Thank you Emmanuele, but as above, I've observed `gvsbuild' project a having
> variable compatibility with the ecosystem of target machines/environments.
>
> I would like to build against the official release, to establish a benchmark
> of compatibility.

What's an "official release"?

Ciao,
 Emmanuele.

> On 5 September 2017 at 13:12, Emmanuele Bassi <[hidden email]> wrote:
>>
>> On 5 September 2017 at 13:01, Jeffrey Sheen
>> <[hidden email]> wrote:
>>
>> > Has anyone built against the official GTK libs successfully with MSVC?
>>
>> Look at gvsbuild: https://github.com/wingtk/gvsbuild
>>
>> Ciao,
>>  Emmanuele.
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Emmanuele Bassi
On 5 September 2017 at 17:28, Jeffrey Sheen
<[hidden email]> wrote:
> Binaries built and distributed with mingw, distributed through MSYS2, are
> declared official here:
>
> https://www.gtk.org/download/windows.php
>
> Has anyone built against these binaries with MSVC?

That's not what MSYS2 is for. MSYS2 is a Unix-like environment on
Windows, and using MSVC is not compatible with that, especially for
things like debugging symbols.

You either want to build everything with MSVC, or you build everything
with MSYS2.

Ciao,
 Emmanuele.

> On 5 September 2017 at 17:19, Emmanuele Bassi <[hidden email]> wrote:
>>
>> On 5 September 2017 at 17:15, Jeffrey Sheen
>> <[hidden email]> wrote:
>> > Thank you Emmanuele, but as above, I've observed `gvsbuild' project a
>> > having
>> > variable compatibility with the ecosystem of target
>> > machines/environments.
>> >
>> > I would like to build against the official release, to establish a
>> > benchmark
>> > of compatibility.
>>
>> What's an "official release"?
>>
>> Ciao,
>>  Emmanuele.
>>
>> > On 5 September 2017 at 13:12, Emmanuele Bassi <[hidden email]> wrote:
>> >>
>> >> On 5 September 2017 at 13:01, Jeffrey Sheen
>> >> <[hidden email]> wrote:
>> >>
>> >> > Has anyone built against the official GTK libs successfully with
>> >> > MSVC?
>> >>
>> >> Look at gvsbuild: https://github.com/wingtk/gvsbuild
>> >>
>> >> Ciao,
>> >>  Emmanuele.
>> >>
>> >> --
>> >> https://www.bassi.io
>> >> [@] ebassi [@gmail.com]
>> >
>> >
>>
>>
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Thank you Emmanuele,

That is the first time I've heard that MinGW binaries (gcc) and the MSVC build chain are incompatible. It would explain why I have non-functional behaviour in my application.

This article on the MinGW website indicated that there was interoperability: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

On 5 September 2017 at 17:35, Emmanuele Bassi <[hidden email]> wrote:
On 5 September 2017 at 17:28, Jeffrey Sheen
<[hidden email]> wrote:
> Binaries built and distributed with mingw, distributed through MSYS2, are
> declared official here:
>
> https://www.gtk.org/download/windows.php
>
> Has anyone built against these binaries with MSVC?

That's not what MSYS2 is for. MSYS2 is a Unix-like environment on
Windows, and using MSVC is not compatible with that, especially for
things like debugging symbols.

You either want to build everything with MSVC, or you build everything
with MSYS2.

Ciao,
 Emmanuele.

> On 5 September 2017 at 17:19, Emmanuele Bassi <[hidden email]> wrote:
>>
>> On 5 September 2017 at 17:15, Jeffrey Sheen
>> <[hidden email]> wrote:
>> > Thank you Emmanuele, but as above, I've observed `gvsbuild' project a
>> > having
>> > variable compatibility with the ecosystem of target
>> > machines/environments.
>> >
>> > I would like to build against the official release, to establish a
>> > benchmark
>> > of compatibility.
>>
>> What's an "official release"?
>>
>> Ciao,
>>  Emmanuele.
>>
>> > On 5 September 2017 at 13:12, Emmanuele Bassi <[hidden email]> wrote:
>> >>
>> >> On 5 September 2017 at 13:01, Jeffrey Sheen
>> >> <[hidden email]> wrote:
>> >>
>> >> > Has anyone built against the official GTK libs successfully with
>> >> > MSVC?
>> >>
>> >> Look at gvsbuild: https://github.com/wingtk/gvsbuild
>> >>
>> >> Ciao,
>> >>  Emmanuele.
>> >>
>> >> --
>> >> https://www.bassi.io
>> >> [@] ebassi [@gmail.com]
>> >
>> >
>>
>>
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
LRN
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

LRN
On 9/5/2017 7:48 PM, Jeffrey Sheen wrote:
> Thank you Emmanuele,
>
> That is the first time I've heard that MinGW binaries (gcc) and the MSVC build
> chain are incompatible. It would explain why I have non-functional behaviour in
> my application.
>
> This article on the MinGW website indicated that there was
> interoperability: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
>

Any DLL that exposes C++ interface (so this does not apply to GTK+, but it's
still useful to keep in mind) is incompatible if it's compiled by different
compilers (especially MSVC and GCC; hell, even compiling with different GCC
versions makes them incompatible).

DLLs with C interface are nominally-compatible. The main source of
incompatibilities are:
1) Wrong compilation (for example - not using the MS alignment for structs when
compiling code with GCC). Code compiled with MSVC is nominally usable in
GCC-compiled programs (you are, after all, using MS W32 API DLLs, and MSVCRT -
these are compiled with MSVC).
2) Different C runtimes - MinGWs generally link to MSVCRT, unless you make them
do otherwise; MSVC generally links to different MSVCR versions, passing around
C object IDs (file descriptors, for example), will lead to bad stuff happening.

Also, debug information is incompatible (MS debugger doesn't understand dwarf
debug info; gdb doesn't understand pdb debug info).

As long as headers are written correctly, and runtimes are compatible (or
runtime differences are accounted for), it's possible to use C-interface DLLs
compiled with different compilers.


--
O< ascii ribbon - stop html email! - http://arc.pasp.de/

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list

0x8DADE9276759BA74.asc (3K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Thank you for the alternate information LRN.

If the mingw DLLs are incompatible, then they are failing silently, as my MSVC application compiles and runs without throwing errors. In your experience, would you expect this, or would you expect the binary incompatibilities to cause failure at runtime?

I'm interested in being able to validate the mingw DLLs' compatibility with MSVC, either programmatically, or by contacting the package maintainer (any idea how to establish who that might be?).

On 5 September 2017 at 18:05, LRN <[hidden email]> wrote:
On 9/5/2017 7:48 PM, Jeffrey Sheen wrote:
> Thank you Emmanuele,
>
> That is the first time I've heard that MinGW binaries (gcc) and the MSVC build
> chain are incompatible. It would explain why I have non-functional behaviour in
> my application.
>
> This article on the MinGW website indicated that there was
> interoperability: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
>

Any DLL that exposes C++ interface (so this does not apply to GTK+, but it's
still useful to keep in mind) is incompatible if it's compiled by different
compilers (especially MSVC and GCC; hell, even compiling with different GCC
versions makes them incompatible).

DLLs with C interface are nominally-compatible. The main source of
incompatibilities are:
1) Wrong compilation (for example - not using the MS alignment for structs when
compiling code with GCC). Code compiled with MSVC is nominally usable in
GCC-compiled programs (you are, after all, using MS W32 API DLLs, and MSVCRT -
these are compiled with MSVC).
2) Different C runtimes - MinGWs generally link to MSVCRT, unless you make them
do otherwise; MSVC generally links to different MSVCR versions, passing around
C object IDs (file descriptors, for example), will lead to bad stuff happening.

Also, debug information is incompatible (MS debugger doesn't understand dwarf
debug info; gdb doesn't understand pdb debug info).

As long as headers are written correctly, and runtimes are compatible (or
runtime differences are accounted for), it's possible to use C-interface DLLs
compiled with different compilers.


--
O< ascii ribbon - stop html email! - http://arc.pasp.de/

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list



_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
N.B. an additional data point:

Before an official distribution of GTK+ 3 for Win32, binaries were maintained here: http://www.tarnyko.net/dl/gtk.htm

These packages contain .LIB files, and the tutorial explicitly describes how to build an application with MSVC (cl): http://www.tarnyko.net/repo/gtk3_build_system/tutorial/gtk3_tutorial.htm

When linking the 3.6.4 Tarnyko.net binaries to my application, I have the exact same behaviour as with the current MSYS2 release binaries (i.e. text not rendering to the cairo data surface, but no errors thrown either).

The above indicates that the distributed binaries (Tarnyko.net and MSYS2) are supposed to be able to be linked with MSVC applications.

On 6 September 2017 at 15:29, Jeffrey Sheen <[hidden email]> wrote:
Thank you for the alternate information LRN.

If the mingw DLLs are incompatible, then they are failing silently, as my MSVC application compiles and runs without throwing errors. In your experience, would you expect this, or would you expect the binary incompatibilities to cause failure at runtime?

I'm interested in being able to validate the mingw DLLs' compatibility with MSVC, either programmatically, or by contacting the package maintainer (any idea how to establish who that might be?).

On 5 September 2017 at 18:05, LRN <[hidden email]> wrote:
On 9/5/2017 7:48 PM, Jeffrey Sheen wrote:
> Thank you Emmanuele,
>
> That is the first time I've heard that MinGW binaries (gcc) and the MSVC build
> chain are incompatible. It would explain why I have non-functional behaviour in
> my application.
>
> This article on the MinGW website indicated that there was
> interoperability: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
>

Any DLL that exposes C++ interface (so this does not apply to GTK+, but it's
still useful to keep in mind) is incompatible if it's compiled by different
compilers (especially MSVC and GCC; hell, even compiling with different GCC
versions makes them incompatible).

DLLs with C interface are nominally-compatible. The main source of
incompatibilities are:
1) Wrong compilation (for example - not using the MS alignment for structs when
compiling code with GCC). Code compiled with MSVC is nominally usable in
GCC-compiled programs (you are, after all, using MS W32 API DLLs, and MSVCRT -
these are compiled with MSVC).
2) Different C runtimes - MinGWs generally link to MSVCRT, unless you make them
do otherwise; MSVC generally links to different MSVCR versions, passing around
C object IDs (file descriptors, for example), will lead to bad stuff happening.

Also, debug information is incompatible (MS debugger doesn't understand dwarf
debug info; gdb doesn't understand pdb debug info).

As long as headers are written correctly, and runtimes are compatible (or
runtime differences are accounted for), it's possible to use C-interface DLLs
compiled with different compilers.


--
O< ascii ribbon - stop html email! - http://arc.pasp.de/

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list




_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Gtk+ - General mailing list
Hi Jeffrey,

As far as I understand, Tarnyko's binaries are built with MSYS2, so I
think the .lib files are generated (with Visual Studio's lib.exe) as a
convenience to people using Visual Studio, but the things that LRN
mentioned should always be taken into account when trying to use
MSYS2/MinGW (or mingw-w64)-built binaries with Visual Studio builds.

Dependency Walker would be the tool that you want to use to check on
which msvcrt(xx).dll (or vcruntime140.dll or so) that the binaries (with
their dependencies) link to.

Since tracking down such incompatibilities can become quite hard (as it
actually goes down into the CRT implementation quite a bit), probably I
would want to look carefully that file descriptors/handles especially
are not passed between your MSVC-built program and the MSYS2-built
binaries.  Do make sure that you are using a single DLL for the same
library (.lib files in this case simply points the built code to the DLL
that they are tied to--so use the same GLib DLL throughout, for example,
and make sure dependencies depend on those same DLLs, this may sound not
so bright but can catch people off guard).

There is ongoing work to support building the GTK+ (albeit 4.x only),
with its gnome.org dependencies with Meson with full support for Visual
Studio, so do take a look at that, too.

It would be best if you can have a minimal sample of the code that is
causing the problem for you.

With blessings, and cheers!

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: GTK+ mingw32 dynamic linking conflict (cairo/pangocairo)

Jeffrey Sheen
Thanks Chun-wei,

Dependency Walker reports that `libglib-2.0-0.dll' is dependent on `MSVCRT.DLL', without any version numeral. `vcruntimeXXX.dll' is not listed as a dependency.

There are no file descriptors/handles explicitly passed between my application's code and the `pango-cairo' API calls.

A simple debug code fragment I use is as follows:

cairo_surface_t *surface;
cairo_t *cr;
cairo_status_t status;

surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 390, 60);
status = cairo_surface_status(surface);

cr = cairo_create(surface);
status = cairo_status(cr);

cairo_set_source_rgba(cr, 0, 0, 0, 1);
status = cairo_status(cr);

cairo_rectangle(cr, 175, 10, 40, 40);
status = cairo_status(cr);

cairo_fill(cr);
status = cairo_status(cr);

cairo_surface_flush(surface);
status = cairo_surface_write_to_png(surface, "f:\\cairo_test.png");

cairo_destroy(cr);
cairo_surface_destroy(surface);

This produces a transparent PNG file when linked against the MSYS2 binaries, where an image of a black square is expected.

I have managed to produce the PNG containing the expected black square when building against `gvsbuild' binaries, but these binaries are not compatible across all test environments (hence why I am trying to use the official binaries).

On 7 September 2017 at 04:17, Chun-wei Fan (范君維) <[hidden email]> wrote:
Hi Jeffrey,

As far as I understand, Tarnyko's binaries are built with MSYS2, so I think the .lib files are generated (with Visual Studio's lib.exe) as a convenience to people using Visual Studio, but the things that LRN mentioned should always be taken into account when trying to use MSYS2/MinGW (or mingw-w64)-built binaries with Visual Studio builds.

Dependency Walker would be the tool that you want to use to check on which msvcrt(xx).dll (or vcruntime140.dll or so) that the binaries (with their dependencies) link to.

Since tracking down such incompatibilities can become quite hard (as it actually goes down into the CRT implementation quite a bit), probably I would want to look carefully that file descriptors/handles especially are not passed between your MSVC-built program and the MSYS2-built binaries.  Do make sure that you are using a single DLL for the same library (.lib files in this case simply points the built code to the DLL that they are tied to--so use the same GLib DLL throughout, for example, and make sure dependencies depend on those same DLLs, this may sound not so bright but can catch people off guard).

There is ongoing work to support building the GTK+ (albeit 4.x only), with its gnome.org dependencies with Meson with full support for Visual Studio, so do take a look at that, too.

It would be best if you can have a minimal sample of the code that is causing the problem for you.

With blessings, and cheers!



_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list