On Mon, 2009-10-26 at 21:34 +0100, Ralf Wildenhues wrote:
3) The pressing issue that Matěj complained about was when configure
fails to detect all libraries, because all of them have a different
calling convention. Right?
The situation that I have encountered the case of cross-compilation.
* Matěj Týč wrote on Sun, Oct 25, 2009 at 03:05:26PM CET:
There is one big issue with AC_SEARCH_LIBS: If you use a different
calling convention than cdecl (like stdcall, but I don't know, they've
just told me), you will get unresolved symbols if you try to link
without a proper include file
On Fri, 2009-10-23 at 12:36 +0900, mpsuz...@hiroshima-u.ac.jp wrote:
* Their custom built library is not used, the system's is.
Indeed. It might be popular when default pkg-config prefix
is differnt from the prefix that users install their own
libraries. Have you experienced the troubles
On Sun, 2009-10-25 at 11:07 -1000, William Pursell wrote:
Alfred M. Szmidt wrote:
pkg-config is broken because it checks for the existance of
libraries, and not for the features that are required for the
program to run.
It does not even check for the existence of
On Mon, 2009-10-26 at 12:28 +1100, Russell Shaw wrote:
William Pursell wrote:
Alfred M. Szmidt wrote:
pkg-config is broken because it checks for the existance of libraries,
and not for the features that are required for the program to run.
It does not even check for the existence of
Matěj,
On 10/25/2009 8:05 AM, Matěj Týč wrote:
There is one big issue with AC_SEARCH_LIBS: If you use a different
calling convention than cdecl (like stdcall, but I don't know, they've
just told me), you will get unresolved symbols if you try to link
without a proper include file (or something
Hello,
* John Calcote wrote on Mon, Oct 26, 2009 at 05:46:07PM CET:
On 10/25/2009 8:05 AM, Matěj Týč wrote:
There is one big issue with AC_SEARCH_LIBS: If you use a different
calling convention than cdecl (like stdcall, but I don't know, they've
just told me), you will get unresolved symbols
* Bob Friesenhahn wrote on Sat, Oct 24, 2009 at 06:33:18PM CEST:
On Sat, 24 Oct 2009, Peter Johansson wrote:
Is there anything conceptually stopping us from writing a new
AC_LINK_IFELSE that links using libtool? That would make life
easier and avoid problems that only occur in configure and
Alfred M. Szmidt wrote:
pkg-config tries to solve an important problem, but it does so in the
wrong way. pkg-config checks for an exact library name,
PKG_CHECK_MODULES does not check for a library name at all,
but for the name of the .pc file. This gives the administrator
On Thu, 2009-10-22 at 11:44 -0700, Murray S. Kucherawy wrote:
What's the current general wisdom on using the pkg-config extensions?
I presume there's a reason they've not been incorporated into basic
autoconf, so I'm keen to learn what common practices there are toward
adopting it into
Alfred M. Szmidt wrote:
pkg-config is broken because it checks for the existance of libraries,
and not for the features that are required for the program to run.
It does not even check for the existence of libraries.
It checks for the existence of a .pc file and assumes
that the user (or
pkg-config is broken because it checks for the existance of
libraries, and not for the features that are required for the
program to run.
It does not even check for the existence of libraries.
It checks for the existence of a .pc file and assumes
that the user (or
Alfred M. Szmidt wrote:
pkg-config is broken because it checks for the existance of
libraries, and not for the features that are required for the
program to run.
It does not even check for the existence of libraries.
It checks for the existence of a .pc file and assumes
William Pursell wrote:
Alfred M. Szmidt wrote:
pkg-config is broken because it checks for the existance of libraries,
and not for the features that are required for the program to run.
It does not even check for the existence of libraries.
It checks for the existence of a .pc file and
And please, don't say about Linux has interlibrary dependency for
shared libraries. First at all, not all libraries are shared
(even under Linux). Second, Linux is not only one flavor of Unix.
Linux is a kernel, the operating system you are refering to is called
GNU or in conjuction
pkg-config tries to solve an important problem, but it does so in the
wrong way. pkg-config checks for an exact library name,
PKG_CHECK_MODULES does not check for a library name at all,
but for the name of the .pc file. This gives the administrator
one extra level of
Alfred M. Szmidt wrote:
pkg-config tries to solve an important problem, but it does so in the
wrong way. pkg-config checks for an exact library name,
PKG_CHECK_MODULES does not check for a library name at all,
but for the name of the .pc file. This gives the administrator
On Fri, 23 Oct 2009, John Calcote wrote:
If your project uses libxml's API, then you as the maintainer should be very
aware of requisite dependencies of that library. The AC_CHECK_LIB macro
accepts a fifth argument, other-libraries, which is a whitespace-separated
list of dependent libraries
Bob Friesenhahn wrote:
In this case life would be better if all libraries had a .la file
and if Autoconf used libtool type functionality (e.g. consult the .la
files) as part of its testing.
Is there anything conceptually stopping us from writing a new
AC_LINK_IFELSE that links using libtool?
On Sat, 24 Oct 2009, Peter Johansson wrote:
Bob Friesenhahn wrote:
In this case life would be better if all libraries had a .la file and if
Autoconf used libtool type functionality (e.g. consult the .la files) as
part of its testing.
Is there anything conceptually stopping us from writing a
On Fri, 23 Oct 2009, mpsuz...@hiroshima-u.ac.jp wrote:
The most popular scenario I think is: the pkg-config
itself is bundled to the system (/usr/bin/pkg-config etc)
but the users install their own libraries to non-system
directory (e.g. /usr/local/xxx), and the users slipped
to set
Bob Friesenhahn wrote:
Configure scripts which trust pkg-config include and library paths and
simpy concatenate them together (often in some random order) cause big
problems for users since the user has no control over the paths used.
I don't understand the comment about random order. The
On Fri, 23 Oct 2009, William Pursell wrote:
Configure scripts which trust pkg-config include and library paths and
simpy concatenate them together (often in some random order) cause big
problems for users since the user has no control over the paths used.
I don't understand the comment about
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt a...@gnu.org wrote:
The way is to simply not use pkg-config, and use AC_CHECK_* functions
to find what is needed; and let the user specify where/what, using
*FLAGS.
Can I ask hard to me and seems easy to you question:
how I can detect using
Hi Andrew,
On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidta...@gnu.org wrote:
The way is to simply not use pkg-config, and use AC_CHECK_* functions
to find what is needed; and let the user specify where/what, using
*FLAGS.
Can I ask
John Calcote john.calc...@gmail.com writes:
If your project uses libxml's API, then you as the maintainer should
be very aware of requisite dependencies of that library. The
AC_CHECK_LIB macro accepts a fifth argument, other-libraries, which is
a whitespace-separated list of dependent
What's the current general wisdom on using the pkg-config extensions? I
presume there's a reason they've not been incorporated into basic autoconf, so
I'm keen to learn what common practices there are toward adopting it into
people's builds (or avoiding it).
Cheers,
-MSK
-Original Message-
From: autoconf-bounces+msk=cloudmark@gnu.org [mailto:autoconf-
bounces+msk=cloudmark@gnu.org] On Behalf Of Ben Pfaff
Sent: Thursday, October 22, 2009 12:31 PM
To: autoconf@gnu.org
Subject: Re: pkg-config wisdom
I imagine that pkg-config has not been
On Thu, Oct 22, 2009 at 14:31, Ben Pfaff b...@cs.stanford.edu wrote:
I imagine that pkg-config has not been integrated into Autoconf
because it does not fit well into the Autoconf philosophy.
I use pkg-config quite heavily in one of my projects, I'm just
wondering is there a more autoconf way
On Thu, 2009-10-22 at 11:44 -0700, Murray S. Kucherawy wrote:
What's the current general wisdom on using the pkg-config extensions?
I presume there's a reason they've not been incorporated into basic
autoconf, so I'm keen to learn what common practices there are toward
adopting it into
Although pkg-config is useful in some cases, I agree with
others' negative evaluation against the idea to builtin
pkg-config support of autoconf. I want autoconf to keep
the library detection without pkg-config.
On Fri, 23 Oct 2009 09:48:30 +0800
Tim Post e...@echoreply.us wrote:
I have
The most popular scenario I think is: the pkg-config
itself is bundled to the system (/usr/bin/pkg-config etc)
but the users install their own libraries to non-system
directory (e.g. /usr/local/xxx), and the users slipped
to set PKG_CONFIG_PATH manually.
Definitely very useful, especially in
32 matches
Mail list logo