libftdi Archives

Subject: RE: Library suffix behavior

From: xantares 09 <xantares09@xxxxxxxxxxx>
To: <libftdi@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 18 Oct 2011 09:20:55 +0000



> From: bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Date: Tue, 18 Oct 2011 10:48:46 +0200
> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> CC: bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: Library suffix behavior
>
> >>>>> "Thomas" == Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx> writes:
>
> Thomas> On Tuesday, 11. October 2011 14:40:36 xantares 09 wrote:
> >> Currently the build system forces the library path to be lib64 on
> >> x86_64 arch except for mac: if(NOT APPLE) # Create suffix to
> >> eventually install in lib64 if(CMAKE_SIZEOF_VOID_P EQUAL 4)
> >> SET(LIB_SUFFIX "") SET(PACK_ARCH "") else(CMAKE_SIZEOF_VOID_P EQUAL
> >> 8) SET(LIB_SUFFIX 64) SET(PACK_ARCH .x86_64)
> >> endif(CMAKE_SIZEOF_VOID_P EQUAL 4) else(NOT APPLE) SET(LIB_SUFFIX "")
> >> SET(PACK_ARCH "") endif(NOT APPLE)
> >>
> >> However some distro do not use this library suffix, like all the
> >> debian-based ones.
> >>
> >> Usually it is the packagers job to decide whether it will install in
> >> lib or lib64 through the macro %cmake defined in rpm systems which
> >> passes -DLIB_SUFFIX=64 on x86_64 systems
> >>
> >> There are two options to allow to install the library in the right
> >> place in every case: - do not try to set LIB_SUFFIX automatically -
> >> provide an option to disable the automatic setting of LIB_SUFFIX
> >> depending on CMAKE_SIZEOF_VOID_P
> >>
> >> I would go for the first one as it's the most simple (no more need
> >> for an APPLE switch) ; just remove all the SET(LIB_SUFFIX...) lines,
> >> it will be automatically read as "" (empty)
>
> Thomas> Uwe, if I recall correctly you added these lines (correct me if
> Thomas> I'm wrong ;)) Do you still need them?
>
> Hello,
>
> I run on Opensuse 11.4 with x86_64. Packages for my system have and need the
> x86_64 extension. Compiling a package without above construct results in a
> rpm package without the x86_64 extension. So witout other changes, I still
> need the lines above...
>
> Bye
> --
> Uwe Bonnes bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Hi,

We could test if "/etc/debian_version" exists like in the cmake module GNUInstallDirs (recently added to cmake versions so not usable on every version):

 if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
  set(_LIBDIR_DEFAULT "lib")
  # Override this default 'lib' with 'lib64' iff:
 #  - we are on Linux system but NOT cross-compiling
# - we are NOT on debian
# - we are on a 64 bits system
# reason is: amd64 ABI: http://www.x86-64.org/documentation/abi.pdf
# Note that the future of multi-arch handling may be even
# more complicated than that: http://wiki.debian.org/Multiarch
if(CMAKE_SYSTEM_NAME MATCHES "Linux"
AND NOT CMAKE_CROSSCOMPILING
AND NOT EXISTS "/etc/debian_version")
if(NOT DEFINED CMAKE_SIZEOF_VOID_P)
message(AUTHOR_WARNING
"Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. "
"Please enable at least one language before including GNUInstallDirs.")
else()
if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
set(_LIBDIR_DEFAULT "lib64")
endif()
endif()
endif()
set(CMAKE_INSTALL_LIBDIR "${_LIBDIR_DEFAULT}" CACHE PATH "object code libraries (${_LIBDIR_DEFAULT})")
endif()
The attached patch should satisfy everyone; it keeps the same behavior except on debian.

Regards.










libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx


Attachment: libftdi-lib_suffix.patch
Description: Text Data

Current Thread