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-compilati
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 sy
On Mon, 2009-10-26 at 10:46 -0600, John Calcote wrote:
> 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 s
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 l
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 th
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 existen
On Fri, 2009-10-23 at 09:56 -0500, Bob Friesenhahn wrote:
> This is not to say that pkg-config doesn't work well; it is just best
> for a carefully built and well integrated environment rather than one
> incrementally put together over time.
That is very likely the best way to explain it. I may
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 troubl
* 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
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 assumes
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 as
> 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 administr
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 ad
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.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
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 peop
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 administra
* 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
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
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 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
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
> 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 indirect
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 w
John Calcote 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 libraries (actually
> comm
Hi Andrew,
On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt 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
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt 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 AC_CHECK_* 2nd
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 "
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
one extra level
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". Th
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 PKG_CONFIG_P
> 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, especiall
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 wrote:
>I have experienced many issues us
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 pe
> 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 of performing the same
task as I constantly run into
"Murray S. Kucherawy" writes:
>> I imagine that pkg-config has not been integrated into Autoconf
>> because it does not fit well into the Autoconf philosophy.
>
> Right, so I'm wondering what that philosophy is, I suppose.
Usually Autoconf tests for particular features, by attempting to
compile
On Thu, Oct 22, 2009 at 14:31, Ben Pfaff 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 of performing the
> -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
"Murray S. Kucherawy" writes:
> 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
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
__
39 matches
Mail list logo
