> concerning compile warnings on HP-UX. Ignore the ones about compiler
> limits and empty files. The empty file one is due to ifdef's in these
> files that make the file empty for the compiler (the files are needed
That was clear. I was just curious whether you get the same warnings.
Do you ?
> for some platforms). No idea about the duplicate symbol for AIX. Does it
I thing that the problem on AIX comes from libCint.a which has it's own
copies of (.)__priority0x80000000 symbols, and then when the
/usr/lpp/xlC/bin/makeC++SharedLib script tries to introduce the next
ones ( in form of object files ) when creating libRoot.a, the linker
gets them doubled. It may be that they are exactly the same ( the same
standard object files ), but it may also happen, that these object files
are always automatically created ( compiled from some automatically
generated c/c++ code ), thus these two copies may be different. I have no
time to look into it, but I really think someone should precisely
investigate it ( the resulting root executable seems to work, but maybe
this problem is somewhere there and some day ... ).
Do you get these warnings on AIX 4.1 ?
BTW. I think you won't see this problem on AIX 3.2, only on AIX 4.1.
I think this is related to some subtle changes in the
/usr/lpp/xlC/bin/makeC++SharedLib script itself.
> work? Concerning g2root. It is currently STILL written in fortran and
> uses recursive calls (not supported by standard f77 and therefore causing
> problems on a number of machines). We plan a C++ version soon.
Does this mean, that you confirm that you also cannot built g2root on both
AIX 4.1 and HP-UX 9 ?
( BTW. the "-AA" option on HP-UX seems to switch ON recursive calls, but
unfortunately it switches OFF some kind of "intrinsic extensions", and I
couldn't find any other option which I could add to get them, too )
> Concerning a user configurable PROOF. This will be for the final v1.00
Nice to hear it. I was seriously afraid that it would go the PIAF way
( totally central maintenance ).
My 5 cents here. The .proof.conf file could as a fourth parameter
in the "slave" command line contain the full path ( and name ) to the
slave executable - it should recognize environment variables in path. This
would ( in future ) allow to run slaves on machines which have different
file structures and even maybe on machines which have different machine
architectures ( this way someone running root on hp-ux could connect
slaves on aix, for example ). Another possible extension would be to allow
different userids on different slaves ( possibly this is what the "user"
command line in .proof.conf is already intended to do using the .netrc ).
On principle I am thinking about a situation where the proof cluster would
be built of machines which have different architectures, which may or
may not share file systems ( and even if they do the absolute/relative
paths may be different ), which have different users and userids.
The only thing that these machines have common is tcpip access, and the
possibility to run user's tasks ( using .rhosts or even better .netrc ).
The user should be able to run his proof sessions without requiring any
special support in any /etc/... files nor from any special proof daemons,
just by specifying userids, master/slave executables, data files, ... .
Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:18 MET