Re: [PDCurses] automake test for libraries
On Mon, Jun 22, 2015 at 8:13 AM, anatoly techtonik wrote: > The only problem with pkg-config is that it is a pain on Windows that > comes with 200Mb of different Unix dependencies. But.. looks like > thing got better for Python https://pypi.python.org/pypi/pykg-config/1.3.0 I use it on Windows all the time. As I mentioned, I use the pkgconf version. It has no significant dependencies and no circular dependencies like the GNU version. I sent the pkgconf project the initial patches to get it working on Windows. I have the Windows executable for pkgconf if anyone needs it. I run it on Linux and BSD as well. I've even been able to build it for DOS (djgpp). Haven't had any problems and it greatly simplifies the task of finding where libraries are and switching between different versions of libraries. I have build scripts for several libraries. Many provide their own .pc files, but if they don't I just add a line or two to my build tool's scripts and it autogenerates a .pc file for me.
Re: [PDCurses] automake test for libraries
On Mon, Jun 22, 2015 at 1:57 PM, LM wrote: > On Sat, Jun 20, 2015 at 9:04 AM, Kevin Lamonte > wrote: >> End-users wanting the X11 version right now can also pass "--with-x >> --x-libraries=/usr/lib/x86_64-linux-gnu/" to configure (might be different >> path based on distro, this is what I use on Debian). Making this behavior >> default would be nice. >> > > For me, the easiest way to find libraries on my system is to use > pkg-config. It's also part of the freedesktop standard ( > http://www.freedesktop.org/wiki/Software/pkg-config/ ). I'm using it > in the pdcurses makefile for SDL2. With pkg-config, it doesn't matter > where a distribution chooses to place libraries, the .pc file holds > the correct location. Not every library has a related .pc file > (although many do). I typically create .pc files for any libraries > that don't already have them. It makes it very easy to switch > locations of libraries or to switch between SDL and SDL2. It's a > simple, standard way for build scripts to locate libraries. If you're > not thrilled with all the dependencies required to build the gnu > version of pkg-config, you can use pkgconf ( > https://github.com/pkgconf/pkgconf ). It's a drop-in replacement for > pkg-config. The only problem with pkg-config is that it is a pain on Windows that comes with 200Mb of different Unix dependencies. But.. looks like thing got better for Python https://pypi.python.org/pypi/pykg-config/1.3.0 -- anatoly t.
Re: [PDCurses] automake test for libraries
On Sat, Jun 20, 2015 at 9:04 AM, Kevin Lamonte wrote: > End-users wanting the X11 version right now can also pass "--with-x > --x-libraries=/usr/lib/x86_64-linux-gnu/" to configure (might be different > path based on distro, this is what I use on Debian). Making this behavior > default would be nice. > For me, the easiest way to find libraries on my system is to use pkg-config. It's also part of the freedesktop standard ( http://www.freedesktop.org/wiki/Software/pkg-config/ ). I'm using it in the pdcurses makefile for SDL2. With pkg-config, it doesn't matter where a distribution chooses to place libraries, the .pc file holds the correct location. Not every library has a related .pc file (although many do). I typically create .pc files for any libraries that don't already have them. It makes it very easy to switch locations of libraries or to switch between SDL and SDL2. It's a simple, standard way for build scripts to locate libraries. If you're not thrilled with all the dependencies required to build the gnu version of pkg-config, you can use pkgconf ( https://github.com/pkgconf/pkgconf ). It's a drop-in replacement for pkg-config.
Re: [PDCurses] automake test for libraries
End-users wanting the X11 version right now can also pass "--with-x --x-libraries=/usr/lib/x86_64-linux-gnu/" to configure (might be different path based on distro, this is what I use on Debian). Making this behavior default would be nice. Would just running autoconf/automake/aclocal with the latest versions do it? On Jun 20, 2015, at 7:42 AM, John P. Hartmann wrote: > Sorry for being terse. > > On a 64 linux that stores 64 bit libraries in /usr/lib64 (debian based), the > configure tests for the Athena and other libraries fail even when the library > is installed. Adding a symbolic link from /usr/lib/ to > /usr/lib64/ allows configure to complete. > > As far as configure is concerned, the variable mh_lib_dirs should somehow > contain /usr/lib64 in addition to /usr/lib. > > This comes from line 150 of aclocal.m4: > > mh_lib_dirs="$x_libraries `echo "$ac_x_includes $ac_x_header_dirs" | sed > s/include/lib/g`" > > This needs to change to accommodate /usr/lib64. Note that testing blindly > for this library in addition to /usr/lib does not expose systems that mix 32 > bit and 64 bit libraries. > > On 06/20/2015 10:34 AM, anatoly techtonik wrote: >> On Fri, Jun 19, 2015 at 6:35 PM, John P. Hartmann >> wrote: >>> Many modern Linux distributions maintain the 64 bit libraries in /usr/lib64 >>> to be able to coreside with 32 bit libraries in /usr/lib. >> >> Ok. >> >>> Has this been fixed so that I don't need to create symbolic links to get >>> around the configuration checks for athena and its prerequisites? >> >> Can you be more specific about what was wrong and what should >> have been fixed for those of us not familiar with Linux internals? >>
Re: [PDCurses] automake test for libraries
Sorry for being terse. On a 64 linux that stores 64 bit libraries in /usr/lib64 (debian based), the configure tests for the Athena and other libraries fail even when the library is installed. Adding a symbolic link from /usr/lib/ to /usr/lib64/ allows configure to complete. As far as configure is concerned, the variable mh_lib_dirs should somehow contain /usr/lib64 in addition to /usr/lib. This comes from line 150 of aclocal.m4: mh_lib_dirs="$x_libraries `echo "$ac_x_includes $ac_x_header_dirs" | sed s/include/lib/g`" This needs to change to accommodate /usr/lib64. Note that testing blindly for this library in addition to /usr/lib does not expose systems that mix 32 bit and 64 bit libraries. On 06/20/2015 10:34 AM, anatoly techtonik wrote: On Fri, Jun 19, 2015 at 6:35 PM, John P. Hartmann wrote: Many modern Linux distributions maintain the 64 bit libraries in /usr/lib64 to be able to coreside with 32 bit libraries in /usr/lib. Ok. Has this been fixed so that I don't need to create symbolic links to get around the configuration checks for athena and its prerequisites? Can you be more specific about what was wrong and what should have been fixed for those of us not familiar with Linux internals?
Re: [PDCurses] automake test for libraries
On Fri, Jun 19, 2015 at 6:35 PM, John P. Hartmann wrote: > Many modern Linux distributions maintain the 64 bit libraries in /usr/lib64 > to be able to coreside with 32 bit libraries in /usr/lib. Ok. > Has this been fixed so that I don't need to create symbolic links to get > around the configuration checks for athena and its prerequisites? Can you be more specific about what was wrong and what should have been fixed for those of us not familiar with Linux internals? -- anatoly t.
