OBS repositories and static libraries
Hello, good people, I wanted just to point out some policies we decided when we started this mingw cross-compiling in OBS. These policies were based on our experience with win32 porting. One is that we don't distribute the *.la files. They hard-code the configure time paths and are basically worthless for linking. If something does not link without them there is a problem somewhere else :) Another policy is that we don't distribute static libraries unless there is a huge reason for this. The exception nowadays is the iconv implementation that we use win_iconv, because it only translates between iconv APIs and win32 native APIs and distribute it as a dll would not make any sense, especially that it is not developed as such by the developer. It is true that in the win32 world, many people, me including (Tor will remember) liked to make as much binaries as possible statically linked so that they can distribute only one *.exe. But, from experience, a multitude of dlls is better even for pixman that might be at one point used by something else then cairo. Cheers Fridrich -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
2011/4/12 Fridrich Strba
Hello, good people,
I wanted just to point out some policies we decided when we started this mingw cross-compiling in OBS. These policies were based on our experience with win32 porting.
Thanks for bringing this up. I was thinking of asking the list first, but then decided to just submit the requests on OBS directly. Can we write these policies down on a wiki or something?
One is that we don't distribute the *.la files. They hard-code the configure time paths and are basically worthless for linking. If something does not link without them there is a problem somewhere else :)
Yup, I agree about *.la. I guess the same holds for *.dll.a files? No static libraries means that there are no *.a (or *.lib) files in the -devel packages either. Does that mean that a -devel pacakage only contains include files and pkg-config files? (perhaps together with docs and helper scripts/binaries) What about *.def files? I am thinking of facilitating people wanting to link against dynamic libraries on Windows using MSVC. Do they need a .def file or is the DLL enough, just like it is for cross-compiling with mingw? May be somebody who actually links against OBS binaries on Windows can answer this.
Another policy is that we don't distribute static libraries unless there is a huge reason for this. The exception nowadays is the iconv implementation that we use win_iconv, because it only translates between iconv APIs and win32 native APIs and distribute it as a dll would not make any sense, especially that it is not developed as such by the developer.
It seems libintl is another exception.
It is true that in the win32 world, many people, me including (Tor will remember) liked to make as much binaries as possible statically linked so that they can distribute only one *.exe. But, from experience, a multitude of dlls is better even for pixman that might be at one point used by something else then cairo.
Well, the binaries from Tor on ftp.gnome.org always included pixman statically in cairo, that's where I got the idea from. But the policy makes sense and there is actually already another package that depends on pixman: gtk2-engine-murrine, although I think I'm the only one interested in that package. If there is a wiki page explaining these policies, then a rationale for only providing DLLs (such as enabling the user to upgrade to newer versions with security fixes) should go there too.
Cheers
Fridrich
Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
Yup, I agree about *.la. I guess the same holds for *.dll.a files?
No, why would it? .dll.a files should be distributed. (I don't think GNU ld's ability to use a DLL directly for import information should be used except in cases where absolutely needed.)
What about *.def files? I am thinking of facilitating people wanting to link against dynamic libraries on Windows using MSVC. Do they need a .def file or is the DLL enough, just like it is for cross-compiling with mingw?
It is easier for them if a .def file is distributed, because then they need to know just how to run lib.exe to generate the import library. Sure, you can generate a .def file from a DLL too, but it is more convoluted, either using pexports or gendef, or link -dump -exports and some manual editing.
May be somebody who actually links against OBS binaries on Windows can answer this.
Yeah, good point, I am not sure there are such people anyway;)
It seems libintl is another exception.
For "my" (no longer updated) binaries, I stopped using the static proxy-libintl in the end, and just link normally to the libintl DLL (which I insisted calling "intl.dll" for backward compatibility).
Well, the binaries from Tor on ftp.gnome.org always included pixman statically in cairo,
That was just a quick decision without much thought back when the separate pixman was introduced, and I stubbornly held on to it. If I would have continues doing builds, I would probably have switched to a normal dynamic pixman library like on Linux. Don't needlessly follow my ideas here... --tml -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
2011/4/13 Tor Lillqvist
Yup, I agree about *.la. I guess the same holds for *.dll.a files?
No, why would it? .dll.a files should be distributed.
Hmm, yes. I was thrown off by rm -f $RPM_BUILD_ROOT%{_mingw32_libdir}/gtk-2.0/*/engines/*.dll.a in mingw32-gtk2-engines. But of course .dll.a files for loadable modules don't need to be redistributed and .dll.a files in %{_mingw32_libdir} do have to be included in the -devel package. I'll take my coffee now.
(I don't think GNU ld's ability to use a DLL directly for import information should be used except in cases where absolutely needed.)
What about *.def files? I am thinking of facilitating people wanting to link against dynamic libraries on Windows using MSVC. Do they need a .def file or is the DLL enough, just like it is for cross-compiling with mingw?
It is easier for them if a .def file is distributed, because then they need to know just how to run lib.exe to generate the import library. Sure, you can generate a .def file from a DLL too, but it is more convoluted, either using pexports or gendef, or link -dump -exports and some manual editing.
Some packages already include .def files (e.g. glib2) and some explicitly exclude them (e.g. gtk2). In other cases it gets generated in the build tree but not installed (cairo). Would it thus be a good policy to include a .def file in the -devel package when the upstream build process already provides one?
May be somebody who actually links against OBS binaries on Windows can answer this.
Yeah, good point, I am not sure there are such people anyway;)
It seems libintl is another exception.
For "my" (no longer updated) binaries, I stopped using the static proxy-libintl in the end, and just link normally to the libintl DLL (which I insisted calling "intl.dll" for backward compatibility).
Well, the binaries from Tor on ftp.gnome.org always included pixman statically in cairo,
That was just a quick decision without much thought back when the separate pixman was introduced, and I stubbornly held on to it. If I would have continues doing builds, I would probably have switched to a normal dynamic pixman library like on Linux. Don't needlessly follow my ideas here...
Fair enough, I'll just retract my requests on the OBS to link pixman statically then.
--tml
Maarten -- To unsubscribe, e-mail: opensuse-mingw+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-mingw+help@opensuse.org
participants (3)
-
Fridrich Strba -
Maarten Bosmans -
Tor Lillqvist