Re: [CMake] Linking on OSX

[Guy Harris]

On Jun 4, 2019, at 2:27 PM, Bryan Christ  wrote:

> Thanks for the explanation.  Yes.  The use of the term Library certainly 
> added to my confusion.  I've been coding on Linux for 20 and the "proper" way 
> of doing things on Mac is a bit elusive to me as I stumble around.

Yeah, it must be weird going from a system that stuffs libraries in /usr/lib64 
to a system that stuffs them in /usr/lib. :-)

(There's no need to put 32-bit and 64-bit libraries in separate directories if 
you can put the 32-bit and 64-bit versions of a library in the same file, as 
you can in Darwin.

But the real point is that every UN*X has its own quirks, and somebody might 
find the UN*X with which you're most familiar to be the quirky one.  If you're 
going to do cross-platform UN*X programming, be prepared to have assumptions 
about UN*X, made based on the platform or platforms with which you're familiar, 
to be violated by some other UN*X.)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking on OSX

[Guy Harris]

On Jun 4, 2019, at 1:33 PM, Bryan Christ  wrote:

> I would agree with you, but I've been told that OSX is moving away from it's 
> Unix heritage and placing libraries in non-traditional locations (not /usr or 
> /usr/local) and that's going to be increasingly the norm in the future.
> 
> https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja

That talks about *headers*, not *libraries*.  (Don't be confused by the 
"/Library" used in some path names in that item - /Library has more than 
libraries in it.)

macOS has, all the way back to when it was called "Mac OS X", had a notion of 
"frameworks", which are not installed under /usr/lib, and that contain 
dynamically-linked shared libraries; the higher-level Cocoa APIs, for example, 
are provided as frameworks, as are C libraries such as Core Foundation.

UNIX APIs, however, are, and have always been, implemented as regular 
dynamically-linked shared libraries under /usr/lib.

The executable image for Microsoft Word for Mac has the strings

/usr/lib/libz.1.dylib
/usr/lib/libsqlite3.dylib
/usr/lib/libobjc.A.dylib
/usr/lib/libc++.1.dylib
/usr/lib/libSystem.B.dylib

built into it as library paths; if Apple were to decide to put UNIX libraries 
somewhere other than /usr/lib, and not have a /usr/lib symbolic link pointing 
to the new location, the run-time linker would have to extract the final 
component of paths beginning with /usr/lib and treat them as if they pointed to 
a library in the new location, instead; they could probably do that, but it's 
not clear what the point of doing so would be.

So if somebody were to claim that macOS will be putting *UNIX libraries* (as 
opposed to macOS frameworks, or header files) in some location other than 
/usr/lib, I'd have to ask for some pretty solid evidence to believe that claim; 
I haven't seen any such evidence so far.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking on OSX

[Guy Harris]

On Jun 3, 2019, at 3:27 PM, Juan E. Sanchez  wrote:

> It looks like macOS made it so you have to do something like this:
> open 
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> 
> for libraries and includes to be put into /usr.

*Libraries* should exist in /usr/lib regardless of whether you do that, or even 
whether you have Xcode, or the command-line developer tools, installed - if you 
don't have the shared libraries in /usr/lib, programs using the libraries won't 
work, and programs shipped with macOS use, at minimum, libSystem, and may use 
other libraries.  vi, for example, uses the ncurses library.

It's the *headers* that aren't installed in /usr/include by default.  The 
compiler *should* look in the directory where they're installed, however.

Note that macOS 10.15 Catalina apparently has a separate read-only volume that 
contains all the executables and libraries, and presumably including /usr, so 
it may be *impossible* to arrange, on 10.15, that there be a /usr/include 
directory.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking on OSX

[Guy Harris]

On Jun 4, 2019, at 10:56 AM, Bryan Christ  wrote:

> Thanks for your suggestions.  I went through that thread pretty thoroughly 
> trying all of the recommended tips and, unfortunately, nothing seemed to 
> work.  I also tried running that open command you cited, but there are still 
> no includes for ncurses in /usr/include or /usr/local/include.

Presumably after you ran the open command you then performed an installation of 
the package from the window that the command popped up?

If not, you need to do that.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] execute short program during cmake configuration ?

[Guy Harris]

On Jun 2, 2016, at 2:56 PM, Alan W. Irwin  wrote:

> It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS
> macro. So I suggest you copy that macro (found in
> Modules/CheckCSourceRuns.cmake) to your own source code where your
> other home-grown CMake macros are located, rename that macro to
> CHECK_FORTRAN_SOURCE_RUNS, and make the minor modifications to that
> macro that are appropriate for the Fortran case.

...and contribute it back to the CMake maintainers to encourage its appearance 
in future releases?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Checking whether particular *linker* flags are supported

[Guy Harris]

On Jan 22, 2016, at 12:24 PM, Guy Harris <g...@alum.mit.edu> wrote:

> CMake has the macros CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG, which 
> allow checking for whether a given C or C++ compiler flag is supported by the 
> compiler being used.
> 
> However, there's no CHECK_LINKER_FLAG macro, so that you can check whether a 
> given *linker* flag is supported by the linker being used, so there doesn't 
> seem to be a good way to use a flag, such as the --as-needed flag, if it's 
> not *required*, but is "nice to have", but isn't available on all platforms.
> 
> So what's the best way to do such a check?
> 
> (I'm assuming here that, for all generators on UN*X platforms, linking is 
> done by using the compiler driver, so that you don't have to worry about, for 
> example, using -Wl,{linker flag} with some generators and just {linker flag} 
> with other generators.)

Bug 0015934:

https://public.kitware.com/Bug/view.php?id=15934

filed.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Checking whether particular *linker* flags are supported

[Guy Harris]

CMake has the macros CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG, which 
allow checking for whether a given C or C++ compiler flag is supported by the 
compiler being used.

However, there's no CHECK_LINKER_FLAG macro, so that you can check whether a 
given *linker* flag is supported by the linker being used, so there doesn't 
seem to be a good way to use a flag, such as the --as-needed flag, if it's not 
*required*, but is "nice to have", but isn't available on all platforms.

So what's the best way to do such a check?

(I'm assuming here that, for all generators on UN*X platforms, linking is done 
by using the compiler driver, so that you don't have to worry about, for 
example, using -Wl,{linker flag} with some generators and just {linker flag} 
with other generators.)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake