1

For distribution in CentOS 6, I'm reviewing a Makefile.patch that has,

-   @echo 'libdir=$${prefix}/lib' >> tap.pc
+   @echo 'libdir=$${prefix}/lib64' >> tap.pc

My question is whether or not that's the way it's done. Is it normal to rewrite all make files for 64/bit and 32/bit installs on CentOS? Is there a way to have make handle this and to just build for 64bit archs without hard coding this?

Later in the makefile you can see they follow forward with this convnetion of hard coding the install for lib64?,

+   mkdir -p $(PREFIX)/lib64 $(PREFIX)/include $(PREFIX)/lib64/pkgconfig
+   install -c libtap.a $(PREFIX)/lib64
+   install -c libtap.so $(PREFIX)/lib64
+   install -c tap.pc $(PREFIX)/lib64/pkgconfig
  • »» whether or not that's the way it's done «« : 1. The package libtap, tap is not in any recommended RHEL / CentOS repo. 2. files.spec are usually for all supported architectures. So the patch in your question looks like an attempt to use a non standard "rpmbuild method". – Knud Larsen Mar 19 at 11:39
2

What you describe is one of the ways, if a library you build does not ship with something like foo.pc.in for example.

The convention is that, if the Makefile (or the build system) allows for configuring library directory via an environment variable, then it's being used.

So as a first step, identify if a given Makefile has something like that. E.g. this example allows to do multilib build (e.g. x64_64 and i686) off the same spec file that has:

%make_install PREFIX=%{_prefix} INSTALL_LIB=%{buildroot}%{_libdir}

No patching required in this case.

A cmake-based project can be told to about the right library directory, like so:

%cmake .. -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
  -DCMAKE_INSTALL_LIBDIR="%{_libdir}"

So as a last resort only, if the Makefile doesn't allow for any customization of the library directory, you would do the patching.

Although, this might get tedious to create such patches. So you can put sed to work in the %prep section.

| improve this answer | |
  • You can certainly use sed (or even Perl ;-) to cook up the patch. But it is better to create a patch and review/*fix* the automated modification, and add the result to the SRPM tnan blindly trust automated mangling. Some later day you'll want to reuse the patch for the next upstream version... – vonbrand Mar 22 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.