Compiling "Could NOT find X Using internal"

[Enjay]

I know that the following are harmless because they are basically taking care of themselves, but I've often wondered about these messages from CMake.

Code: Select all • Expand view

Could NOT find BZip2 (missing:  BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
Could NOT find JPEG (missing:  JPEG_LIBRARY JPEG_INCLUDE_DIR)
Could NOT find ZLIB (missing:  ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Could NOT find GME (missing:  GME_LIBRARIES GME_INCLUDE_DIR)
Using internal zlib
Using internal jpeg library
Using internal bzip2 library
Using internal gme library


Is there any advantage to installing the relevant libraries or is there no real benefit over "Using internal [whatever] library"?

[Graf Zahl]

That's for the Linux geeks who are under the strange belief that the only way to link to a library is to install that library separately and dynamically link to the installed version.

[Enjay]

Fair enough. Good to know. Thanks.

[Rachael]

I got a bit of a laugh out of the way Graf said that.

Ultimately, even on Linux it really doesn't hurt anything to use external or internal libraries. However, most people install using external libraries, and that is even instructed as such on the wiki.

[Graf Zahl]

On Windows that weird practice has mostly disappeared, except for installable system components because it causes so many problems.

The best case in point would be the official OpenAL which insists on running only from the Windows System directory and causing all sorts of problems with other software which expects a sane setup. I know what Linux recommends but ultimately it's a really stupid practice because it assumes the best when the worst is more likely.

[dpJudas]

The worst? You mean when the display driver links to LLVM and then crashes when the application itself also uses said component?

[Rachael]

In my opinion, the "sanest" route is to only call an operating system's API when accessing the hardware, inter-process calls, file system, or other extremely common and mundane tasks (such as the "Open/Save As" dialog box).

But maybe I come from a day when if you built executables in DOS, you had to almost rely entirely on your own API, because DOS expected you to manipulate the hardware directly and provided absolutely no API assistance to do so. Ah, the freedom you had, in those days, though...

[dpJudas]

The problem with Linux is that there is not really such a distinction. There is an ABI done by the Linux kernel, but anything in userspace is just tossed into the /usr/lib and /usr/include folders. The rationale behind this was to save memory and disk space. Something that has been made largely obsolete by the fact that memory and disk space is virtually limitless today compared to back when that choice was made. Today there's only really the disadvantages left in my opinion.

[Graf Zahl]

The worst? You mean when the display driver links to LLVM and then crashes when the application itself also uses said component?

Yes, something along those lines, although not quite as bad. This was because I ultimately decided to dynamically link to OpenAL32.dll, because I could specify a full path.
That 'official' DLL somehow has managed to force itself into the process globally and causing all sorts of weird issues with code that was expecting OpenAL Soft.

I believe the main issue with Linux is that the executable format only defines the symbols it requires but not the library they should come from, like on Windows. It not only amplifies dependency hell to insane proportions but also looks like a great way to inject malicious code into a process.


BTW, the things this thread is about is about stuff that initially was just static on Linux just like on Windows. Unless some Linux geeks came along, decided that it was bad and subverted it to the Linux way of things, depending on a sane library setup.

[Edward-san]

Interestingly, nobody mentioned the most advantageous thing about libraries installed from official packages: security updates. For example, the gme library got updated not much after the release of the zero-day critical bug, while it took some time for us to add the fix to the internal version (and required somebody to make the report!).

[Graf Zahl]

I have made it a policy to never distribute any binaries I cannot fully vouch for. And depending on such packages can easily bite me in the ass if something goes wrong, so anything I develop professionally either has all DLLs accompanying the EXE or if possible I statically link to stuff. Security updates may be a thing but in the bigger picture they are not worth the trouble I could face if that software ceased to work just because some external library suddenly introduced a critical regression.

[Blzut3]

BTW, the things this thread is about is about stuff that initially was just static on Linux just like on Windows. Unless some Linux geeks came along, decided that it was bad and subverted it to the Linux way of things, depending on a sane library setup.

Hmm? I don't recall this ever being static by default except for GME, which has always been a community supported package for Ubuntu at least. I don't think the developers make any claims of ABI stability for libgme either (but I could be wrong). For the other three to the extent of my memory ZDoom has always searched for a system library and used those if available.

Zlib and BZip2 are almost always installed on Linux distributions and OS X includes them in the SDK (well zlib at least, would have to double check bzip2). JPEG is kind of special as its one of the few core libraries that doesn't have ABI stability (and controversially so).