[libvirt] Fedora MinGW - need for *.def files
[This is just a FYI ...] Upstream binutils or gcc changed the default way that symbols are exported for cross-compiled (Fedora MinGW) DLLs. Previously all symbols were exported. Now they are only exported if they are explicitly listed in a *.def file. There are two ways that libvirt could be changed to do the right thing here. Either (probably simplest) add '-export-all-symbols' to the libtool command line. This would have to be done conditionally based on Win32 being the compilation target. Or create a *.def file. It looks like: LIBRARY libvirt.dll DESCRIPTION "libvirt foo blah" EXPORTS <<list of symbol names, one per line>> http://msdn.microsoft.com/en-us/library/d91k01sh%28VS.80%29.aspx http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx The LIBRARY and DESCRIPTION lines are optional. You have to add '-export-symbols libvirt.def' to the libtool command line. (It's not clear to me at the moment if you only do this for Windows or if it's safe to pass this on all platforms -- the documentation for this is very sparse). There is a third method: you can munge all the code by adding __declspec(dllexport) to all exported symbols in the header files, conditionally of course. I'm pretty sure that's the worst of all worlds. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Mon, Nov 16, 2009 at 11:23:15AM +0000, Richard W.M. Jones wrote:
[This is just a FYI ...]
Upstream binutils or gcc changed the default way that symbols are exported for cross-compiled (Fedora MinGW) DLLs. Previously all symbols were exported. Now they are only exported if they are explicitly listed in a *.def file.
There are two ways that libvirt could be changed to do the right thing here.
Or create a *.def file. It looks like:
LIBRARY libvirt.dll DESCRIPTION "libvirt foo blah" EXPORTS <<list of symbol names, one per line>>
http://msdn.microsoft.com/en-us/library/d91k01sh%28VS.80%29.aspx http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx
The LIBRARY and DESCRIPTION lines are optional.
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Nov 16, 2009 at 11:34:51AM +0000, Daniel P. Berrange wrote:
On Mon, Nov 16, 2009 at 11:23:15AM +0000, Richard W.M. Jones wrote:
[This is just a FYI ...]
Upstream binutils or gcc changed the default way that symbols are exported for cross-compiled (Fedora MinGW) DLLs. Previously all symbols were exported. Now they are only exported if they are explicitly listed in a *.def file.
There are two ways that libvirt could be changed to do the right thing here.
Or create a *.def file. It looks like:
LIBRARY libvirt.dll DESCRIPTION "libvirt foo blah" EXPORTS <<list of symbol names, one per line>>
http://msdn.microsoft.com/en-us/library/d91k01sh%28VS.80%29.aspx http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx
The LIBRARY and DESCRIPTION lines are optional.
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
yup, Rich how urgent is that ? maybe we should try to fix this for 0.7.3 (I'm also wondering why I didn't see this for libxml2/libxslt) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Nov 16, 2009 at 01:29:35PM +0100, Daniel Veillard wrote:
On Mon, Nov 16, 2009 at 11:34:51AM +0000, Daniel P. Berrange wrote:
On Mon, Nov 16, 2009 at 11:23:15AM +0000, Richard W.M. Jones wrote:
[This is just a FYI ...]
Upstream binutils or gcc changed the default way that symbols are exported for cross-compiled (Fedora MinGW) DLLs. Previously all symbols were exported. Now they are only exported if they are explicitly listed in a *.def file.
There are two ways that libvirt could be changed to do the right thing here.
Or create a *.def file. It looks like:
LIBRARY libvirt.dll DESCRIPTION "libvirt foo blah" EXPORTS <<list of symbol names, one per line>>
http://msdn.microsoft.com/en-us/library/d91k01sh%28VS.80%29.aspx http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx
The LIBRARY and DESCRIPTION lines are optional.
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
yup, Rich how urgent is that ? maybe we should try to fix this for 0.7.3 (I'm also wondering why I didn't see this for libxml2/libxslt)
Erik can probably answer this more accurately, but I think it's only a concern for Fedora 13. The problem is that if you don't do anything then you'll end up silently building DLLs that don't work. I hit that problem today with mingw32-libpng :-( Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
Op maandag 16-11-2009 om 13:03 uur [tijdzone +0000], schreef Richard W.M. Jones:
On Mon, Nov 16, 2009 at 01:29:35PM +0100, Daniel Veillard wrote:
On Mon, Nov 16, 2009 at 11:34:51AM +0000, Daniel P. Berrange wrote:
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
yup, Rich how urgent is that ? maybe we should try to fix this for 0.7.3 (I'm also wondering why I didn't see this for libxml2/libxslt)
Erik can probably answer this more accurately, but I think it's only a concern for Fedora 13.
The problem is that if you don't do anything then you'll end up silently building DLLs that don't work. I hit that problem today with mingw32-libpng :-(
Rich.
Hi, Fedora 12 already contains the gcc and binutils which have this behaviour. A few weeks ago I ran into this issue with the mingw32-libsoup DLL which didn't contain any exported symbols anymore after an upgrade (a bug for that was already filed at [1]). I don't know what the situation is for libxml2/libxslt as the build logs aren't available anymore in Koji and I didn't get to do a local build here. BTW, the .def files are also used on Mac OS X environments (though I had issues were libtool didn't like the 'EXPORTS' line in the .def file). Regards, Erik van Pienbroek [1]: https://bugzilla.gnome.org/show_bug.cgi?id=595176
On 11/16/2009 02:40 PM, Erik van Pienbroek wrote:
BTW, the .def files are also used on Mac OS X environments (though I had issues were libtool didn't like the 'EXPORTS' line in the .def file).
Indeed, libtool works on all platforms if you just place one-symbol-per-line in the file (and maybe not call it .def since it is not a .def file). Paolo
On Mon, Nov 16, 2009 at 03:40:43PM +0100, Paolo Bonzini wrote:
On 11/16/2009 02:40 PM, Erik van Pienbroek wrote:
BTW, the .def files are also used on Mac OS X environments (though I had issues were libtool didn't like the 'EXPORTS' line in the .def file).
Indeed, libtool works on all platforms if you just place one-symbol-per-line in the file (and maybe not call it .def since it is not a .def file).
By 'works' you mean restricts you to the lowest common denominator of just allowing you to give a list of symbols. For Linux and Solaris this is not useful, since we need the full ELF versioning data Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 11/16/2009 03:46 PM, Daniel P. Berrange wrote:
By 'works' you mean restricts you to the lowest common denominator of just allowing you to give a list of symbols. For Linux and Solaris this is not useful, since we need the full ELF versioning data
Yes, you'd add a configure test for ELF versioning support, and use -export-symbols if that test fails. Paolo
On 11/16/2009 12:34 PM, Daniel P. Berrange wrote:
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
So this: `-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported. does not work for MinGW? Paolo
On Mon, Nov 16, 2009 at 02:20:23PM +0100, Paolo Bonzini wrote:
On 11/16/2009 12:34 PM, Daniel P. Berrange wrote:
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
So this:
`-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported.
does not work for MinGW?
That';s what we use on Linux, but the script we provide is an ELF symbol version script, and since MinGW does not use ELF I doubt its going to work directly Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 11/16/2009 02:24 PM, Daniel P. Berrange wrote:
So this:
`-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported.
does not work for MinGW?
That';s what we use on Linux, but the script we provide is an ELF symbol version script, and since MinGW does not use ELF I doubt its going to work directly
Yeah, i was asking Rich why generating a .def file rather than going through libtool's abstraction. Paolo
On Mon, Nov 16, 2009 at 02:20:23PM +0100, Paolo Bonzini wrote:
On 11/16/2009 12:34 PM, Daniel P. Berrange wrote:
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
So this:
`-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported.
does not work for MinGW?
As I understand it [and note: I have *not* tried it] the documentation there is wrong for MinGW. You should pass a *.def file as the parameter when the compiler target [ie. "host"] is Windows. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
On 11/16/2009 02:34 PM, Richard W.M. Jones wrote:
On Mon, Nov 16, 2009 at 02:20:23PM +0100, Paolo Bonzini wrote:
On 11/16/2009 12:34 PM, Daniel P. Berrange wrote:
This method sounds appealing to me - we could likely auto-generate this file from the master src/libvirt_public.syms file we already have for Linux/Solaris
So this:
`-export-symbols SYMFILE' Tells the linker to export only the symbols listed in SYMFILE. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option has no effect on some platforms. By default all symbols are exported.
does not work for MinGW?
As I understand it [and note: I have *not* tried it] the documentation there is wrong for MinGW. You should pass a *.def file as the parameter when the compiler target [ie. "host"] is Windows.
The libtool code suggests that in addition a .def file is accepted by libtool on Windows hosts, but this is undocumented and the detection is very simplistic: # exporting using user supplied symfile if test "x`$SED 1q $export_symbols`" != xEXPORTS; then # and it's NOT already a .def file. So passing LIBRARY as the first line doesn't work. :-( However, passing a simple one-symbol-per-line file should work. Paolo
On Mon, Nov 16, 2009 at 02:43:27PM +0100, Paolo Bonzini wrote:
The libtool code suggests that in addition a .def file is accepted by libtool on Windows hosts, but this is undocumented and the detection is very simplistic:
libtool .. undocumented. Say it ain't so :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Erik van Pienbroek -
Paolo Bonzini -
Richard W.M. Jones