Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Aug 2008 17:53:55 +0300
From:      Giorgos Keramidas <keramida@freebsd.org>
To:        "Krishna Mohan Gundu" <gkmohan@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: A few questions from a current linux user
Message-ID:  <878wv361rw.fsf@kobe.laptop>
In-Reply-To: <70ec82800808110415s22fe82d1kea2b57551929f7e6@mail.gmail.com> (Krishna Mohan Gundu's message of "Mon, 11 Aug 2008 04:15:07 -0700")
References:  <70ec82800808072020h5aafa48axe4140c5eeb229854@mail.gmail.com> <873alf9duf.fsf@kobe.laptop> <70ec82800808110415s22fe82d1kea2b57551929f7e6@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Aug 2008 04:15:07 -0700, "Krishna Mohan Gundu" <gkmohan@gmail.com> wrote:
>>> 2) Is it possible to compile multiple versions of gcc? If so what is
>>> the best way to do it?
>>
>> Yes, of course.
>>
>> The "base system" of FreeBSD includes _one_ version of gcc, installed as
>> `/usr/bin/gcc', but this does not mean that you are limited to *that*
>> version only.  You can use the Ports tree to install one or more
>> versions[...]
>>
>>  # pwd
>>  /usr/ports/lang
>>  # ls -ld gcc* | nl
>>       1  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc-ooo
>>       2  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc28
>>       3  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc295
>>       4  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc32
>>       5  drwxr-xr-x  3 root  wheel  - 512 Jul 22 05:03 gcc33
>>       6  drwxr-xr-x  3 root  wheel  - 512 Jul 29 04:46 gcc34
>>       7  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc41
>>       8  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc41-withgcjawt
>>       9  drwxr-xr-x  3 root  wheel  - 512 Jul 22 05:03 gcc42
>>      10  drwxr-xr-x  3 root  wheel  - 512 Jul 17 03:01 gcc42-withgcjawt
>>      11  drwxr-xr-x  3 root  wheel  - 512 Jul 29 04:46 gcc43
>>      12  drwxr-xr-x  3 root  wheel  - 512 Aug  7 02:25 gcc44
>>  #
>
> So I believe each gcc port keeps track of various dependencies and
> their versions for a chosen gcc version. However if I need gcc40 (lets
> say, not available from ports) or if I need to enable certain features
> that ports disable then I guess I am on my own in that there are no
> guarantees that it will compile.

Then it's usually much easier to tweak the port than start from scratch.
The Ports tree also includes various patches, updates and it supports a
lot of things other than ``run the ./configure script with all the right
options''.  Some of these extra features are:

  * Dependency tracking of the package.

  * Conflicts tracking.  If there are possible conflicts with already
    installed packages, you will get notified.

  * Recursive or simple one-port fetching of all the sources from their
    standard FTP, or HTTP site, including checksum verification of the
    distfiles.

  * Patching of the source tree with `make patch', as an integrated part
    of the port itself.

  * Package registration in `/var/db/pkg'.  With this comes also the
    ability to pkg_delete the installed port in one, well-defined step.
    The alternative of manually tracking what was installed, where it
    was installed, which files it touched or added, and so on, may also
    work, but it's not really as nice as pkg_add/pkg_delete.

  * Package creation.  You can build on one system, then `make package'
    and transfer the pre-compiled port to another system (i.e. your
    small sub-notebook EeePC that can do better things than build gcc
    all the time).

Enabling a new option in a port is often just a matter of editing the
port Makefile and adding a few extra arguments to CONFIGURE_ARGS, i.e.:

    # I like my gcc ports to have --enable-foo too (keramida)
    CONFIGURE_ARGS += --enable-foo

Then you get to keep all the nice features of Ports, and if you find the
new option useful, you can send it back to the Port maintainer :)

> Coming from linux background, the different way of managing base
> system and ports bothers me.  I understand the reasons behind the
> division but not the necessity to manage them differently.  For
> example how would I know if a package is in the base system or not?
> Looks like for ports this can done with 'make search name=whatever'.
> Is there an equivalent of freebsd-update for ports?

The separation comes with its own advantages.  For example, if you are
tracking the 6.X-STABLE branch of the base system, then you can keep
updating the base system as many times as you want and leave the Ports
unchanged.  The binary compatibility of the 6.X-STABLE branch guarantees
that a thirdparty package you compiled on 6.0-RELEASE will keep working
with a base system of 6.1-RELEASE, 6.2-RELEASE or 6.10-STABLE.  As long
as there are not major security issues with a specific port you do *not*
have to upgrade it.

The base system itself is not a package, and all the ports intstall
software _exclusively_ under `/usr/local'.  So you know that something
is part of the Ports because it is installed under `/usr/local'.  The
opposite is also true: if something is in /usr/{bin,sbin,lib} then in a
well-managed FreeBSD system it is *not* part of the Ports, but of the
base system.

To answer the question about updates, yes, there are tools like
freebsd-update for Ports too.  They are usually Ports themselves too,
and they are found in the `/usr/ports/ports-mgmt' category of software.
AFAIK, the most popular ones are `portupgrade', `portmanager' and
`portmaster'.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?878wv361rw.fsf>