1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Some port won't build with gcc46

Discussion in 'Installation and Maintenance of Ports or Packages' started by morpho, Jan 4, 2011.

  1. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    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
     
  2. DutchDaemon

    DutchDaemon Administrator Staff Member Administrator Moderator

    Messages:
    10,732
    Thanks Received:
    2,134
    Stop "optimizing", this isn't Gentoo. Remove all CFLAGS (and variants) from /etc/make.conf, and use the system compilers.
     
  3. dandelion

    dandelion New Member

    Messages:
    55
    Thanks Received:
    18
    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*.
     
    morpho thanks for this.
  4. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    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
     
  5. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,561
    Thanks Received:
    2,226
    "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.
    
     
  6. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    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 ?!

    Did you try ??? I never asked you to do this.
     
  7. DutchDaemon

    DutchDaemon Administrator Staff Member Administrator Moderator

    Messages:
    10,732
    Thanks Received:
    2,134
    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.
     
  8. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    Thanks for your answer Dutch. I understand that applying what this article explain can cause problem.

    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
     
  9. DutchDaemon

    DutchDaemon Administrator Staff Member Administrator Moderator

    Messages:
    10,732
    Thanks Received:
    2,134
    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.
     
  10. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    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 ?
     
  11. DutchDaemon

    DutchDaemon Administrator Staff Member Administrator Moderator

    Messages:
    10,732
    Thanks Received:
    2,134
    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.
     
  12. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,561
    Thanks Received:
    2,226
    That's unusual, usually I'm just mostly wrong.

    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.

    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.
     
  13. morpho

    morpho New Member

    Messages:
    6
    Thanks Received:
    0
    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 ...
    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
     
  14. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,561
    Thanks Received:
    2,226
    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.
     
  15. DutchDaemon

    DutchDaemon Administrator Staff Member Administrator Moderator

    Messages:
    10,732
    Thanks Received:
    2,134
    But we're in the process of removing them ;)