gmake[2]: execvp: m68k-rtems-gcc: Too many levels of symbolic links

Ralf Corsepius corsepiu at
Tue Feb 24 06:44:29 UTC 2004

On Tue, 2004-02-24 at 00:19, Gordon Scott wrote:
> On Mon, 23 Feb 2004, Joel Sherrill wrote:
> > In general, a short path is better than a long path for a number of
> > reasons. :)
> Yes indeed. I wonder that so many applications/toolsets come with their
> own separate install areas. Perhaps that's the influence of M$.
Definitely no. 

The main reason for using /opt/<package> is to avoid package conflicts
with vendor-supplied and local packages.

Other reasons are
* Allowing network'ed installations: Unlike /usr and /usr/local,
/opt/<package> can easily be shared (e.g. nfs-mounted) across networks.

* Easy deinstallation: rm -rf /opt/<package>

* Easier access control: You can easily set up special permissions to
allow read/write access to files below a common root (/opt/<package>)
than to packages being spread into various locations of your system.

A nice side effect: Though current RTEMS toolchain binaries are built on
RH-7.3 they are usable on many other Linux distributions (AFAIK, on
newer RH, SuSE, Debian and probably many others).

> A few years back it would be just ~/bin:/usr/local/bin:/bin:/usr/bin
/ and /usr are reserved for vendor supplied packages. 

/usr/local is reserved for non-networked, local packages augmenting
packages in / or /usr.

/opt/<package> is reserved for larger 3rd party packages such as RTEMS.

This all is covered by the FHS/LSB and thereby (at least semi-mandatory)

> Now it's about 400 characters.

> > I recommend putting the RTEMS directory first in your PATH as a
> > general rule because if you need the RTEMS speific automake or
> > autoconf, then it MUST be ahead of the system default.
automake and autoconf are the only RTEMS tools that potentially conflict
with vendor supplied packages. All others don't.

More precisely: We need to ship autoconf/automake because we need more
recent versions of these tools than most vendors ship and most users
have installed and because some vendors ship broken or malfunctioning
(esp. Debian) versions.
People using recent systems will not need them.

> It's now ahead of the defaults, but previously was not.
Except of autoconf and automake, this should not matter.

The "Too many level of symlinks" error you have reported indicates
having a self-recursive link somewhere.

>  But it's still
> after the toolset for eCos, which I'm also considering for this app,
> and jdk. Maybe it's time to start mapping PATH specifically for each
> project .. Tedious and mistake-prone, though :-(
Well, we don't have any control over jdk nor eCos nor the OS you are
using (BTW: I don't recall if you already told us what you are using),
therefore this is the easiest way for us to handle.

Remember, all of RTEMS and its toolchains is open source, so you have
the freedom to rebuild and install to whatever location you prefer, if
you really want to.


More information about the users mailing list