#11 apvsys does not find registered tool


Email to: koenraad.schelfhout@alcatel.be

Suppose I have in my toolspec the following entries:


When looking to the installations, I see that only for
binutils/v2.14 and for gcc/2.95.3 the command c++filt
is registered. There is no c++filt in the bin-directory
for gcc/v3.3.3

With the toolspec listed above, I get following when
I run apv -a c++filt

WARNING: The version gcc/v3.3.3 that you specified in
<toolspec> does not exist for this O.S.!
Executable found at: /ap/tools/bin/c++filt:

10 registered versions ....
Matched toolspec: NULL
Chosen version from: "NULL"

However, commenting out the line gcc/v3.3.3, selects
If nothing is given (empty toolspec), gcc/v2.95.3 is
taken (default for that O.S.)

- although there are registered versions for a tool
apvsys does not seem to find them always.
- I have the impression that the way that apvsys
looks for a tool is not failsave.

From my experiments, it looks that apvsys does the
a) when looking for a tool/version for a specific
command(c++filt), apvsys first checks if the
command is registered for a specific tool. The
first one it encounters is (gcc). It does not look
or check if the version is ok.
b) When it finds one, it assumes that for the "version"
listed in the toolspec (v3.3.3) the command exists.
This is not the case in my example.
So it fails to find a registered command.


  • Logged In: YES

    Hi Koen,

    Thank for your feedback.

    It is not a bug, it is the normal behabior. Effectively this
    is the only way to take care of multiple O.S. conflict.

    May be it could be useful to add an environment variable to
    bypass this check that can be annoying in some
    circonstances. What do you think about ?

    Thanks again and good luck


    • assigned_to: nobody --> apvsys
    • status: open --> open-rejected
  • Logged In: YES

    I forgot to say that it is also important to avoid the risk
    to mix different versions of the same tool. Actually, if a
    command exists in a version of a tool and you specify
    explicitely another version of this tool that does not
    contain this command, it would be dangerous to accept this
    command. Effectively,the user could be convince that the
    command comes from the version of the tool he specified in
    his tool-spec.

    I'm writing this comment and I realize that the behaviour is
    maybe correct but the warning message not and it should be