From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3087 invoked by alias); 31 Jul 2008 04:46:36 -0000 Received: (qmail 3078 invoked by uid 22791); 31 Jul 2008 04:46:35 -0000 X-Spam-Check-By: sourceware.org Received: from web57002.mail.re3.yahoo.com (HELO web57002.mail.re3.yahoo.com) (66.196.97.106) by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 31 Jul 2008 04:46:16 +0000 Received: (qmail 91099 invoked by uid 60001); 31 Jul 2008 04:46:14 -0000 Received: from [220.255.7.207] by web57002.mail.re3.yahoo.com via HTTP; Wed, 30 Jul 2008 21:46:14 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 31 Jul 2008 10:49:00 -0000 From: Unga Reply-To: unga888@yahoo.com Subject: Re: GCC build on FreeBSD 7.0 questions To: Ian Lance Taylor Cc: gcc-help@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <792510.90397.qm@web57002.mail.re3.yahoo.com> X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg00323.txt.bz2 --- On Wed, 7/30/08, Ian Lance Taylor wrote: > From: Ian Lance Taylor > Subject: Re: GCC build on FreeBSD 7.0 questions > To: unga888@yahoo.com > Cc: gcc-help@gcc.gnu.org > Date: Wednesday, July 30, 2008, 10:14 PM > Unga writes: > > > 1) grep -o '/usr/lib.*/crt[1in].*succeeded' > dummy.log > > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o > succeeded > > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crti.o > succeeded > > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crtn.o > succeeded > > > > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o > is > > actually /usr/lib/crt1.o, why not refer directly? > > It has to do with preserving the ability to move the entire > gcc > installation tree to a new location and have it continue to > work. > > > How it refer /usr/lib/libc.so is as -lc > (/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../libc.so)! > > Look at the -L options passed to the linker to see what > happens there. > > > How to fix this? > > It's not a bug. Don't fix it. > > > > 2) Some files are installed in > /usr/lib/gcc/i386-unknown-freebsd7.0/ > > and /usr/libexec/gcc/i386-unknown-freebsd7.0/. I > prefer files to be > > installed in /usr/lib/, /usr/libexec/, etc. Eg. crt* > files > > (crtbegin.o, crtend.o, etc) to be installed in just > /usr/lib/ . How > > to get this done? > > You can just move them by hand if you like. gcc will still > be looking > for those directories, though. Those directories exist so > that you > can install multiple versions of gcc for multiple targets > on one > machine. > > > > 3) I don't think I need header files in > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include and > > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include-fixed. > Normally > > they pollute build environment. Any way to not install > them too? > > Again, you can mix them by hand if you like. Be sure that > there > aren't files with the same name in the two directories, > although I > don't think that happens these days. > > > These issues all arise in order to support complex > installation > scenarios. They aren't useful for simple cases like > yours, but on > the other than they also don't hurt. The best approach > is to not let > it bother you. > Hi Ian Thanks for the reply. I overlooked the fact multiple GCC installations. As the issues I mentioned makes no harm, I have decided to just leave it like that. I'm not sure whether it slightly makes it slow to compile and link. Kind regards Unga