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



## ikbendeman (Sep 10, 2013)

What does the knob in make.conf

```
WITH_NEW_XORG=YES
```
do?

Also, can anyone shed light on

```
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?


----------



## fonz (Sep 10, 2013)

ikbendeman said:
			
		

> And isn't PKGNG default nowadays?


No. It will be when 10.0-RELEASE comes around, but it isn't yet. You may be thinking of PC-BSD.


----------



## wblock@ (Sep 10, 2013)

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 (Sep 11, 2013)

> BUILD_STATIC = instead of using dynamic shared libraries, build them into the code


And which is the best choice?


----------



## wblock@ (Sep 11, 2013)

It's like all defaults, leave it alone unless you have a good reason to change it.


----------



## SirDice (Sep 11, 2013)

sk8harddiefast said:
			
		

> And which is best choice?



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.


----------



## bkouhi (Sep 11, 2013)

Also, according to /usr/ports/Makefile, statically linked executables are much faster:


```
# /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.


----------



## SirDice (Sep 11, 2013)

bkouhi said:
			
		

> Also, according to /usr/ports/Makefile, statically linked executables are much faster:


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.


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.


----------



## kpa (Sep 11, 2013)

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.


----------



## ikbendeman (Sep 12, 2013)

bkouhi said:
			
		

> Also, according to /usr/ports/Makefile, statically linked executables are much faster:
> 
> 
> ```
> ...



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'?


----------

