On Tue, Jul 5, 2011 at 8:20 PM, Will Rosecrans <[email protected]> wrote:
>> 2. I'm confused by the Makefile in the root of the source. It appears
>> to be a plain Makefile which turns around and runs cmake? For Fedora
>> it's better to use the %cmake macro so that a lot of defaults are set
>> properly instead of me having to set them manually. I tried just going
>> into the src directory and doing just that and it appears to work. Are
>> there any pitfalls to this method I need to be aware of?
>>
>
> I think there's no reason why an automatic build would need to use the
> classic Makefile. It generally isn't used on Windows, where make is
> uncommon. It is, IMO, a nice convenience for those of us who are used
> to such things, but you can go straight for the cmake stuff if it
> makes your life easier. (And, it sounds like you are pretty familiar
> with cmake)
Good to know... Thanks.
>> 3. Would it be difficult to get the cmake configuration to honor
>> "CMAKE_INSTALL_LIBDIR" so that the library goes in /usr/lib64 on
>> x86_64 systems rather than usr /usr/lib?
>>
>
> Last time I actually paid any attention to the build system, there
> wasn't really a concept of an install target directory. There was
> build, and then copy the results wherever you wanted. Presumably it's
> something that could be sorted out without too much trouble. I think
> the install stuff was sort of being deferred until the project was
> "mature enough that somebody would actually want to package it for use
> by others," which has apparently happened.
Yup :) I'm not sure if it's intentional or not but 'make
DESTDIR=%{buildroot} install' does work, I just assumed the website
hadn't been updated since it mentioned there was no install target.
The only problem I'm having was getting the library put in /usr/lib64,
but I can work around that during the build process.
>> 5. Fedora doesn't allow hard coded paths for libraries (except for
>> internal libraries). Is there an option to stop this behavior? See:
>>
>> http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
>>
>> I tried the builtin cmake option "CMAKE_SKIP_RPATH" but it didn't seem
>> to help...
> Is there somewhere specific that you are seeing the hard coded paths?
> That may help those of us who aren't really up to speed on build
> issues understand where to look.
Here's the relevant snippet from the build log:
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
* to fail. To ignore these errors, you can set the '$QA_RPATHS'
* environment variable which is a bitmask allowing the values
* below. The current value of QA_RPATHS is 0x0000.
*
* 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
* issue but are introducing redundant searchpaths without
* providing a benefit. They can also cause errors in multilib
* environments.
* 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
* nor relative filenames and can therefore be a SECURITY risk
* 0x0004 ... insecure RPATHs; these are relative RPATHs which are a
* SECURITY risk
* 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
* RPATHs; this is just a minor issue but usually unwanted
* 0x0010 ... the RPATH is empty; there is no reason for such RPATHs
* and they cause unneeded work while loading libraries
* 0x0020 ... an RPATH references '..' of an absolute path; this will break
* the functionality when the path before '..' is a symlink
*
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
* $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
* $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*
*******************************************************************************
ERROR 0001: file '/usr/python/OpenImageIO.so' contains a standard
rpath '/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/iv' contains a standard rpath '/usr/lib'
in [/usr/lib]
ERROR 0001: file '/usr/bin/iconvert' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/maketx' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/idiff' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/igrep' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/iinfo' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/bin/iprocess' contains a standard rpath
'/usr/lib' in [/usr/lib]
ERROR 0001: file '/usr/lib64/libOpenImageIO.so' contains a standard
rpath '/usr/lib' in [/usr/lib]
I hope that helps! There is a utility that will just brute force strip
them out but it doesn't always work...
Thanks,
RIchard
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
