On Aug 21, 2008, at 5:38 PM, Mark Hatle wrote:
> Just an FYI, the lib64 scan was added because of short amount of
> time. We knew
> it wasn't the right approach.. but it wasn't completely clear what
> WAS the right
> Any place thats just scanning for "lib" is just as broken as
> scanning for lib64
> or lib32 or lib42. There should be a way to pass in the lib
> directory name and
> use that for the scanning (if AM_PATH_PYTHON approach doesn't fix
> the issue.)
There _IS_ a way to specify what to scan using
And the this is uglix, so searching .../lib is not exactly odd or
is what is odd and unusal.
73 de Jeff
> Ralf S. Engelschall wrote:
>> On Tue, Aug 19, 2008, Jeff Johnson wrote:
>>> On Aug 19, 2008, at 1:37 PM, Jeff Johnson wrote:
>>>>>> $ CPPFLAGS="-I/path/to/foo/include" \
>>>>>> LDFLAGS="-L/path/to/foo/lib64" \
>>>>>> ./configure --with-foo=external
>>>>>> This way the "libfoo.* should be happily picked up from
>>>>>> /path/to/foo/lib64, too.
>>>> Let me whack at this approach some. Thanks.
>>> This approach will mostly work.
>>> However, I will need to fix libtool within python/Makefile.am
>>> there's an issue with libdir != -rpath path using libtool to install
>>> current conventions for WITH_PYTHON_LIBDIR search and value passed.
>>> Which leads me to the discovery of
>>> as used by rpm.org.
>>> Any objections to attempting AM_PATH_PYTHON on HEAD?
>> I've never used AM_PATH_PYTHON but if it is better than the
>> stuff we have in configure.ac, just use AM_PATH_PYTHON, of course.
>> Ralf S. Engelschall
>> RPM Package Manager http://
>> Developer Communication List rpm-
> RPM Package Manager http://rpm5.org
> Developer Communication List email@example.com
Received on Fri Aug 22 02:19:14 2008