Make options for a desktop

M

max21

I know there are certain options that can be used for MakeBuildWorld for servers, jails and ports, but now I want to MakeBuildWorld for my gnome-2 desktop once again, but this time I want to add some options.

Are these options safe and workable for my FreeBSD 10.1p4 gnome-2 desktop?

I am especially concern about BUILD_STATIC, because that is what I want to use for ports as well as the base system while the WORLD is build.

/etc/make.conf
Code: 
# KERNCONF=NBIT
FORCE_MAKE_JOBS=    yes
MAKE_JOBS_NUMBER=4
BUILD_STATIC=        yes
WITHOUT_DEBUG=    yes
NO_PROFILE=        yes
WITH_PKGNG=        yes

WITHOUT_NLS=        yes
WITH_X11=        yes
WITH_NEW_XORG=    yes
WITH_PKGNG=        yes
QT4_OPTIONS= CUPS QGTKSTYLE ....### Virtualbox use QT4
KDE4_PREFIX=/usr/local ....### I don’t use KDE desktop but QT4 has relation to KDE

NO_WERROR=
WERROR=

# #########################################
# #########################################
##NO_WARNING_PKG_INSTALL_EOL=yes
##NO_WARNING_PKG_INSTALL_EOL="YES"
##FORCE_PKG_REGISTER=yes
#WITHOUT_CHECK=yes
#WITH_OPENSSL_PORT=yes
#DISABLE_VULNERABILITIES=yes

#WITH_ICONV= .... NEVER INCLUDE THIS unless
#................you know what you're doing
Thanks in advance
 
FORCE_MAKE_JOBS might break something. It's not really helpful anyway. Why do you want BUILD_STATIC?
 
wblock@ said:
FORCE_MAKE_JOBS might break something. It's not really helpful anyway. Why do you want BUILD_STATIC?
Click to expand...

Thanks wblock@: I removed FORCE_MAKE_JOBS, but I found another interesting option.
MALLOC_PRODUCTION=y . I find this stuff but most never have a definition and google is really not that much help because who want to optimize desktops for FreeBSD other than me? :( Mostly everything is about servers.

1 – Memory usage; each running process is a program (or takes a program to run it) and for every program that runs it must include the entire c-lib for each process in memory. With gnome, office and much more running we may have more than a 200-1000 process just to get them open. 200 x c-lib = big waste of memory

2- because there is no question that an executable runs MUCH faster than any program(s), including those that need (sh) and the translator, who may copy the c-lib to memory for each in order to run. Half of this is just guesting, but there is only one way to know for sure. BUILD_STATIC and try to learn.

3- when using commands like netstat, top and such I don't want to see all that extra information that may be included for each running process. Most of it is only a repeat of what and where each c-lib is in memory, I'm betting.

4- What could possibly be more fun, and what other OS would offer the opportunity to do so. The best thing of all; if something interfere with future upgrade, you can rebuild again but WITHOUT.

WITH_ICONV is the worse and I removed it.
http://ximalas.info/2013/08/26/freebsd-and-with_iconv/

I wonder are there options that must have a mother option in order to be actually included in the build, or are they all independent of one another? Like would MALLOC_PRODUCTION need some kind of C option ahead of it like CFLAGS=? Something like the link above seems to indicate. Google database don't know, so I really don't expect anyone else to know.
 
Using static binaries actually increases memory usage because each program's address space contains copies of the libraries it uses. With dynamic linking the OS needs to load a specific library into memory only once. If a program then uses the library the OS will simply map it into the program's address space, i.e. programs that use a specific library share the part of memory where the OS put the library into (that's why dynamic libraries have a .so suffix: shared object).

I'd suggest you don't use any fancy options at all.
 
Last edited:
WITH_NEW_XORG= yes and WITH_PKGNG= yes knobs are obsolete. Also, WITH/WITHOUT options are deprecated. Use OPTIONS_SET, OPTIONS_UNSET
It's better just to remove everything except MAKE_JOBS_NUMBER and add OPTIONS_UNSET= EXAMPLES DOCS
 
Using static binaries actually increases memory usage because each program's address space contains copies of the libaries it uses. With dynamic linking the OS needs to load a specific library into memory only once. If a program then uses the library the OS will simply map it into the program's address space, i.e. programs that use a specific library share the part of memory where the OS put the library into (that's why dynamic libraries have a .so prefix: shared object).
Click to expand...

Hi worldi; you are absolutely correct. I don't know C, but I read blogs and benchmarks to digest as much I can about it. Thank you very much for correcting my imaginary statements…. and don't anyone think for one minute that I am smart; I'm just trying very hard to be. You can blame that on the forum formatting rules.

I’ll clean up by saying *nothing is faster than a c-compiled program other than an application well-written in pure machine language*. You may never feel the differences, but your machine will, especially at crunch-time. Its like millions of cpu clock time faster on a FreeBSD server, and way more than half of that on a desktop.
I'd suggest you don't use any fancy options at all.
Click to expand...
Worldi, it was not easy to dig them all out, so which one(s) would you suggest not using, and why?
. .^. . that's why dynamic libraries have a .so prefix: shared object
Click to expand...
You must have read my mind because I see this as a starting point. I was actually thinking how to know the difference when FreeBSD is running a static binary. Could you shed more light on this?
 
Wblock@: being in the rush to get start, I thought I removed FORCE_MAKE_JOBS, but BuildWorld had already completed in 2 hours and 3 minutes using everything listed except WITH_ICONV. But I removed FORCE_MAKE_JOBS and I added MALLOC_PRODUCTION at BuildKernel time. What surprise me is that both build time were near exact, like one minute, without options. I try to record everything to make comparisons when applicable. Anyway, I been using it for hours and nothing is difference that I can see. I’m going to give it a day or two so I can throw everything at gnome copy this or that, LibreOffice, wait-clock holding up things. I do this to see if I get those little stalls that a FreeBSD heavy-weight desktop system gives us from time to time. If it helps there, only then will I become a believer. But I’m going to give it a extra chance and delete all installed ports and rebuild them with those options or most suggested posted options, if any. Than take it from the top with the 10.1 CD install while I got the spirit. I must be lucky because FORCE_MAKE_JOBS have not hurt a thing that I can see so far. But I think it best to remove it anyway as you suggest, because it might come back to bite me at freebsd-update time. BTW: another reason why is for peace of mind. I can forever say, I tried it.


WITH_NEW_XORG= yes and WITH_PKGNG= yes knobs are obsolete. Also, WITH/WITHOUT options are deprecated. Use OPTIONS_SET, OPTIONS_UNSET
It's better just to remove everything except MAKE_JOBS_NUMBER and add OPTIONS_UNSET= EXAMPLES DOCS
Click to expand...
Hi abishai, So that is what worldi was saying "remove everthing" haha. I'm so glad I did it all ready. I just hope BUILD_STATIC and MALLOC_PRODUCTION took since it's not in your list. May I ask you the same type question that I just ask worldi ... Would you know how I can prove that these two options took and detect it while running? Also could you post or point to where the entire list, or some of those options are, that are not deprecated?

Anyway, I'm not sorry I spent the time, because it makes it more interesting to see what actually took or not. I'm not saying you guys are wrong, but I have seen beginning with FreeBSD 10.0 and above do things that people said it could not do, or would not do anymore. And I sure that I'm not the only person in the world that have witness something this, at lease once. I pay attention very deeply at times, expecting known failures (obsolete something), but here it comes out of nowhere. Read this. I done ran out of reasons why things just happen.

https://forums.freebsd.org/threads/is-freebsd-vulnerable-to-ghost.50166/

Ah, btw, as I chatted with wblock@, I'm going to do it all over again after checking what I have now and use OPTIONS_SET, OPTIONS_UNSET and other the way you suggested for everything. I see no reason to quit now.
 
abishai said:
and add OPTIONS_UNSET= EXAMPLES DOCS
Click to expand...
This should be
Code: 
OPTIONS_UNSET+= EXAMPLES DOCS
The + is needed to add the options, not using the + would remove all other OPTIONS_UNSET entries.
 
Also, WITH/WITHOUT options are deprecated.
Click to expand...

Hey guys, I'm sorry about interruption and the bloat but I just realize that I forgot to include that the only problem I had with BuildWorld was a typo. I had MALLOC_PRODUCTION-yes instead of MALLOC_PRODUCTION=yes and BuildWorld check strongly forced correction. After correction it build non-stop with no error even after completion!

Would this mean that all options (with the WITH and WITHOUT directives) were all was accepted and where needed? If so, then my theory was correct, and my master-piece is all jack-up for the better :)

I'm an so glad that you guys are showing the proper way to do thing. I will not be staying down here in non-upgradeable land forever.
 
max21 said:
[...]After correction it build non-stop with no error even after completion! Would this mean that all options [...] were all was accepted and where needed?
Click to expand...

Not necessarily. You can have a typo or even an non-existent option which wouldn't broke build, for example
Code: 
BLD_SATIC=something
, it will be silently ignored AFAIK.

As about testing results - ldd(1) comes on mind first for overview of dynamically linked objects - there should be none for statically linked binaries.
 
In general, the default is the safest, most likely work, and best tradeoff of performance versus cost. Setting options in make.conf without being exactly sure what they do is a mistake. These are not magic speed buttons that just need to be discovered, they are go-fast stripes that might also (metaphorically speaking) destroy the engine.

Besides, benchmarking these changes is more difficult than it seems. Takes the same time to compile? Sure... once the files have been read. It really needs a reboot after a change to make sure the caches are empty. Even then, try it three times each way, with reboots before each, to get a real value.

MAKE_JOBS was an option added to the ports system a while back to allow concurrent compiling. Many ports did not support it, but most were fixed. Setting FORCE_MAKE_JOBS causes ports that say they can't be compiled concurrently to be compiled that way anyway. See the problem?
 
abishai; I understand. I’m going to put all of these suggestions in order and follow your golden rules, it match one of the links below. What version of the FreeBSD are you using? I just build my first Penitentiary juggling 4-how-to, Alcatraz, just days ago, and every one of you wardens got to know how I feel. I can’t wait to check back in; but proper Installation with Knobs now comes first. I’m going to start from scratch; FreeBSD 10.1 cd with MATE. If everything was in the FreeBSD handbook, pages would stretch around the world. Any limitations, solutions, new-found possibilities could float anywhere.


Yes Yes, ondra_knezour, Thanks, I could have caught fool's gold fingers. Ldd is all the tool I need. One step at a time, right? First the base-check, than the ports-check, but should I leave the src along?-[] BuildWorld-check, BuildKernel-check . . . case close!

Code: 
# lld /swapon

  libutil.so.9 => /lib/libutil.so.9 (0x800821000)

  libc.so.7 => /lib/libc.so.7 (0x800a33000)

Code: 
# lld /myScript

  ldd: myscript: not a dynamic executable

btw: I was only trying to re-find this first link so to use NO_INET6=YES and that was it . . . It took three days. I never even seen it anywhere else. The last one has a reply that seems very closes to abishai format, but missing the underscore. I got a lot to learn:

http://blog.up-link.ro/freebsd-optimizations-etc-make-conf/

https://wiki.freebsd.org/DefaultDebuggingKnobs

https://forums.freebsd.org/threads/whats-in-your-make-conf.36150/

https://wiki.freebsd.org/Graphics/WITH_NEW_XORG

https://wiki.freebsd.org/SeanBruno/Desktop

https://gist.github.com/clemensg/8827704

http://kernelnomicon.org/?p=164

http://kernelnomicon.org/?p=275


Time to go to work.
 
I just created my near FINAL make.conf file. Unless some kind of major change happen with technology, I plan stay dedicated to AMD-64. I hope *native* means it will works for all 64bit AMD's and up, if not, I got to start all over again with my 10.1 MATE masterpiece. If I'm safe than someday I plan to deal with those C-Build options as I learn how-to. As far as clang options being default, I added them anyway at QT build-time, just in case. And it is compiling pure clang right now, (just-in-case it did not with the others. I know it can't be true but I thought I seen GCC do a few things with x11-servers from time to time). For everything listed below, portmaster proved to me by showing results that all is well. I will never build anything again without it.

Highly recommended by:
http://www.bsdnow.tv/tutorials/ports
Code: 
# ......................      clang will build everything since v10.0 :)
# ......................  
CPUTYPE?=native          #  This is only a start to all the fancy C opts

BUILD_STATIC=yes         #  Should this be default in a FreeBSD system?
                         #  Included or not postmaster -dwv likes it.

WITHOUT_DEBUG=yes        #  I rather back-up than perform trial & error.
NO_PROFILE=yes         #  Avoid compiling profiled libraries.
WRKDIRPREFIX=/ram        #  Compile everything in a ram disk and use ccache
WITH_CCACHE_BUILD=yes

WITH_PKGNG=yes            #  10.0 &nup.  Portmaster request to create it and
                          #  when compiling there are no issues, so I keep it.

FETCH_BEFORE_ARGS=-p4     #  use passive FTP and only use IPv4

                          #  Add a fast mirror for downloading distfiles
MASTER_SITE_BACKUP?= \
http://mirror.symnds.com/FreeBSD/ports/distfiles/${DIST_SUBDIR/}

MASTER_SITE_OVERRIDE?=${MASTER_SITE_BACKUP}         #  try downloading
                                                    #  from it by default

QT4_OPTIONS= CUPS QGTKSTYLE    #  (makes QT4 apps look good in Xfce)
KDE4_PREFIX=/usr/local        #  (makes all QT4 apps go where they are supposed too)
#NO_WERROR=
#WERROR=
# ....................    strip out options the author never want enabled

OPTIONS_UNSET= DEBUG HELP STATIC GNUTLS DOCS EXAMPLES IPV6 \
               PTH IDN LIBIDN NLS PULSEAUDIO JAVA MANPAGES \
               DOCBOOK CUPS TESTS HTMLDOCS BONJOUR GSSAPI \
               APIDOCS NLS

# ................................................
# ................................................
##NO_WARNING_PKG_INSTALL_EOL=yes
NO_WARNING_PKG_INSTALL_EOL="YES"
##FORCE_PKG_REGISTER=yes
#WITHOUT_CHECK=yes
#WITH_OPENSSL_PORT=yes
#DISABLE_VULNERABILITIES=yes
. . . . . . . . . . . . . . . .. . . . .
. . . . . . . . . . . . . . .  . . . . .
Let it default than remove them from the directories if you don’t use it.
#WITHOUT_ICONV=yes    #   NEVER-EVER ... /usr/bin ... /usr/local/bin
                #                  /usr/obj/usr/src/usr.bin/iconv
                 #                  /usr/include/iconv.h
                 #                  /usr/include/sys/iconv.h
                 #                  /usr/src/include/iconv.h
                 #                  /usr/src/sys/sys/iconv.h
It's all about saving more resources for FreeBSD to use with jails and such. That's the real reason why. I'm hoping the OS will run all those heavy-weight desktop applications faster so to get them the heck out the way. you see ... FreeBSD and I have better things to do :)
 
Just a quick note:
Code: 
KDE4_PREFIX=/usr/local
is redundant, as that has been the default since a year or so ago I believe.

Personally I'd add, if you continue using FreeBSD long term, the performance fun will probably wear off eventually and you'll realize the time spent tweaking everything under the sun was a learning experience but little more. Opening the x11-fm/nautilus file manager .2 milliseconds faster after 12 hours of performance tweaking and compiling isn't worth the effort IMO for example. Time is probably better spent learning the intricacies of the OS in which performance is of course a part of, but in the grand scheme of things, a very small part.
 
Just a quick note:
Click to expand...

I just figured that out today after googling the right places, finally. MATE is still GNOME because GNOME applications must exist so that MATE can translate them and eventually turn them all into MATE itself. and after chopping the life out of X11-server, MATE put everything back in anyway to operate on GNOME. But as you said, I have learned a lot behind wasting all of this time. One good thing I got out the deal, I finally build my first jail mixing three how-to that does nearly everything in the most unconventional way and it working. I understand it so well you would think I invented it. Well, thanks to the author and the Almighty Gnome-Team GNOME has a new and better life. Any speed increase is FREE! Another thing I learn; Google is case-sensitive. Small-case everything for FreeBSD brought more FreeBSD related hits. Example; for freshports (sdl-12) while the original case (SDL-12) brought absolutely nothing, at lease for me. Maybe javascript has something to do with it. I hardly every use it. I had four of them missing from ports. That was a half of morning wasted. I almost threw-in my comedian card. I'll dump kde and keep the rest.

Thank you protocelt … I’ll never forget Jack-Just-Quick
 
Opening the x11-fm/nautilus file manager .2 milliseconds faster after 12 hours of performance tweaking and compiling isn't worth the effort IMO for example.
Click to expand...

Protocelt, I can't sleep on that note. I forgot to add I use to be a basement masm programmer for Windows, for years, and I got good at benchmarking everything I done. I would not touch the base-system as I once indicated and there is no glory in using packages. So the 12 hours spent is near same when port-lovers compile ports anyway. Also it will save way more than a few milliseconds; I know CPU. The speed would be tremendous, but in FreeBSD case it will depended on the type of apt that it does touch. You may never know it but the CPU will. And the best thing of all "it cost you nothing" but the same time spend. It seems that no body realize that you never have to do it again until the next release, or never. This was my reason for coming to FreeBSD in the first place. I care nothing much of networking. Benchmarking is my thing because I need to know the real facts. I spend more time trying to explain why than getting around to it. I got over worded post all over the place. What ever the case I will see for myself. Cool, cool ... Thanks man
 
Hey max21,
Here's an "easter egg" for you; all the make/build world KNOBS, all in one place:
/usr/src/tools/build/options/
DO NOTE, some of them are "meta"; for example,
WITHOUT_BIND=true
also nukes all of the other BIND options. make.conf(5) gives greater meaning to all those KNOBS. Happy tweaking! :)

--Chris
 
You must log in or register to reply here.
Back
Top