What steps will reproduce the problem? 1. build the lib on x86_64 2. issue make install 3.

What is the expected output? What do you see instead? the library should be copied to $PREFIX/lib64, but it's copied to $PREFIX/lib

What version of the product are you using? On what operating system? openSUSE, 64bit OS. latest released tarball tested

Just got round to seeing this - sorry for not noticing earlier.

I just had a look at this on LHS, didn't know about it.

I expect lots of older programs will install by default to lib, so doesn't really look like a clever thing to do to mandate this in a path standard, but if it's mandated, I'll change it in the Makefile for next version.

After looking around a bit, it seems that libs should go in lib64 if building a 64 bit lib on a 32 bit arch (or at least on a non 64 bit arch). I have no cross compiling support, so I'd see this as a non issue - if you're on a x86_64 host, native libs should go in lib rather than lib64 - do you have any information that this is not the case ? or are you trying to cross compile to 64 bit while running a 32 bit kernel on x86_64 ? Thanks

In all setups I have ever seen, all native 64bit libs were installed in lib64 and native 32bit libs in lib.

It's nothing really new and you can grab almost all libs out there and it will be this way.

I'm not cross-compiling

I'm actually on a x86_64 machine, and I've tried installing 3 libs (libogg, liboggz, libtheora) and all 3 install to /usr/local/lib by default (using autotools, which are supposed to do the "right thing"). Do those install to lib64 by default for you ?

What I don't understand is that some lib built on x86_64 will install in /usr/local/lib if it doesn't do anything special for x86_64 (eg, an old lib), and this would break this setup, which strikes me as odd, so I feel like I'm missing something here.

I just want to make sure I understand the issue before making any changes.

well, I hardly ever use a 'simple' make install, as I wrap most things up for RPMs for proper distribution.

so using the correct ./configure parameters always makes it the way it should be (openSUSE for example requires 64bit libs to be in lib64, as sometimes 32bit libs have to be installed in parallel... and having both in /usr/lib will give you major headaches(

RPM files just install in places which are independant of where a Makefile would place them, right ? To be honest, if widely used libs such as libogg and libtheora do install in /usr/local/lib, I'm inclined to keep doing he same too as it seems more correct to me (admittedly, I do not know much at all about x86_64 specific issues).

AFAICT, installing in lib64 should be in installing a 64 bit lib on a 32 bit OS (eg, a non default case). I'd be interested to get links to sources detailing the use of lib64, however, if you have some at hand).

I've had a look at some more libs (ffmpeg, GStreamer, libcheck), and they also all install in lib on my x86_64 machine, so unless I get more info about why this is wrong, I'll close this as invalid. Thanks

As A fedora packager i would vote +1 for lib64 location on multilibs 64bit system. This could have been done accurately by using autotools. Actually not using an accurate build system (either autotools or cmake) will make this package really difficult to maintain. So i would vote +1 for a build system re-introduction.

I've just made a major overhaul to the Makefile (adding libtool among others), and I took the opportunity to make the lib directory a variable (LIBQUAL), so by default libs will be installed in $(PREFIX)/lib, but by using, eg, make LIBQUAL=lib64, they'll go in $(PREFIX)lib64 (or anything else you select). I'll mark this as fixed on releasing 0.1.7, which should be shortly.

About autotools, I'm far from comfortable with those, definitely not enough to add them. Maybe later.

I've since found libs that install to lib64 by default: some KDE stuff that installed itself when I tried Amarok. All others I tried went to lib (using autotools for most of them). All on a x86_64.

Anyway, would this LIBQUAL variable meet your needs ?

There is no need to recreate the wheel here! ;) LIBDIR is the only correct value. by default it can be prefix/lib, indeed. But if specified it has to follow the option given to install library in the correct location.

Remember that you also need to use $(DESTDIR)$(PREFIX) and $(DESTDIR)$(LIBDIR) etc. DESTDIR is used at make install step to install compiled code in a special directory so it can be rpmized easily.

Now the problem with "simple makefile" is that they aren't that simple. pkg-config detection for ogg and others dependencies will need to be recreated from scratch. where autotools pkg-config support is only one line lenght. It can even be overidden by parsing the correct OGG_CFLAGS etc...

I would add, pkg-config support for libkate would also be needed. This will be hard to have them created accurately without autotools support. (libdir directory will need to be inherited in the created pkgconfig)

OK, I just don't know much about all that :) I'll make it LIBDIR - and that's the whole path, right, so you can make install PREFIX=/usr LIBDIR=/tmp/foo/lib ? I have DESTDIR in the latest dist. I do have pkg-config files for libkate (in misc/pkg-config) though I'll have to make sure the directories are properly set with the latest changes. If you mail me, I can send you the current snapshot ? It'd be very much appreciated to be seen by someone who knows about all this.

Maybe we can use the svn once populated. But it would be really fine to reintroduce autotools support. I could help you to fix problem if needed.

Now it can be possible to have it use this makefile, but as i said, it will produce more problem than it will solve.

Feel free to contact me kwizart at gmail.com

libkate now uses autotools, which makes it in turn support changing LIBDIR, so libs may now be installed in lib64 if the installer needs to.