Some port won't build with gcc46

M

morpho

Hi,

This is my first post in FreeBSD community and note that i'm a new BSD user since yesterday. My first goal is to use FreeBSD for my desktop and optimize as the best as I can. I have made some change in make.conf to build ports using gcc46 to benefit the best compilation time. But, on a couple of them I get some undefined error when building the ports. I have made some test and research and finally I can confirm that the problem is cause by gcc46.

here is my make.conf

Code: 
# =============================================================================
# DEFINITION DU TYPE DE PROCESSEUR POUR L'OPTIMISATION DE LA COMPILATION
# =============================================================================

CPUTYPE?= athlon64

# =============================================================================
# DEFINITION DU TYPE DE PROCESSEUR POUR L'OPTIMISATION DE LA COMPILATION
# =============================================================================

CFLAGS= -O2 -fno-strict-aliasing -pipe
CXXFLAGS+= -fconserve-space

MAKE_JOBS_NUMBER= 6

# =============================================================================
# DEFINITION DU TYPE DE PROCESSEUR POUR L'OPTIMISATION DE LA COMPILATION
# =============================================================================

MAKE_SHELL?= sh

# =============================================================================
# OPTION DE COMPILATION POUR LE KERNEL
# =============================================================================

KERNCONF= MYKERNEL GENERIC
COPTFLAGS= -O -pipe

# =============================================================================
# OPTION DE COMPILATION POUR LANGUAGE ET ENCODAGE A COMPILER
# =============================================================================

DOC_LANG= fr_CA.ISO8859-1 fr_CA.UTF-8 en_US.ISO8859-1 en_US.UTF-8

# =============================================================================
# UTILISATION DE CCACHE
# =============================================================================

.if !defined(NO_CACHE)
CC= /usr/local/libexec/ccache/world-cc
CCX= /usr/local/libexec/ccache/world-c++
.endif

.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
.endif

# =============================================================================
# UTILISATION DE PERL
# =============================================================================

PERL_VERSION=5.10.1

# =============================================================================
# UTILISATION DE GCC 4.6
# =============================================================================

.if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc46)
CC=gcc46
CXX=g++46
CPP=cpp46
CFLAGS+=-mssse3
.endif


When I get the error, I need to editing the make.conf and comment these lines, restart the build and after that I can build it successfully.

Code: 
.if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc46)
#CC=gcc46
#CXX=g++46
#CPP=cpp46
#CFLAGS+=-mssse3
.endif

After the fact, I would like to know if the use of gcc46 is stupid, if yes which version of gcc you suggest to me, don't forget, I would like to use mssse3 optimisation. Otherwise, which method could I use to deal with ports that don't build with gcc46.

Thanks and Regards
 
Stop "optimizing", this isn't Gentoo. Remove all CFLAGS (and variants) from /etc/make.conf, and use the system compilers.
 
If you're sure it's not a compiler bug, i.e. reproducible on latest stable branch of gcc (gcc45), then you can try to document it via GNATS. But make sure that you don't do smth funny with CFLAGS. While ports are not guaranteed to work with any non-base compiler someone may offer you a fix. For example, www/firefox used to fail build in the past, now it builds fine thanks to bf.

OTOH, there is ongoing effort to make ports build with clang. This may or may not help build failures with lang/gcc*.
 
Thanks Dandelion for your great reply. Sorry Dutch, but i'm not agreed with your post. Optimizing can be a good way to learn. Otherwise, we never can be better... Another question, about stable branch: How I can know which port are consider in stable branch.

Thanks and regards
 
"Optimizing" with gcc options does not always result in improvements, and even when it does they may not be measurable. Besides that, ports which can use gcc optimizations generally handle that already, and overriding it in /etc/make.conf makes things worse, not better.

If you're interested in learning by breaking things, I've been compiling a list:
Code: 
Do change root's shell to bash.
Do use chmod 777 on lots of things.
Do set CFLAGS to heavily optimized values.
Do enable root login for ssh.
Do enable telnet.
Do use sysinstall to edit system settings.
Do install applications from bare source.
Do edit /etc/defaults/rc.conf and /boot/defaults/loader.conf.
 
I think you are totally wrong wblock

please refer to http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/article.html

you will find this part:
4 Impact on the binary performance
Using GCC version 4.4 with SSSE3 instruction set enabled (if supported by the CPU) may yield up to 10% average increase in binary performance. In certain tests, the results show more than a 20% performance boost (e.g. in multimedia processing).

As I know, i was on the freebsd website.

Improving performance on binary for more than 10%, I suppose that could be great for a desktop... NO ?!

If you're interested in learning by breaking things, I've been compiling a list:

Code:
Do change root's shell to bash.
Do use chmod 777 on lots of things.
Do set CFLAGS to heavily optimized values.
Do enable root login for ssh.
Do enable telnet.
Do use sysinstall to edit system settings.
Do install applications from bare source.
Do edit /etc/defaults/rc.conf and /boot/defaults/loader.conf.
Click to expand...

Did you try ??? I never asked you to do this.
 
Morpho, by all means: shoot yourself in the foot all day long. Just don't expect to find accomplices here. The advice is: leave the system, flags and compilers well alone, don't try to outsmart the hundreds of committers and ports maintainers who know infinitely more about this operating system's optimizations and internal logic than you do. FreeBSD advances on its own time schedule and on its own terms.
 
Thanks for your answer Dutch. I understand that applying what this article explain can cause problem.

don't try to outsmart the hundreds of committers and ports maintainers who know infinitely more about this operating system's optimizations and internal logic than you do
Click to expand...

I did not post here with this intention. I have asked a question and got some answer (some better ... and some stupid)

For now, I only want to use port on all software I need. I want to build my system for my CPU specifc and if this possible improve performance on binary without always need to tune something to do the work.

Does this is possible in FreeBSD ?

Thanks and Regards
 
Define CPUTYPE?= in /etc/make.conf. That's all you'll ever need to do to optimize for your CPU. See /usr/share/examples/etc/make.conf for allowed types. I see you have athlon64, so that should be fine. All other flags and settings should be removed.
 
Great ! I will do this ! If you remark, I'm using CCACHE and I suppose that could not break the build but simply improve the compilation time. Is this right ?
 
You'll find quite a few CCACHE users here (for ports and base system), and this should generally speed things up. Search the forums for possible pitfalls.
 
morpho said:
I think you are totally wrong wblock
Click to expand...

That's unusual, usually I'm just mostly wrong.

please refer to http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/article.html

you will find this part:
4 Impact on the binary performance
Using GCC version 4.4 with SSSE3 instruction set enabled (if supported by the CPU) may yield up to 10% average increase in binary performance. In certain tests, the results show more than a 20% performance boost (e.g. in multimedia processing).
Click to expand...

Sure. "Up to" 10%, or maybe 20%. If the port will build at all, of course. But "up to" includes 0%. And -10%. Unless you have something that isn't running fast enough, this is a form of premature optimization.

Improving performance on binary for more than 10%, I suppose that could be great for a desktop... NO ?!
Click to expand...

Sure. If there is actually an improvement. If the ports can be adjusted to build and run correctly.

Consider a more cautious approach. Install the system, get it working, become familiar with it, then optimize things that aren't fast enough.
 
Hi wblock,

I understand your approach and I will try to apply it on my desktop. At my point of vue, I have learn on how to manage ports today. I think this is a good way to learn because that's the first time I use the ports system. Before, I only have to do apt-get install xxx or pacman -S xxx or ./configure && make install clean to install some software. Today I want to build all from ports and .. you're right, I have broke my system.

The only thing that put me frustated is about this post ...
If you're interested in learning by breaking things, I've been compiling a list:

Code:
Do change root's shell to bash.
Do use chmod 777 on lots of things.
Do set CFLAGS to heavily optimized values.
Do enable root login for ssh.
Do enable telnet.
Do use sysinstall to edit system settings.
Do install applications from bare source.
Do edit /etc/defaults/rc.conf and /boot/defaults/loader.conf
Click to expand...

Please consider that this problem is solved and the best in this case is I have learn something.
Thanks for your help and sorry for the inconvenience.

Regards
 
morpho said:
The only thing that put me frustated is about this post ...

(WB: unfunny list of "things to try")

Please consider that this problem is solved and the best in this case is I have learn something.
Thanks for your help and sorry for the inconvenience.
Click to expand...

I apologize for that. It was supposed to be a funny list of things we see done regularly that turn out to be really memorable mistakes. It's more of an in-joke, and not that funny anyway. I'm sorry, and hope it hasn't given a bad impression of the forums. Everybody else here is actually pretty nice.
 
You must log in or register to reply here.
Back
Top