mingw32-opensc package

[Erik van Pienbroek]

Op maandag 23-03-2009 om 19:25 uur [tijdzone +0200], schreef Kalev
Lember:
> 1) Is there any good reason to package libtool .la files? I've excluded
> them right now, but I saw some of them in the spec files from HG repo.

Yes there is. It is necessary for libtool to find out what the
dependencies are of libraries (for example, when linking some
application against glib, you also need to link against gettext). This
is especially the case when using static libraries. Another reason for
it is so that libtool can find the .dll (in ../bin) which belongs to
the .dll.a import library.

> 2) I couldn't get configure script to detect libiconv and added a
> workaround to the spec file:
> export ICONV_LIBS="-liconv"
> %{_mingw32_configure}
> 
> Is it acceptable like that?

Could you post a config.log somewhere which can't find the iconv
library?

> 3) Should I mark %{_mingw32_sysconfdir}/opensc.conf as %config? Rpmlint
> spits out an error, because it doesn't like config files in /usr.

I think that the %config directive should be used here and that the
rpmlint warning should be ignored, but maybe the other people on this
list have a different opinion about that.

> 4) Rpmlint also says the following, but I guess it is harmless and can
> be ignored:
> mingw32-opensc.noarch: E: script-without-shebang
> /usr/i686-pc-mingw32/sys-root/mingw/sbin/opensc-install.bat
> mingw32-opensc.noarch: E: wrong-script-end-of-line-encoding
> /usr/i686-pc-mingw32/sys-root/mingw/sbin/opensc-install.bat
> mingw32-opensc.noarch: E: script-without-shebang
> /usr/i686-pc-mingw32/sys-root/mingw/bin/cardos-info.bat
> mingw32-opensc.noarch: E: wrong-script-end-of-line-encoding
> /usr/i686-pc-mingw32/sys-root/mingw/bin/cardos-info.bat

These can all the ignored. The wrong-script-end-of-line-encoding is
caused by the fact that Win32 uses \r\n for newlines and UNIX uses just
\n for newlines. Leaving those files as is shouldn't cause any
side-effects.

> 5) For some reason Firefox refuses to load opensc-pkcs11.dll as a
> security plugin. I have no idea how to resolve that but I think it isn't
> a showstopper.

You might want to open the .dll using Dependency Walker (just Google for
it). With this program you can see what functions are exported from
the .dll. If no functions are exported then Firefox won't be able to
load the plugin and you might want to review the linker flags.

> 6) I'd need a sponsor.

Sorry, can't help you with that..

Regards,

Erik van Pienbroek