Re: TODO
On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: > Albert Chin wrote: > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote: > > > > Ick. Libtool is about portably building/using libraries. Why can't we > > leave it at that? > > But linking against installed libraries using the correct -L and -l flags > *is* part of portably building/using libraries! ;-) > > Haven't thought through the -I thing yet though... maybe that doesn't > belong in libtool... maybe we could provide a macro that can intuit > include directories from .la locations... I dunno... > The most common arrangement is libraries in /usr/lib and includes in /usr/include/- ... so not easy to intuit like that. Scot -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
> On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > It's just that their functionality
> > intersects and partially conflicts.
>
> how?
>
> pkg-config is used to give basic information about installed packages.
> libtool is used to build libraries.
>
> pkg-config is used in configure scripts.
> libtool is used in Makefiles.
>
> yes, it's possible to use constructs like
>
> foo.so: foo.o
> ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
>
> in Makefiles, but this is not overlap in a conflicting way.
>
This is actually exactly what happens when you use pkg-config in a
configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
you arrange for the contents of that to be added to the link line --
just like you say here.
The conflict is that pkg-config not only provides the -L and -l needed
to the library, but also those for all of its dependency libraries.
So does Libtool.
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
It would be far neater if they could co-operate with this.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > It doesn't care about package versions, but it has to care about library > > versions and paths to libraries. > > again, functionality provided by pkg-config. > > I am contesting the claim "Libtool already has all the information > it needs". > I actually tend to think we should look at this the other way ... if we could expose the information Libtool has to other tools, pkg-config could defer to Libtool. So rather than libtool taking over pkg-config, we make them work together. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
誰ã§ãåºä¼ãããããããªã³ã¯éã§ãã
âÁÏèoï¢ÌêàÍTCgIÑ©çB oï¢TCg̨©ßîñª¢ÁÏ¢ÌNðWßܵ½B «Ú×ÍR`©ç« http://www.i67.jp/~link/ ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On 2004-11-14T08:50-, Scott James Remnant wrote: ) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: ) > Haven't thought through the -I thing yet though... maybe that doesn't ) > belong in libtool... maybe we could provide a macro that can intuit ) > include directories from .la locations... I dunno... ) The most common arrangement is libraries in /usr/lib and includes ) in /usr/include/- ... so not easy to intuit like that. That appears to be common of GNOME components, but does not appear to be common in the general case. (Automake's includedir location defaults to prefix/include and its pkgincludedir location defaults to includedir/name, not includedir/name-version.) The following packages on my FC4 machine have versioned pkgincludedirs: apr atk at-spi bonobo dbus devhelp eel2 evolution evolution-data-server gail gal gdk-pixbuf gedit gimp glib glib2 gnome-desktop gnome-keyring gnome-libs gnome-mag gnome-panel gnome-speech gnome-vfs gnome-vfs2 gnopernicus gstreamer gtk+ gtk2 gtkhtml gtkhtml2 gtkhtml3 gtksourceview gtkspell howl libart_lgpl libbonobo libbonoboui libcroco libgal2 libglade libglade2 libgnome libgnomecanvas libgnomecups libgnomeprint22 libgnomeprintui22 libgnomeui libgsf libgtop2 libIDL librsvg2 libsoup libwnck linc metacity ORBit ORBit2 ots pango startup-notification subversion Of that list, I believe only apr, ots, and subversion are not GNOME components. Also of that list, only the following did not appear to have .pc files installed: apr gnome-libs subversion Just as another point of data, the following packages on my FC4 machines have .pc files installed: aiksaurus aiksaurus-gtk alsa-lib atk at-spi audiofile bluez-libs bonobo dbh dbus devhelp eel2 esound evolution evolution-data-server fontconfig freetype fribidi gail gaim gal gamin gawk GConf GConf2 gedit gimp gkrellm glib glib2 gnome-applets gnome-bluetooth gnome-desktop gnome-icon-theme gnome-keyring gnome-mag gnome-media gnome-mime-data gnome-panel gnome-pilot gnome-python2 gnome-speech gnome-utils gnome-vfs2 gnopernicus gok gphoto2 gstreamer gstreamer-plugins gtk+ gtk2 gtk2-engines gtkhtml gtkhtml2 gtkhtml3 gtksourceview gtkspell hal howl ImageMagick imlib libao libart_lgpl libbonobo libbonoboui libbtctl libcroco libdv libexif libgal2 libgcj libgda libglade libglade2 libgnome libgnomecanvas libgnomecups libgnomedb libgnomeprint22 libgnomeprintui22 libgnomeui libgsf libgtop2 libIDL libidn libmusicbrainz libogg libpng libpng10 libraw1394 librsvg2 libsilc libsoup libuser libvorbis libwnck libwpd libxfce4mcs libxfce4util libxfcegui4 libxklavier libxml libxml2 libxslt linc metacity mozilla mozilla-nspr mozilla-nss nautilus nautilus-cd-burner neon NetworkManager openssl ORBit ORBit2 ots pango planner pygtk2 pyorbit qt rhythmbox shared-mime-info speex startup-notification valgrind vte xemacs-sumo xfce4-panel xfce-mcs-manager xffm xmlsec1 xmlsec1-openssl xorg-x11 Of this second list, most of them appear to be either a) GNOME components, b) GNOME-related/integrated software (gaim, ImageMagick), or c) software maintained by people who are also GNOME developers (*xml*). (The .pc file gawk installs is a README for "pc" versus "hpux" or "atari" :) I would be very interested in researching how Libtool can help with multilib builds. Other than that cause, however, I am not sure there exists a real demand (outside of GNOME) for the features PKGConfig offers that Libtool does not already provide. (My own machines without GNOME or even X installed only have .pc files for valgrind and/or openssl, and do not have PKGConfig installed. They do, however, have many .la files. On my machines with a C++ compiler installed, there is a g++-3 directory in /usr/include; on machines without, there are no versioned include directories.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ If nature has made you a giver, your hands are born open, and so is your heart. And though there may be times when your hands are empty, your heart is always full, and you can give things out of that. -- Frances Hodgson Burnett, Novelist ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: > They're both trying to deal with platforms like Solaris that don't have > a needed-following link loader. What does this mean? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Scott!
Scott James Remnant wrote:
On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
>On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
>
>>It's just that their functionality
>>intersects and partially conflicts.
>
>how?
>
>pkg-config is used to give basic information about installed packages.
>libtool is used to build libraries.
>
>pkg-config is used in configure scripts.
>libtool is used in Makefiles.
>
>yes, it's possible to use constructs like
>
>foo.so: foo.o
>${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
>
>in Makefiles, but this is not overlap in a conflicting way.
This is actually exactly what happens when you use pkg-config in a
configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
you arrange for the contents of that to be added to the link line --
just like you say here.
The conflict is that pkg-config not only provides the -L and -l needed
to the library, but also those for all of its dependency libraries.
That is a good point.
My main complaint about pkg-config is this: It is supposed to
make it easier to link with packages that have each been installed
to their own prefix (to support parallel installation of multiple
versions), but in fact it makes things much harder.
Real world example: I want to link against libgdiplus, which has a
dependency on cairo, so I ask it for the linkflags:
$ pkg-config --libs libgdiplus
Package libgdiplus was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgdiplus.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgdiplus' found
Fair enough, better tell it where libgdiplus lives:
$ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
Hmmm... so I have to tell it where cairo is again, even though I've
already specified where the cairo libs are when I linked gdiplus.
Luckily I remember which cairo I linked it against, otherwise it
would report the wrong flags:
$ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig:\
/opt/libcairo02/lib/pkgconfig pkg-config --libs libgdiplus
Package libpixman was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpixman.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpixman', required by 'cairo', not found
Err... so? How come I need to know what libraries cairo depends
on. I want to link against libgdiplus! Okay, I'll run ldd on
libcairo.so to make sure I get the right prefix:
$ ldd /opt/libcairo02/lib/libcairo.so | grep pixman.so
libpixman.so.1 => /opt/libpixman01/lib/libpixman.so.1
$ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig:\
/opt/libcairo02/lib/pkgconfig:\
/opt/libpixman01/lib/pkgconfig pkg-config --libs libgdiplus
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng', required by 'cairo', not found
Geez, here we go again:
$ ldd /opt/libcairo02/lib/libcairo.so | grep png.so
libpng.so.2 => /opt/libpng12/lib/libpng.so.2
$ PKG_CONFIG_PATH=/opt/libdgiplus10/lib/pkgconfig:\
/opt/libcairo02/lib/pkgconfig:\
/opt/libpixman01/lib/pkgconfig:\
/opt/libpng12/lib/pkgconfig pkg-config --libs libgdiplus
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'libpng', not found
Anyway, so we go around and around manually finding out the
entire tree of dependencies that will be pulled in by
libgdiplus, until we eventually arrive at this horror:
$ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig:\
/opt/libcairo02/lib/pkgconfig:\
/opt/libpixman01/lib/pkgconfig:\
/opt/libpng12/lib/pkgconfig:\
/opt/zlib11/lib/pkgconfig:\
/opt/libttf21/lib/pkgconfig:\
/opt/libtiff35/lib/pkgconfig:\
/opt/libjpeg6b/lib/pkgconfig:\
/opt/libungif41/lib/pkgconfig pkg-config --libs libgdiplus
So that it can tell me all the prefixes I just looked up
manually (big deal!):
-L/opt/libgdiplus10/lib -L/opt/libcairo02/lib \
-L/opt/libpixman01/lib -L/opt/libpng12/lib \
-L/opt/zlib11/lib -L/opt/libttf21/lib \
-L/opt/libtiff35/lib -L/opt/libjpeg6b/lib \
-L/opt/libungif41/lib -L/usr/X11R6/lib \
-lgdiplus -lgmodule-2.0 -ldl -lgthread-2.0 \
-lcairo -lm -lfreetype -ltiff -ljpeg -lungif \
-lglib-2.0 -lfontconfig -lpixman -lXrender -lX11 \
-lpng -lz
Hmmm... where did it get -lglib-2.0 and friends from, I
didn't specify those paths on PKG_CONFIG_PATH, maybe it
did do something to save me time after all?
$ ldd /opt/libgdiplus10/lib/libgdiplus.so | grep glib-2.0
libglib-2.0.so.0 => /opt/libglib24/lib/libglib-2.0.so.0
Err, no it gave me the wrong flags, so that I'll end up
linking against libglib-2.0 from the linker default search
path. Better go back and add those to the PKG_CONFIG_PATH
too, along with anything else they might depend on.
And so it goes on. Like I said, pkg-config is an aberration:
it makes it *harder* for me to link correctly :-( And worse,
if I try to li
Re: TODO
On Sun, 14 Nov 2004, Albert Chin wrote: On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: They're both trying to deal with platforms like Solaris that don't have a needed-following link loader. What does this mean? I assume that he is talking about ELF inherited dependencies. With inherited dependencies, libraries which were not specified at link time may appear in the output of `ldd' because one of the linked libraries does require other non-listed libraries. Recent versions of Solaris do inherit shared library dependencies. Probably Scott should have mentioned Linux instead since I recall a time (possibly as recent as Red Hat 5.0) when it did not inherit shared library dependencies. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 14 Nov 2004, Gary V. Vaughan wrote: My main complaint about pkg-config is this: It is supposed to make it easier to link with packages that have each been installed to their own prefix (to support parallel installation of multiple versions), but in fact it makes things much harder. Real world example: I want to link against libgdiplus, which has a dependency on cairo, so I ask it for the linkflags: $ pkg-config --libs libgdiplus Package libgdiplus was not found in the pkg-config search path. Perhaps you should add the directory containing `libgdiplus.pc' to the PKG_CONFIG_PATH environment variable No package 'libgdiplus' found Fair enough, better tell it where libgdiplus lives: $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. The system I use (Solaris based) uses three. There is one for the software that comes with the base system (under /usr)), one for "freeware" (under /usr/sfw), and one created by myself for locally installed packages (under /usr/local). The Gentoo Linux system I use has only two pkgconfig files. Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Bob! Bob Friesenhahn wrote: You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. Absolutely. But the point is that pkg-config is supposed to help with parallel installs, and it most certainly does not! The system I use (Solaris based) uses three. There is one for the software that comes with the base system (under /usr)), one for "freeware" (under /usr/sfw), and one created by myself for locally installed packages (under /usr/local). The Gentoo Linux system I use has only two pkgconfig files. pkgconfig directories, right? Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. You mean that the installed .pc files need to be altered by the user to give things a hope of linking? ;-) But seriously, why would you install a .pc using library, and then alter the installed .pc file? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
> You mean that the installed .pc files need to be altered by the
> user to give things a hope of linking? ;-)
Hate to chime in, but I always seem to have to add -Wl,-R... to the *.pc
files, so have not ended up being a fan of pkg-config. Unfortunately
it seems to crop up all over the place, and I keep reinventing ways of
getting libtool's ${wl} info into the foo.pc from foo.pc.in..
> But seriously, why would you install a .pc using library, and then
> alter the installed .pc file?
Because that's what comes in the source tar :-( and then the other
source tars' use pkg-config --libs (given up on glib and friends often)
Cheers,
Patrick
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
> On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
>
> > On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > > It's just that their functionality
> > > intersects and partially conflicts.
> >
> > how?
> >
> > pkg-config is used to give basic information about installed packages.
> > libtool is used to build libraries.
> >
> > pkg-config is used in configure scripts.
> > libtool is used in Makefiles.
> >
> > yes, it's possible to use constructs like
> >
> > foo.so: foo.o
> > ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
> >
> > in Makefiles, but this is not overlap in a conflicting way.
> >
> This is actually exactly what happens when you use pkg-config in a
> configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
> you arrange for the contents of that to be added to the link line --
> just like you say here.
yes, or I could just as easily hardcode
FOO_LIBS="-L/usr/local/lib -lfoo -lbar"
in configure.
so now, I'm not using pkg-config at all. it's not uncommon to see
such things. how would libtool deal with that?
> The conflict is that pkg-config not only provides the -L and -l needed
> to the library, but also those for all of its dependency libraries.
>
> So does Libtool.
how is that a conflict? would the case above be an irreconcilable
conflict?
> They're both trying to deal with platforms like Solaris that don't have
> a needed-following link loader.
>
> It would be far neater if they could co-operate with this.
libtool already scrutinizes the command line for relevant flags.
if libtool is so infinitely better than anything else at building
libraries, then why can't it simply drop irrelevant/duplicated
flags, and add the ones it needs?
--
<[EMAIL PROTECTED]>
>
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/libtool
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote: > On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > > > It doesn't care about package versions, but it has to care about library > > > versions and paths to libraries. > > > > again, functionality provided by pkg-config. > > > > I am contesting the claim "Libtool already has all the information > > it needs". > > > I actually tend to think we should look at this the other way ... if we > could expose the information Libtool has to other tools, pkg-config > could defer to Libtool. why can't libtool just ignore what it thinks is wrong? > So rather than libtool taking over pkg-config, we make them work > together. how about just making libtool work correctly. it's not the fault of any single program that extra linker flags can end up in link commands. if libtool cannot deal with such situations, then libtool is simply broken. -- <[EMAIL PROTECTED]> > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 14 Nov 2004, Gary V. Vaughan wrote: Hi Bob! Bob Friesenhahn wrote: You seem to be a victim of a package install where every package has used its own unique installation prefix. It seems to me that most systems use just one or two installation prefixes. Absolutely. But the point is that pkg-config is supposed to help with parallel installs, and it most certainly does not! It can help if the packages themselves are designed to support parallel installs by using versioned lib, include, share, etc., directories. That allows them to use the same installation prefix. Libtool helps, but its resulting configuration (saved in .la files) is static, while pkgconfig's configuration is dynamic since it may be altered by the user. You mean that the installed .pc files need to be altered by the user to give things a hope of linking? ;-) But seriously, why would you install a .pc using library, and then alter the installed .pc file? The libraries may be moved to (or reside in) a different location than when they were built. As you pointed out, pkg-config pulls configuration at run-time for each package, and the user has the ability to specify the pkg-config directory via PKG_CONFIG_PATH. This means that pkg-config is more end-user "tweakable" than libtool. Libtool's .la file scheme expects more path stability than pkg-config does. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig ) You seem to be a victim of a package install where every package has ) used its own unique installation prefix. It seems to me that most ) systems use just one or two installation prefixes. [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name. ... The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. (It may be arguable that having to manually specify paths to find .pc files to pkg-config is not functioning "normally"--at least not within the stated goals of PKGConfig's developers--as Gary pointed out.) ... The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system must be present within /opt/, including files intended to be copied into /etc/opt/ and /var/opt/ as well as reserved directories in /opt. As opposed to: [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY] The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. [27] The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy for packages that are installed outside of the local system's software management infrastructure. (/usr/local is the default install prefix for the autotools to gently enforce this.) The /opt hierarchy, on the other hand, may be more widely used by third-party software that does integrate with the local system's software management infrastructure, but is not a part of the local system's core installation. The /opt hierarchy may also be used by operating system distributors who *want* to isolate each package, and either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management). There is no requirement that software installed into /opt make its presence known (in well-known locations). Hence, to be reliable, PKGConfig would either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers manually specify from which install prefix to pull information. Either way, PKGConfig's reliable usefulness is reduced to being something like a means of storing CFLAGS and CPPFLAGS preferences for specific instances of a software package; it can not be relied upon in all cases as helping manage systems with multiple versions of a package installed. (That is, in a case where a .pc file might be installed in a well-known location without the library and header files being installed in well-known locations, an .la file could be similarly installed separately to provide access to the same kind of information, just lacking the header file component.) -- Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ There is a lot of food in a supermarket, too, but a supermarket isn't the best place to hold a dinner party. -- Christopher Faylor ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote: > On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: > ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: > ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig > ) You seem to be a victim of a package install where every package has > ) used its own unique installation prefix. It seems to me that most > ) systems use just one or two installation prefixes. > > [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] > /opt is reserved for the installation of add-on application software > packages. > > A package to be installed in /opt must locate its static files in a > separate /opt/ or /opt/ directory tree, where >is a name that describes the software package and >is the provider's LANANA registered name. > > ... > > The directories /opt/bin, /opt/doc, /opt/include, /opt/info, > /opt/lib, and /opt/man are reserved for local system administrator > use. Packages may provide "front-end" files intended to be placed in > (by linking or copying) these reserved directories by the local > system administrator, but must function normally in the absence of > these reserved directories. > > (It may be arguable that having to manually specify paths to find .pc files > to pkg-config is not functioning "normally"--at least not within the stated > goals of PKGConfig's developers--as Gary pointed out.) huh? so pkg-config is supposed to look in _every_ directory to find .pc files? besides the second part of what you quoted is what should have happened on Gary's system, so instead of all the separate paths under /opt, there would have simply been /opt/lib/pkgconfig. > ... > > The use of /opt for add-on software is a well-established practice > in the UNIX community. The System V Application Binary Interface > [AT&T 1990], based on the System V Interface Definition (Third > Edition), provides for an /opt structure very similar to the one > defined here. > > The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a > similar structure for /opt. > > Generally, all data required to support a package on a system must > be present within /opt/, including files intended to be > copied into /etc/opt/ and /var/opt/ as well as > reserved directories in /opt. > > > > As opposed to: > > [http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY] > The /usr/local hierarchy is for use by the system administrator when > installing software locally. It needs to be safe from being > overwritten when the system software is updated. It may be used for > programs and data that are shareable amongst a group of hosts, but > not found in /usr. > > Locally installed software must be placed within /usr/local rather > than /usr unless it is being installed to replace or upgrade > software in /usr. [27] > > > The /usr/local hierarchy may be thought of as mimicking the /usr hierarchy > for packages that are installed outside of the local system's software > management infrastructure. (/usr/local is the default install prefix for the > autotools to gently enforce this.) > > The /opt hierarchy, on the other hand, may be more widely used by > third-party software that does integrate with the local system's software > management infrastructure, but is not a part of the local system's core > installation. > > The /opt hierarchy may also be used by operating system distributors who > *want* to isolate each package, and either manage a system-wide set of > $*PATH environment variables or manage symlinks from other well-known > locations (maybe as part of a simple form of software management). > > There is no requirement that software installed into /opt make its presence > known (in well-known locations). Hence, to be reliable, PKGConfig would > either need to crawl /opt/*/lib/pkgconfig/ or demand that the installers > manually specify from which install prefix to pull information. Either way, yes, because they "*want* to isolate each package", but the administrator failed to "either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management)." > PKGConfig's reliable usefulness is reduced to being something like a means > of storing CFLAGS and CPPFLAGS preferences for specific instances of a > software package; it can not be relied upon in all cases as helping manage > systems with multiple versions of a package installed. _any_ tool that needs information that is hidden from it will of course not be as functional as it could be. > (That is, in a case where a .pc file might be installed in a well-known > location without the library and header files being installed in well-known > locations, an .la file could be similarly installed separat
Re: TODO ... solution to the pkg-config "conflict"?
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote: > On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > > > It doesn't care about package versions, but it has to care about library > > > versions and paths to libraries. > > > > again, functionality provided by pkg-config. > > > > I am contesting the claim "Libtool already has all the information > > it needs". > > > I actually tend to think we should look at this the other way ... if we > could expose the information Libtool has to other tools, pkg-config > could defer to Libtool. > > So rather than libtool taking over pkg-config, we make them work > together. so, what you want, is simply something like ... $ pkg-config --libs foo -L/path/to -lfoo $ pkg-config --libs-libtool foo /path/to/libfoo.la $ pkg-config --libs bar -L/path/to -lbar -L/path/to -lfoo $ pkg-config --libs-libtool bar /path/to/libbar.la where libbar depends on libfoo? if so, then write the patch and give it to the pkg-config folks. I can't imagine that you'd have the time to reimplement pkg-config, but not the time to patch it. -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Hi Jacob, Jacob Meuser wrote: On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote: On 2004-11-14T14:56-0600, Bob Friesenhahn wrote: ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote: ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig ) You seem to be a victim of a package install where every package has ) used its own unique installation prefix. It seems to me that most ) systems use just one or two installation prefixes. [http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES] /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name. ... The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. (It may be arguable that having to manually specify paths to find .pc files to pkg-config is not functioning "normally"--at least not within the stated goals of PKGConfig's developers--as Gary pointed out.) huh? so pkg-config is supposed to look in _every_ directory to find .pc files? Nope. Just the ones required to let me link with the library I specify. besides the second part of what you quoted is what should have happened on Gary's system, so instead of all the separate paths under /opt, there would have simply been /opt/lib/pkgconfig. But the point of splitting things into separate directories is so that I can have parallel installs of, say, libpng-1.2.4 and libpng-1.2.7, and link them against, say, zlib-1.1.4 and zlib-1.2.2 respectively. You can't do that with a shared pkgconfig directory. And without a lot of manual intervention, pkg-config actually makes it harder to do that than just looking up the dependencies by hand. :-( yes, because they "*want* to isolate each package", but the administrator failed to "either manage a system-wide set of $*PATH environment variables or manage symlinks from other well-known locations (maybe as part of a simple form of software management)." There shouldn't be any need to do this. All the information was already known when the .pc file was made, but it wasn't saved. _any_ tool that needs information that is hidden from it will of course not be as functional as it could be. pkg-config could either get it from ldd at link time, or at install time from configure. Or it could co-operate with libtool... Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote: > Hi Bob! > > Bob Friesenhahn wrote: > >You seem to be a victim of a package install where every package has > >used its own unique installation prefix. It seems to me that most > >systems use just one or two installation prefixes. > > Absolutely. > > But the point is that pkg-config is supposed to help with parallel > installs, and it most certainly does not! come on Gary, libtool is supposed to make building libraries more portable, but it is simply _broken_ for some systems at any given time, because the libtool team simply does not have the time to check that every change does not break on any systems. so you end up having someone who finds the brokenness and sends in patches. think about it. you can either improve the interaction between pkg-confg and libtool in a positive and constructive manner, or you can just blame pkg-config. -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
