make.conf: WITH_NEW_XORG.... and other questions

ikbendeman

ikbendeman

What does the knob in make.conf
Code: 
WITH_NEW_XORG=YES
do?

Also, can anyone shed light on
Code: 
BUILD_STATIC=YES
[B]NO_PROFILE=YES[/B]
WITH_PKGNG=YES

I have no clue what WITH_NEW_XORG does. I understand what BUILD_STATIC does, but not its performance impact (I have an 8 core AMD FX 4.0 GHz, with 16 GB ram RAM). No clue and I can't even guess what NO_PROFILE does.

And isn't PKGNG default nowadays?
 
WITH_NEW_XORG = use the newer version (there are two versions hidden in ports, imagine it like xorg-devel versus xorg)
BUILD_STATIC = instead of using dynamic shared libraries, build them into the code
NO_PROFILE = build without performance profiling information

As with most entries in /etc/make.conf, they should generally only be used by people who can explain the disadvantages. That is, don't use a tool until you know how to misuse it.
 
sk8harddiefast said:
And which is best choice?
Click to expand...

That entirely depends on the situation. For example, the tools in /rescue/ are all statically linked. This makes them bigger (the needed libraries have to be attached to the executable) but it also means you don't need to have access to /usr/lib/ to load a library dynamically. What's the use you might think? Imagine a non-booting system and you only have access to the root filesystem and /usr/ can't be mounted. In that case a statically linked executable will still work. When a dynamically linked executable will fail because it can't load it's libraries from /usr/lib/. Statically linked executables can also be useful from a chroot(8), you don't have to copy or link libraries into the chroot environment.

There is a downside of course. If there's a bug in libc for example, each and every executable that statically links libc would need to be rebuild. Yet only libc itself needs to be rebuild in order to 'update' all executables that dynamically load it.
 
Also, according to /usr/ports/Makefile, statically linked executables are much faster:

Code: 
# /rescue/sh is statically linked and much faster to execute than the
# dynamically linked /bin/sh.  This is significant for targets like
# make index that execute the shell tens of thousands of times.
.if exists(/rescue/sh)
INDEX_SHELL=            /rescue/sh
.else
INDEX_SHELL=            /bin/sh
.endif

So, this is another advantage of statically linked executables, but in my opinion, it should be only used in special cases.
 
bkouhi said:
Also, according to /usr/ports/Makefile, statically linked executables are much faster:
Click to expand...
The executables themselves won't be faster or slower. It's just that external libraries don't have be looked up, loaded, initialized etc. before they can be used, this can cause a slight delay. Multiply this small delay a couple of hundred times and it will be noticeable. Most of the time this doesn't really matter as they will be cached after the first use anyway.

So, this is another advantage of statically linked executables, but in my opinion, it should be only used in special cases.
Click to expand...
I fully agree. Don't be tempted to statically link everything just because in some specific cases it's ever so slightly faster. Use it with caution and make sure you understand the implications.
 
Statically linked in libraries are a major pain in the a** because there's absolutely no way you can ever update the library code that has been copied from the library archive to the executable other than recompiling the whole program from sources. Sometimes recompilation just isn't an option because the sources don't compile anymore or the program is a closed source one.
 
bkouhi said:
Also, according to /usr/ports/Makefile, statically linked executables are much faster:

Code: 
# /rescue/sh is statically linked and much faster to execute than the
# dynamically linked /bin/sh.  This is significant for targets like
# make index that execute the shell tens of thousands of times.
.if exists(/rescue/sh)
INDEX_SHELL=            /rescue/sh
.else
INDEX_SHELL=            /bin/sh
.endif

So, this is another advantage of statically linked executables, but in my opinion, it should be only used in special cases.
Click to expand...

Ok, well, I can see using it in special cases but the library will be loaded one way or another. Just within the executable or not. So if five programs are statically linked to libc then libc is 'loaded' five times. Dynamic loading would require some extra steps but am I also to assume that libc then would 'be in memory five times'?
 
You must log in or register to reply here.
Back
Top