Re: no .pc file
On Friday 26 October 2012 14:27:32 Bob Friesenhahn wrote: > On Fri, 26 Oct 2012, Yaroslav Bulatov wrote: > > Oops my badthat was a bad paste from some auto-generated code. > > > > This is basically a modified version of .pc file I get when building > > zlib. Not sure how useful this is because you need to update "prefix" > > in this file manually each time you rebuild libtool. Ideally the .pc > > file would be generated automatically by configure/make > > If it is not clear, package config files are operating system and/or > operating system distribution and/or operating system release version > specific. One reason for this is that each operating system > distribution uses its own names for pkg-config package definitions. > Using zlib as an example is not useful since zlib does not depend on > any other packages. Most packages depend on other packages and so > there is an OS-distribution (or even site-specific) list of packages > that this package depends on. > > While many packages do produce sample pkg-config files (based on > guess-work or assumption of a partiticular OS distribuiton), it is > common practice for the default offering to be modified by the OS > package distribution maintainer because the OS uses a different name > for a similar thing. i'm not sure how much (if any) of this is true. projects that use .pc files use the same name all the time regardless of the OS and/or distro and/or os/distro version. since that name is static, other .pc files can rely on it. the name tends to have direct correlation to the project name, so collisions are generally avoided (and certainly isn't any different from having a collision in the e.g. /usr/lib/lib.so "namespace"). some projects will vary the name slightly with their own version number, but that is package- specific (i.e. the GNOME project likes to version their libraries with major numbers, so the .pc files will include that as well). as an example, there is a SDL_net package that brings common network functionality to the common gaming SDL package. the SDL library provides a "sdl.pc" file regardless of the OS/distro. then SDL_net provides a "SDL_net.pc" that includes a line that states: Requires: sdl >= 1.2.14 this tells us that SDL_net.pc requires sdl.pc. and the behavior will be the same regardless of distro/OS/version. > with a hand-edited/non-portable framework like pkg-config. i don't think this is true either. most .pc files are generated dynamically based on input/detection from configure (or whatever equivalent build system that is in use). when it comes to the libraries in use, it's really no different in this regard from the generated libtool linker script (.la) files that libtool produces. -mike signature.asc Description: This is a digitally signed message part. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool is linking the wrong library (location) in and I can't figure out what's causing it.
On Oct 27, 2012 1:25 AM, "Jim Lynch" wrote: > > I have two fairly identical gnu make/build projects. One of them works fine but the other is looking for the library in the wrong place. The difference I see is that one of them has this: > > ibtool: link: g++ -std=c++0x -g -O2 -o loggerd loggerd-fieldlist.o loggerd-t2m.o loggerd-loggercounters.o loggerd-loggerbase.o loggerd-dbutil.o loggerd-ftplogparser.o loggerd-infocache.o loggerd-inputqueue.o loggerd-outputqueue.o loggerd-imagenode.o loggerd-arcmessage.o loggerd-xmlrpc_client.o loggerd-emailthread.o > ... > -lxmlrpc++ -lxmlrpc -lxmlrpc_util /home/jwl/build/usr/local/lib/liblog4cplus.so -pthread -Wl,-rpath -Wl,/home/jwl/build/usr/local/lib -Wl,-rpath -Wl,/home/jwl/build/usr/local/lib Sorry if this is terse, I'm on my phone. In the first case, you're using a library, liblog4cplus.so, that's installed in your home directory. Libtool sees this as outside the dynamic linker's path and adds a runpath so you're program will find the library at runtime without setting any environment variables. This is either helpful or a nuisance depending on your perspective. One thing I'd suggest is rather than toying with prefix, which tells the tools where you're going to run the program from, use the DESTDIR make variable to stage the installation into your home directory. Dan ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
On Fri, 2012-10-26 at 13:27 -0500, Bob Friesenhahn wrote: > On Fri, 26 Oct 2012, Yaroslav Bulatov wrote: > > > Oops my badthat was a bad paste from some auto-generated code. > > > > This is basically a modified version of .pc file I get when building > > zlib. Not sure how useful this is because you need to update "prefix" > > in this file manually each time you rebuild libtool. Ideally the .pc > > file would be generated automatically by configure/make > > If it is not clear, package config files are operating system and/or > operating system distribution and/or operating system release version > specific. One reason for this is that each operating system > distribution uses its own names for pkg-config package definitions. > Using zlib as an example is not useful since zlib does not depend on > any other packages. Most packages depend on other packages and so > there is an OS-distribution (or even site-specific) list of packages > that this package depends on. > > While many packages do produce sample pkg-config files (based on > guess-work or assumption of a partiticular OS distribuiton), it is > common practice for the default offering to be modified by the OS > package distribution maintainer because the OS uses a different name > for a similar thing. > > Being intended for portable software, libtool does not concern itself > with a hand-edited/non-portable framework like pkg-config. As I understand it, the .pc files use their own namespace so once a given piece of software has chosen its naming, other things can depend on it using that name space and it doesn't matter about the OS distribution or OS version used. This is a clear incentive to maintain the .pc file with the software so that there is one common naming used, at least in pkg-config space. There is no connection to the package management namespace which is totally separate. This assumes that people use some kind of common sense when choosing namespace but other than that it seems to work well. As one of the people looking after the Yocto Project (which includes an build system targeted at embedded devices), I have to say I see less problems with pkg-config than with libtool and I'm once again being asked to remove all .la files as a policy decision due to them causing more problems than they seem to solve in a cross environment :(. I'm running out of arguments against this, not least as I couldn't get any response to the libtool sysroot problems I reported a while back. Cheers, Richard ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
On Friday 26 October 2012 16:26:29 Yaroslav Bulatov wrote:
please don't top post
> Sorry for confusing terminology, I actually needed pc file for libltdl
> not libtool The .pc file above seems to have solved my problem
the proposed .pc file is incorrect for libltdl. you need to specify -lltdl in
the Libs: section after the -L${libdir}. you also need -ldl in Libs.private:.
you should also have this be a libltdl.pc.in file and have configure generate
it
so that the prefix=... and such lines are automatically replaced with the
correct paths rather than hardcoded ones from your system.
i think it'd be ok for libltdl to ship a .pc file since doing so does not mean
libltdl itself needs pkg-config in anyways. the generation of the file
requires
nothing more than any other file produced by config.status. but i'm not the
libtool maintainer ;).
-mike
signature.asc
Description: This is a digitally signed message part.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
Sorry for confusing terminology, I actually needed pc file for libltdl
not libtool The .pc file above seems to have solved my problem
For reference, the reason pc file was needed was because the toolchain
I'm using is doing something along these lines for each dependency of
fontforge (one of the dependencies was libltdl):
if ${pkgconfig} --exists ${depname}; then
# do stuff
else
echo "Missing dependency ${deplib} : ${depname}"
fi
On Fri, Oct 26, 2012 at 11:54 AM, Mike Frysinger wrote:
> On Friday 26 October 2012 01:05:10 Yaroslav Bulatov wrote:
>> I see. I needed it because a package management system was using
>> pkg-config to check if libtool was available, and refusing to proceed
>> because .pc file was missing.
>
> your package management system sounds broken. providing .pc files for
> libraries makes sense (so you could make an argument for providing one for
> libltdl), but providing one for non-libraries rarely makes sense. libtool
> included.
> -mike
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
On Friday 26 October 2012 01:05:10 Yaroslav Bulatov wrote: > I see. I needed it because a package management system was using > pkg-config to check if libtool was available, and refusing to proceed > because .pc file was missing. your package management system sounds broken. providing .pc files for libraries makes sense (so you could make an argument for providing one for libltdl), but providing one for non-libraries rarely makes sense. libtool included. -mike signature.asc Description: This is a digitally signed message part. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Building libltdlc.la?
Thanks, the relevant variable turns out to be AC_LIBLTDL_CONVENIENCE, and the way get libltdlc from regular configure make is the following: ./configure --enable-ltdl-convenience make This complains about "WARNING: unrecognized options: --enable-ltdl-convenience", but it builds libltdlc.la nonetheless On Thu, Oct 25, 2012 at 11:20 PM, Gary V. Vaughan wrote: > On Oct 26, 2012, at 12:10 PM, Yaroslav Bulatov wrote: >> Any ideas how to build libltdlc.la? > > 'make check' inside the libtool distribution builds libltdlc.la et al. for > the test suite. > > Read the Makefile's (or the manual) for full instructions :-) > > Cheers, > -- > Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
On Fri, 26 Oct 2012, Yaroslav Bulatov wrote: Oops my badthat was a bad paste from some auto-generated code. This is basically a modified version of .pc file I get when building zlib. Not sure how useful this is because you need to update "prefix" in this file manually each time you rebuild libtool. Ideally the .pc file would be generated automatically by configure/make If it is not clear, package config files are operating system and/or operating system distribution and/or operating system release version specific. One reason for this is that each operating system distribution uses its own names for pkg-config package definitions. Using zlib as an example is not useful since zlib does not depend on any other packages. Most packages depend on other packages and so there is an OS-distribution (or even site-specific) list of packages that this package depends on. While many packages do produce sample pkg-config files (based on guess-work or assumption of a partiticular OS distribuiton), it is common practice for the default offering to be modified by the OS package distribution maintainer because the OS uses a different name for a similar thing. Being intended for portable software, libtool does not concern itself with a hand-edited/non-portable framework like pkg-config. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Libtool is linking the wrong library (location) in and I can't figure out what's causing it.
I have two fairly identical gnu make/build projects. One of them works fine but the other is looking for the library in the wrong place. The difference I see is that one of them has this: ibtool: link: g++ -std=c++0x -g -O2 -o loggerd loggerd-fieldlist.o loggerd-t2m.o loggerd-loggercounters.o loggerd-loggerbase.o loggerd-dbutil.o loggerd-ftplogparser.o loggerd-infocache.o loggerd-inputqueue.o loggerd-outputqueue.o loggerd-imagenode.o loggerd-arcmessage.o loggerd-xmlrpc_client.o loggerd-emailthread.o ... -lxmlrpc++ -lxmlrpc -lxmlrpc_util /home/jwl/build/usr/local/lib/liblog4cplus.so -pthread -Wl,-rpath -Wl,/home/jwl/build/usr/local/lib -Wl,-rpath -Wl,/home/jwl/build/usr/local/lib whereas the last bit of the one that works has: libtool: link: g++ -g -O2 -o vaprobe protoarduino.o pdbutil.o timer.o arcserver.o probethread.o protocamera.o protosimple.o vaprobe.o svn_version.o -L/usr/lib64/mysql -limageserver-0.4.1 -lmysqlpp -lboost_regex -lmysqlclient -lpthread -lssl -lccgnu2 -lcurl -lccext2 -ldl -lxml2 In the first case the previous line starts with: /bin/sh ../libtool --tag=CXX --mode=link g++ -std=c++0x -g -O2 -o loggerd Followed by the list of .o files and libraries. In the working one, it's similar: /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o vaprobe One other difference is that in the first (bad) output I see two lines: libtool: link: warning: library `/usr/local/lib/libimageserver-0.4.1.la' was moved. libtool: link: warning: library `/usr/local/lib/libimageserver-0.4.1.la' was moved. But not in the good run. Where exactly is the -Wl flag coming from? The Makefile.am files are essentially identical, except for the extra '-std=c++0x' and file differences. My configuration in both cases looks like ./configure --prefix=/home/jwl/build/usr/local --sysconf=/home/jwl/build/etc I do the build via a make install prefix=~/build/logger/usr/local sysconfdir=~/build/logger/etc rpmbuild --buildroot=$HOME/build/logger/ -bb logger.spec And the spec files are structurally the same. I don't think there are any environment variables set outside of the scripts. Any information would be most appreciated. Thanks, Jim. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
Oops my badthat was a bad paste from some auto-generated code.
This is basically a modified version of .pc file I get when building
zlib. Not sure how useful this is because you need to update "prefix"
in this file manually each time you rebuild libtool. Ideally the .pc
file would be generated automatically by configure/make
prefix=/usr/local/google/home/yaroslavvb/third_party/15_2/x86_64/libtool
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libtool
Description: libtool
Version: 2.4
Libs: -L${libdir}
Cflags: -I${includedir}
On Fri, Oct 26, 2012 at 7:09 AM, Eric Blake wrote:
> On 10/25/2012 11:05 PM, Yaroslav Bulatov wrote:
>> I see. I needed it because a package management system was using
>> pkg-config to check if libtool was available, and refusing to proceed
>> because .pc file was missing.
>>
>> I got around it by supplying my own pc file.it . In case someone else
>> runs into this problem -- here's the file I used
>>
>> # Copyright 2012 Google Inc. All Rights Reserved.
>
> I stopped reading right here. That license is not open, and therefore,
> it cannot be incorporated into other projects. Are you able to
> relicense this under an open license?
>
> --
> Eric Blake ebl...@redhat.com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: no .pc file
On 10/25/2012 11:05 PM, Yaroslav Bulatov wrote: > I see. I needed it because a package management system was using > pkg-config to check if libtool was available, and refusing to proceed > because .pc file was missing. > > I got around it by supplying my own pc file.it . In case someone else > runs into this problem -- here's the file I used > > # Copyright 2012 Google Inc. All Rights Reserved. I stopped reading right here. That license is not open, and therefore, it cannot be incorporated into other projects. Are you able to relicense this under an open license? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
