compatibility [u]

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

Re: compatibility [u]

Nils Larsch
Stef Hoeben wrote:
...
>> And about the sc_random call in this function:
>> why is it really necessary ? The openssl random number generator should
>> , when it is initialized, query the typical system sources for
>> random data (afaik the same does scrandom).
>
>
> Hm, if openssl gathers enough randomness from itself on all platforms
> then the call to the smart card indeed wouldn't be needed. (OTOH, openssl

I would keep the smartcard call (after all it's smartcard pkcs11 lib). I
was more thinking about the scrandom call.

> allows to add an extra random seed, but that's probably for the paranoid?)

aren't we paranoid ?

...
>> being pedantic that's what I would naively expect a pkcs11 lib
>> should do (of course this would be terrible slow but a pkcs11
>> library should not patronize the user). This is just my personal
>> opinion (and I would like to hear more opinions).
>
>
> Guess a pseudo-random stream derived from 20 random bytes is
> almost as good as 10000 random bytes (using a good algo of course).

depends, if we promise to give 10000 hardware generated random bytes
(by supplying the appropriate pkcs11 func) and give 'only' software
generated random numbers (where the PRNG was seeded with card random
data) it might not be good enough.

> IMHO a user want random bytes quickly...

well, but if the hardware device doesn't support random number
generation (or it doesn't support it in a manner the user requires
, for example not fast enough) he needs another source of random
data. It should not be the task of a pkcs11 lib to work around
missing features of a hardware device.

> In the other case, she would
> have to get a separate pseudo-random generator if she wants much
> random data because our pkcs11 lib will be too slow..

btw: which applications actually uses the pkcs11 random number
function ?

Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility [u] with AM_OPENCT macro

Roumen Petrov-2
In reply to this post by Andreas Jellinghaus-2
Hi Andreas,

please find attached files:
- "opensc-trunk-20050707-extra.tar.bz2" - contain new files and should be extracted in source dir;
- "opensc-trunk-20050707.diff.bz2" - diff to existing files.
The proposed modification use macro AC_LIB_HAVE_LINKFLAGS defined in lib-link.m4 from gettext.
The modification add options --with-libopenct-prefix=DIR and --without-libopenct-prefix can be used to
build without OpenCT library.

In additional file "openct-trunk-20050707.diff.bz2" is attached with proposed changes to OpenCT - mostly to install openct.m4.

OpenCT and OpenSC use subdirectory "aclocal" to store m4 macro files,
but default (most common) location for m4 files is subdirectory "m4".


>>[SNIP]
>>
>>Ok, how should we proceed? I think it might be best to simply
>>do those changes to configure.ac and then seek real world experience,
>>whether we need special code, or whether the generic pkg.m4 code works
>>fine for us.
>>
>
>
> writen from scratch:
> May be an existing macro can be used - AC_LIB_LINKFLAGS([XXXX])
> (Note I'm not sure about name).
> It should be defined in liblink.m4 (?).
> This macro will add option --with-libXXXX-prefix to configure
> script and will set some variables (may be LIBXXXX INCXXXX ?).
>
> I will try to find it and to propose a patch - may be first for libopenct.
>
Comments welcome,
Roumen



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

opensc-trunk-20050707-extra.tar.bz2 (6K) Download Attachment
opensc-trunk-20050707.diff.bz2 (2K) Download Attachment
openct-trunk-20050707.diff.bz2 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compatibility [u]

Stef Hoeben
In reply to this post by Nils Larsch

> btw: which applications actually uses the pkcs11 random number
> function ?

Mozilla adds a random seeds before telling the pkcs11 to do keypairgen
(but doesn't use the randomness itself), I believe.

No idea about other apps.

Cheers,
Stef

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility [u]

Nils Larsch
Stef Hoeben wrote:
>
>> btw: which applications actually uses the pkcs11 random number
>> function ?
>
>
> Mozilla adds a random seeds before telling the pkcs11 to do keypairgen

useless in our case (and pretty useless anyway)

> (but doesn't use the randomness itself), I believe.
>
> No idea about other apps.

as smartcards are normally used for signing or key decryption
I don't think/hope that a smartcard pkcs11 is supposed to
supply a random data source.

Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Andreas Jellinghaus-2
In reply to this post by Roumen Petrov-2
sorry, but I still don't get it.

how is this superior to pkg-config?

pkg-config is a standard tool, everyone knows it.
pkg-config has version checks build in, your patch hasn't.
pkg-config is more flexible, as the caller defines the
variable-prefix and any HAVE_* definition.
pkg-config allows configure to optionaly link with some
code. your code seems to always fail (AC_MSG_ERROR
aborts the configure script, right?)

also there are minor issues (why a new dir m4/? isn't
aclocal enought? why not use autoreconf? I thought it
was an improvement that I don't need to know the correct
order? why specify automake "foreign" flag in bootstrap,
when it is already in Makefile.am?), but I still don't
get what our own macro buys us versus using pkg-config.

I understand pkg-config only checks for the *.pc file
while your code does a simple test (compile/link only?
also run?), but I wonder why we can't do that test on
top of pkg-config with all the flexibility it offers.

also I can't find any documentation on AC_LIB_HAVE_LINKFLAGS,
at least a zgrep on my info dir returned nothing.
dpkg tells me it is defined in a file from gettext?

Also I don't understand how the m4 macro from openct ends up
in opensc source code m4/ directory.

> The proposed modification use macro AC_LIB_HAVE_LINKFLAGS defined in
> lib-link.m4 from gettext. The modification add options
> --with-libopenct-prefix=DIR and --without-libopenct-prefix can be used to
> build without OpenCT library.

"-prefix"? isn't it usaly either --with-foo= or --with-foo-includes=
--with-foo-libs=  or something like that?

as far as I see all gnome projects and many others as well are using
pkg-config these days. I already know that one. my current experience
is: it works fine. so to use something different than the common standard
we should have a reason?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Roumen Petrov-2
Hi Andreas,

please find answers/questions in quoted text.

Andreas Jellinghaus [c] wrote:
> sorry, but I still don't get it.
>
> how is this superior to pkg-config?
>
> pkg-config is a standard tool, everyone knows it.
autoconf is standard, 99% of projects use it.
pkg-config define cflags but don't define cppflags.
autoconf use cflags and cppflags.
pkg-config mix compiler and preprocessor flags,
i.e. it isn't designed to work with autoconf.

> pkg-config has version checks build in, your patch hasn't.
in general we cannot use version check to find a library.
let a system is with libXXXX-1.2.3-...-NNN.i386.rpm.
to suppose that on this system is installed version 1.2.3 of libXXXX
is wrong in general. the installed lib is 1.2.3 or later(!).
usually vendors keep version number and increase only NNN.
the updated library can be similar to 1.2.4 (or later) but
without increase of version number.

i wonder about this openssl version check in
current configure script, bet let discuss further
it other thread.


> pkg-config is more flexible, as the caller defines the
> variable-prefix and any HAVE_* definition.
this sentence is not clear, could please explain.

> pkg-config allows configure to optionaly link with some
> code. your code seems to always fail
really! definitely no!
lets look the openct.m4 code again. it contain an extra
check for header file openct/openct.h, to verify
correctness of preprocessor flags.

> (AC_MSG_ERROR
> aborts the configure script, right?)
yes

>
> also there are minor issues (why a new dir m4/? isn't
> aclocal enought?
m4 is more standard/common.

> why not use autoreconf?
autoreconf do not work well in all cases.

> I thought it
> was an improvement that I don't need to know the correct
> order? why specify automake "foreign" flag in bootstrap,
> when it is already in Makefile.am?), but I still don't
> get what our own macro buys us versus using pkg-config.
>
> I understand pkg-config only checks for the *.pc file
> while your code does a simple test (compile/link only?
the current opensc code (in subversion) do same.
the whole current macro code is reduced to one call:
AC_LIB_HAVE_LINKFLAGS(openct,[],[#include <openct/openct.h>],
[ct_reader_connect(0);])
proposed macro file check preprocessor flags too:
AC_CHECK_HEADERS([openct/openct.h])


note AC_LIB_HAVE_LINKFLAGS should not include
...[#include <openct/openct.h>]...

I borrow it from current configure script:
AC_TRY_LINK([#include <openct/openct.h>],[ct_reader_connect(0);]....
, but this is incorrect.
It is not clear failure reason - missing library function or header file.

Correct one is:
AC_LIB_HAVE_LINKFLAGS(openct,[],[],
[char ct_reader_connect(); ct_reader_connect(0);])


> also run?),
when is necessary. note cross compiling.

> but I wonder why we can't do that test on
> top of pkg-config with all the flexibility it offers.
>
> also I can't find any documentation on AC_LIB_HAVE_LINKFLAGS,
> at least a zgrep on my info dir returned nothing.
> dpkg tells me it is defined in a file from gettext?
yes, AC_LIB_HAVE_LINKFLAGS and file config.rpath are from gettext.

>
> Also I don't understand how the m4 macro from openct ends up
> in opensc source code m4/ directory.
why not ?
openct.m4 should be part from openct source - see
the third diff "openct-trunk-20050707.diff".

opensc can contain it too (aclocal -I path_to_opensc_local_m4_macros).
source tarbal from some project contains all m4 macro files in use.
as example opensc may contain libtool.m4 and others.
since libtool.m4 is common it is not in openct/sc source,
but acx_pthread.m4 is part of openct/sc source.
note that openct/sc contain different versions of pkg.m4.

>
>>The proposed modification use macro AC_LIB_HAVE_LINKFLAGS defined in
>>lib-link.m4 from gettext. The modification add options
>>--with-libopenct-prefix=DIR and --without-libopenct-prefix can be used to
>>build without OpenCT library.
>
>
> "-prefix"? isn't it usaly either --with-foo= or --with-foo-includes=
> --with-foo-libs=  or something like that?
>
> as far as I see all gnome projects and many others as well are using
> pkg-config these days.
that's right. it is redhat command/request. before two(three?) years redhat
order some project (gnome of course) to switch to pkg-config.

> I already know that one. my current experience
> is: it works fine.  so to use something different than the common standard
> we should have a reason?
what is standard: GNU autoconf, old, proven to work or new pkg-config
incompatible with autoconf at all ?

>
> Regards, Andreas

Regards,
Roumen
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Wouter Verhelst
On Mon, Jul 11, 2005 at 12:34:44AM +0300, Roumen Petrov wrote:

> Hi Andreas,
>
> please find answers/questions in quoted text.
>
> Andreas Jellinghaus [c] wrote:
> >sorry, but I still don't get it.
> >
> >how is this superior to pkg-config?
> >
> >pkg-config is a standard tool, everyone knows it.
> autoconf is standard, 99% of projects use it.
> pkg-config define cflags but don't define cppflags.
> autoconf use cflags and cppflags.
> pkg-config mix compiler and preprocessor flags,
> i.e. it isn't designed to work with autoconf.

This isn't true. For starters, autoconf isn't what you actually build
your software with; either a self-written Makefile.in or a Makefile.am
is.

Second, while autoconf does indeed preprocess files in the header
include tests, it doesn't actually a problem if the flags for
preprocessing include compile-specific stuff such as -g or -O*. It'll
all work just fine.

So I don't see what your problem in using pkg-config is, really. A lot
of projects use it (including OpenSC) and it works just fine.

> >pkg-config has version checks build in, your patch hasn't.
> in general we cannot use version check to find a library.
> let a system is with libXXXX-1.2.3-...-NNN.i386.rpm.
> to suppose that on this system is installed version 1.2.3 of libXXXX
> is wrong in general. the installed lib is 1.2.3 or later(!).
> usually vendors keep version number and increase only NNN.
> the updated library can be similar to 1.2.4 (or later) but
> without increase of version number.

If any vendor does that, it is braindead and should be hit with a
cluebat. Preferably a titanium one. Preferably very hard. Preferably ...

Well, you get the idea.

Even if they are that broken, the version of the package is not in the
least important for the pkg-config version test; the pkg-config .pc file
is. For example, my /usr/lib/pkgconfig/pango.pc contains the following:

---
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

pango_module_version=1.4.0

Name: Pango
Description: Internationalized text handling
Version: 1.8.1
Requires: glib-2.0,gobject-2.0,gmodule-no-export-2.0
Libs: -L${libdir} -lpango-1.0
Cflags: -I${includedir}/pango-1.0
---

Now if you run 'pkg-config --modversion pango', you'll get '1.8.1' --
the contents of the 'Version' line. There are also three options to the
pkg-config script that were especially written for autoconf tests:
'--atleast-version=', '--max-version=', and '--exact-version='. And
apart from that, the .pc file contains a crude dependency system, so if
I don't have glib-2.0 .pc files (or one of the other) on my system,
pkg-config will claim pango isn't even installed on my system. As it
should.

> >pkg-config is more flexible, as the caller defines the
> >variable-prefix and any HAVE_* definition.
> this sentence is not clear, could please explain.

Please see the comments in the /usr/share/aclocal/pkg.m4 file.

> >also there are minor issues (why a new dir m4/? isn't
> >aclocal enought?
> m4 is more standard/common.

aclocal is pretty standard as well. Besides, it already exists. Having
two separate directories for the same thing isn't really all that clear,
is it?

> >why not use autoreconf?
> autoreconf do not work well in all cases.

I haven't ever seen that, except when there was a bug. Could you give an
example?

[...]
> >also I can't find any documentation on AC_LIB_HAVE_LINKFLAGS,
> >at least a zgrep on my info dir returned nothing.
> >dpkg tells me it is defined in a file from gettext?
> yes, AC_LIB_HAVE_LINKFLAGS and file config.rpath are from gettext.

So, you're suggesting to depend on gettext even though gettext isn't
actually used in OpenSC or OpenCT?

Isn't that pretty silly?

[...]
> >"-prefix"? isn't it usaly either --with-foo= or --with-foo-includes=
> >--with-foo-libs=  or something like that?
> >
> >as far as I see all gnome projects and many others as well are using
> >pkg-config these days.
> that's right. it is redhat command/request. before two(three?) years redhat
> order some project (gnome of course) to switch to pkg-config.

I don't think any distribution can 'order' any project to do anything.
My experience from Debian is that while you can make requests to do
anything in a specific way, in the end it's the upstream developer, not
the distributor, who makes this kind of decision.

In other words, I don't believe the GNOME people made the decision to go
with pkg-config because they thought it was a bad idea.

> >I already know that one. my current experience
> >is: it works fine.  so to use something different than the common standard
> >we should have a reason?
> what is standard: GNU autoconf, old, proven to work or new pkg-config
> incompatible with autoconf at all ?

pkg-config is not in the least incompatible with autoconf.

The unavailability of an optional feature - one which is not only
mostly useless, but also very much unused by most projects - is hardly a
reason to call something 'incompatible'.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Roumen Petrov-2
[SNIP]
>> >pkg-config is more flexible, as the caller defines the
>> >variable-prefix and any HAVE_* definition.
>> this sentence is not clear, could please explain.
>
> Please see the comments in the /usr/share/aclocal/pkg.m4 file.

Did you and Andreas think that macro AC_LIB_HAVE_LINKFLAGS don't define HAVE_* and
*FLAGS ? Could, please check again
and see AC_LIB_HAVE_LINKFLAGS comment.

AC_LIB_HAVE_LINKFLAGS(XXXX, ...) define HAVE_LIBXXXX and ...
HAVE_LIB* in this case is more precisely then HAVE_*.

1.) HAVE_OPENCT - openct is expected to be a function or binary executable or ...
may be can be everything :-\
2.) HAVE_LIBOPENCT - openct is a library.


>> >also there are minor issues (why a new dir m4/? isn't
>> >aclocal enought?
>> m4 is more standard/common.
>
> aclocal is pretty standard as well. Besides, it already exists. Having
> two separate directories for the same thing isn't really all that clear,
> is it?

:-\


[SNIP]
>> what is standard: GNU autoconf, old, proven to work or new pkg-config
>> incompatible with autoconf at all ?
>
> pkg-config is not in the least incompatible with autoconf.

ok :-). until pkg-config mix compiler and preprocessor flags it will be
partially compatible with autoconf.


> The unavailability of an optional feature - one which is not only
> mostly useless, but also very much unused by most projects - is hardly a
> reason to call something 'incompatible'.

a quick search in openssh bugzilla http://bugzilla.mindrot.org/ show
a number of bugs related to CPPFLAGS/CFLAGS/openssl, as example
bug numbers: 77, 168, 601, 933.


Regards,
Roumen

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Andreas Jellinghaus-2
From my point of view pkg-config is good enough.
I know, it is hard to argue against "good enough",
but we want to spend our time on the smart card
problems and not on some other areas.

And so far I see your code as different: some
new additional features, some features less.
pkg-config is used by everyone and that is a
big fat advantage, as I don't want to dig into
those issues too much.

[flags etc.]
with AM_OPENCT it is already decided: the result will be OPENCT_CPPFLAGS
and OPENCT_LDFLAGS and HAVE_LIBOPENCT. with pkg-config macro (see manpage)
I decide what it will be calles and pkg-config appends _CFLAGS and _LIBS.
Also I can have my own code for both cases (found/not found). Even more
pkg-config checks version, knows about dependencies, and can cummulate
several checks into one combined detection code, if I want.

Also I simply like this feature: I don't need to document how to link
with openct. Telling people to use "#include <openct/foo.h>" and use
pkgconfig with "openct" is all I need. With your macro the documentation
would be longer, as we have to explain how to copy the m4 file, how
to use it, which variables will be set, how to check for versions etc.

In general the option which is easier to document might be better.

> ok :-). until pkg-config mix compiler and preprocessor flags it will be
> partially compatible with autoconf.

I don't care. it does not modify either LIBS or CFLAGS or anything.
it is up to me what I do with those variables called OPENCT_CFLAGS
and OPENCT_LIBS and of course I can do things like
CPPFLAGS=$(CPPFLAGS) $(OPENCT_CFLAGS)
if I prefer it that way.

but pkg-config fits perfectly in the libtools/automake/autoconf
world, and that is also why your example with openssh is weak:
they neither use automake nor libtool.

simple things should be easy, hard things should be possible.
I think pkg-config fits this quite well. you can still use your
own sophisticated macro in your own project using openct/sc/...
but I think opensc is better of using openct via pkg-config,
and I think we do good in recommending pkg-config as the best
way to use openct and opensc(*) to our users, because it is a
simply way that works well and is easy to debug.

Regards, Andreas
(*) well, users should better use opensc-pkcs11.so or some lib
on top of opensc, but that is a different story.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Martin Preuss-2
Hi,

On Tuesday 12 July 2005 00:27, Andreas Jellinghaus [c] wrote:
[...]
> Also I simply like this feature: I don't need to document how to link
> with openct. Telling people to use "#include <openct/foo.h>" and use
> pkgconfig with "openct" is all I need. With your macro the documentation
> would be longer, as we have to explain how to copy the m4 file, how
> to use it, which variables will be set, how to check for versions etc.
[...]

Well, just my two cents (as someone who feels quite comfortable with AM
macros): You don't have to tell the user to copy this file. Just do what pkg
does with its .pc-files: Install it (i.e. install a "opensc.m4" file, like
most other projects do).

After that it is as easy as using pkg-config, just the macro name is
different...
And if you comply to the commonly used conventions about variable names used
in AM macros you don't have to explain too much...

Generally I like AM macros better than pkg-config because automake is used
anyway so there is no need to have an additional package (->pkg-config), but
that's just my personal feeling.


regards
Martin

--
"Things are only impossible until they're not"

AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: compatibility with AM_OPENCT macro [u]

Roumen Petrov-2
In reply to this post by Andreas Jellinghaus-2
Hi Andreas,


I cannot agree with you request: "....
- require pkg-config to find openct, openssl, pcsc-lite
   (all of them provide *.pc files, and that would makes the
    long and horrible autoconf code quite simple)
...."
configure script to use pkg-config only.
I propose one sample how to make current script simple.
I'm sure that someone can propose different solution.

After review of the mail thread I cannot found
well grounded argument.

You argue against current script too - why the script define HAVE_* :) .
Please, reread you arguments - all is poor.


>>From my point of view pkg-config is good enough.
> I know, it is hard to argue against "good enough",
> but we want to spend our time on the smart card
> problems and not on some other areas.
>
> And so far I see your code as different: some
> new additional features, some features less.
> pkg-config is used by everyone and that is a
> big fat advantage, as I don't want to dig into
> those issues too much.
>
> [flags etc.]
> with AM_OPENCT it is already decided: the result will be OPENCT_CPPFLAGS
> and OPENCT_LDFLAGS and HAVE_LIBOPENCT. with pkg-config macro (see manpage)
> I decide what it will be calles and pkg-config appends _CFLAGS and _LIBS.
> Also I can have my own code for both cases (found/not found). Even more
> pkg-config checks version, knows about dependencies, and can cummulate
> several checks into one combined detection code, if I want.
>
> Also I simply like this feature: I don't need to document how to link
> with openct. Telling people to use "#include <openct/foo.h>" and use
> pkgconfig with "openct" is all I need. With your macro the documentation
> would be longer, as we have to explain how to copy the m4 file, how
> to use it, which variables will be set, how to check for versions etc.
>
> In general the option which is easier to document might be better.
>
>> ok :-). until pkg-config mix compiler and preprocessor flags it will be
>> partially compatible with autoconf.
>
> I don't care. it does not modify either LIBS or CFLAGS or anything.
> it is up to me what I do with those variables called OPENCT_CFLAGS
> and OPENCT_LIBS and of course I can do things like
> CPPFLAGS=$(CPPFLAGS) $(OPENCT_CFLAGS)
> if I prefer it that way.
>
> but pkg-config fits perfectly in the libtools/automake/autoconf
> world, and that is also why your example with openssh is weak:
> they neither use automake nor libtool.
>
> simple things should be easy, hard things should be possible.
> I think pkg-config fits this quite well. you can still use your
> own sophisticated macro in your own project using openct/sc/...
> but I think opensc is better of using openct via pkg-config,
> and I think we do good in recommending pkg-config as the best
> way to use openct and opensc(*) to our users, because it is a
> simply way that works well and is easy to debug.
>


This reason is "strong" :-D : "....With your macro the documentation
would be longer, as we have to explain how to copy the m4 file, how
to use it, which variables will be set, how to check for versions etc. ..."
What is this? Is a new joke? I cannot beli&#1077;ve.


pkg-config is funny tools - one more program to bring into dependency hell.


Topic closed,
Roumen

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
12