[cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path

[Christian Schmidbauer]

I don't think our patches will be mutually exclusive. If I understand
you correctly, you are trying to make x32 auto-detectable, hence make
it work "out of the box". I like the idea and I also tried x32
auto-detection in the past, but it seemed to me that the
infrastructure does not support it very well. I also don't think that
enough people use x32 to justify putting many working hours into it.

My approach of this patch on the other hand is much more general in
nature: I am trying to support any lib<qual>, as defined in [1]. This
allows cmake to be used in environments which have more specific
requirements. Hence it overwrites the default heuristic, which is
usually wrong in such environments. The x32 ABI is just one scenario
where you could apply this overwrite.

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html

On Sun, Feb 26, 2017 at 6:38 PM, Steven Newbury <steve at snewbury.org.uk> wrote:
> On Sun, 2017-02-26 at 16:25 +0000, Steven Newbury wrote:
>> On Sun, 2017-02-26 at 16:42 +0100, Christian Schmidbauer wrote:
>> > Hallo,
>> >
>> > I provided a v2 of my previous patch to the ML a few hours back
>> > (see
>> > [1]), you can give it a try. I was successfully able to build llvm
>> > on
>> > Gentoo, by adding the following lines to
>> > /usr/portage/eclass/cmake-utils.eclass
>> >
>> > --- aaa/cmake-utils.eclass      2017-02-07 06:44:59.000000000 +0100
>> > +++ bbb/cmake-utils.eclass      2017-02-26 16:37:53.176993623 +0100
>> > @@ -607,6 +607,7 @@
>> >         cat > "${common_config}" <<- _EOF_ || die
>> >                 SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate
>> > Gentoo
>> > package build")
>> >                 SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library
>> > path suffix" FORCE)
>> > +               SET (CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
>> > "${libdir/lib}" CACHE STRING "")
>> >                 SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH
>> > "Output
>> > directory for libraries")
>> >         _EOF_
>> >         [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo
>> > 'SET
>> > (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make"
>> > FORCE)' >> "${common_config}"
>> >
>>
>> Hallo Chris,
>>
>> I've made some progress with run-time x32 detection in cmake.  I'll
>> see
>> how that goes, if I can't get it working (which I'm testing now) I'll
>> use your approach.
>
> I have to say, the whole idea behind having either 32-bit or 64-bit
> library paths determined by the size of a single type, this way seems a
> little flawed to me.  Linux x32 (Linux ELF x86-64-32) isn't the only
> 32-bit userland on 64-bit kernel.  MIPS does the same and there's also
> ILP32 for aarch64 (ARM64-32).  Not to mention any other ABI variants.
>
> Previous code used CMAKE_INTERNAL_PLATFORM_ABI at least for MIPS, this
> just makes much more sense to me, and it's the approach I've used in my
> updated x32 cmake patch to determine at run-time if we're using x32-
> abi.