Compiling "Could NOT find X Using internal"

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Compiling "Could NOT find X Using internal"

Postby Enjay » Thu Jan 05, 2017 12:15 pm

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 allExpand 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"?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Compiling "Could NOT find X Using internal"

Postby Graf Zahl » Thu Jan 05, 2017 12:20 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Compiling "Could NOT find X Using internal"

Postby Enjay » Thu Jan 05, 2017 12:22 pm

Fair enough. Good to know. Thanks.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Compiling "Could NOT find X Using internal"

Postby Rachael » Thu Jan 05, 2017 12:32 pm

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

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.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: Compiling "Could NOT find X Using internal"

Postby Graf Zahl » Thu Jan 05, 2017 1:08 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Compiling "Could NOT find X Using internal"

Postby dpJudas » Thu Jan 05, 2017 1:11 pm

The worst? You mean when the display driver links to LLVM and then crashes when the application itself also uses said component? ;)
dpJudas
 
 
 
Joined: 28 May 2016

Re: Compiling "Could NOT find X Using internal"

Postby Rachael » Thu Jan 05, 2017 1:16 pm

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...
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: Compiling "Could NOT find X Using internal"

Postby dpJudas » Thu Jan 05, 2017 1:25 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Compiling "Could NOT find X Using internal"

Postby Graf Zahl » Thu Jan 05, 2017 1:54 pm

dpJudas wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Compiling "Could NOT find X Using internal"

Postby Edward-san » Thu Jan 05, 2017 4:43 pm

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!).
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: Compiling "Could NOT find X Using internal"

Postby Graf Zahl » Thu Jan 05, 2017 5:01 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Compiling "Could NOT find X Using internal"

Postby Blzut3 » Thu Jan 05, 2017 5:23 pm

Graf Zahl wrote: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).
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support


Return to General

Who is online

Users browsing this forum: No registered users and 5 guests