From apmasell@engmail.uwaterloo.ca Wed Feb 1 20:42:25 2006 From: Andre Masella Bcc: apmasell@engmail.uwaterloo.ca To: ssingh@uwaterloo.ca Subject: Problems Noted on HarshRealm Date: Wed, 1 Feb 2006 20:42:25 -0500 User-Agent: KMail/1.9 Cc: wmott@uwaterloo.ca Organization: University of Waterloo X-KMail-Transport: EngMail X-KMail-Identity: 1195284952 MIME-Version: 1.0 Message-Id: <200602012042.42503.apmasell@engmail.uwaterloo.ca> X-Original-Status: RO X-Original-X-Status: RSC Content-Type: multipart/signed; boundary="nextPart2437812.jVyhxTpdHK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: X-Length: 2432 X-UID: 99 Status: RO X-Status: ORSC --nextPart2437812.jVyhxTpdHK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I was working on Harsh Realm and I noticed three problems that should be=20 addressed. 1) There is a clock skew between HarshRealm and the NFS server on ECEServ.= =20 This can be demonstrated by running: touch file; date ; stat -c %y file; rm file It shows a clear ~20second clock skew. I am surprised NTP is not in use. 2) GCC will link against /usr/local/lib/libgcc_s.so, but /usr/local/lib is = not=20 the the default library path. ``crle'' shows only /usr/lib in the default=20 library path. This means a program linked with the native C compiler may no= t=20 run! The Solaris dynamic linker configuration in /var/ld/ld.config seems to= =20 be missing. 3) Many of the manual pages are wrong. When testing the clock skew, I went = to=20 read the ``date'' manual, and discovered it was the GNU date manual page=20 which is entirely unhelpful for the Solaris date binary. This is true of wc= ,=20 df, ln, dd and almost anything I pick randomly from the GNU coreutils. There problems are a impediment to usage of HarshRealm. I hope then can be= =20 easily fixed. Thank you. =2D-=20 =2D-Andre Masella (apmasell@engmail, www.eng/~apmasell, 0x10ECBAE0) Windows NT: designed for the Internet. The Internet: designed for UNIX. --nextPart2437812.jVyhxTpdHK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBD4WOSTGn8QhDsuuARAgNIAKDg3uG6tokQyi1wwhuT5qo8n6pD7QCggaK2 uuGJJgrKsR78rsAWb5QgxOo= =060i -----END PGP SIGNATURE----- --nextPart2437812.jVyhxTpdHK-- From apmasell@engmail.uwaterloo.ca Sat Feb 4 11:44:23 2006 From: Andre Masella Organization: University of Waterloo X-KMail-Identity: 1195284952 X-KMail-Transport: EngMail To: Sanjay Singh Subject: Re: discussion ... Re: Problems Noted on HarshRealm Date: Sat, 4 Feb 2006 11:44:23 -0500 User-Agent: KMail/1.9 References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> In-Reply-To: X-KMail-Link-Message: 20703 X-KMail-Link-Type: reply Cc: wmott@uwaterloo.ca MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1167787.cyBqjolT1X"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602041144.33886.apmasell@engmail.uwaterloo.ca> X-Original-Status: RO X-Original-X-Status: RSC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: X-Length: 6490 X-UID: 100 Status: RO X-Status: ORSC --nextPart1167787.cyBqjolT1X Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Look, I'm all for continually improving the systems, but this is the first > complaint I have heard about clock variation. > Yes, I know about NTP, and I could get it going easily enough, but its not > clear to me exactly WHY this is such a big issue for you. > Is there an actual impediment to your productivity in some way? If so, I > would like to know how. We are using make for our design project and make is complaining about the= =20 clock skew and giving me incomplete builds. I've actually used make before on HarshRealm without problems. This seems=20 recent. > > 2) GCC will link against /usr/local/lib/libgcc_s.so, but /usr/local/lib > > is not the the default library path. > I think you are transferring your Linuxisms to Solaris. Solaris does not > use a /var/ld/ld.config so far as I know. Sorry, no. Linux and BSD use an /etc/ld.so.conf. Solaris=20 uses /var/ld/ld.config. This information is in the crle manual page. > Linker paths are held in an environment variable, and this should only be > necessary if you don't compile a library search path into your binary. I > forget the argumentation, but there are compiler arguments to do this. I am familiar with this. The LD_LIBARY_PATH can hold a path for the dynamic= =20 linker to search for shared libraries. However, the dynamic linker will als= o=20 search its own system-wide path found in /var/ld/ld.config. The RPATH/RUNPA= TH=20 can be fed to the linker (with -R). I did add /usr/local/lib to my RPATH to= =20 link my binary. This seems to be some inconsistency in GCC. Solaris's default path for ELF= =20 library (according to the crle manual) is only /usr/lib. However, gcc was=20 compiled and built into /usr/local and correspondingly put it's libraries=20 in /usr/local/lib, out of reach of the Solaris dynamic linker. How odd. > Are you having problems compiling on harshrealm? I compiled the ddd (data > display debugger) package and it chugged along for a half an hour (on a > single CPU) or just a few minutes with parallel make jobs and I had no > problems... its in /opt/ddd-3.3.11 ... ditto for electric-7.00+sfs Looking at these binaries, only ddd uses libgcc_s.so and it managed to pick= up=20 the RPATH since I was able to extract it from the binary. electric however,= =20 does not include /usr/local/lib in the RPATH, and will not run for me as it= =20 requires libgcc_s.so and libstdc++.so. If I create a simple C++ program: #include using namespace std; int main () { string first_name =3D "Bjarne"; return 0; } It will compile, but then fail to run as it can't find libstdc++.so. If I a= dd=20 ``-R /usr/local/lib'', it will then work. I have no LD_LIBRARY_PATH set, as= =20 there is none in /etc/profile. > > ``crle'' shows only /usr/lib in the default > > library path. This means a program linked with the native C compiler may > > not run! The Solaris dynamic linker configuration in /var/ld/ld.config > > seems to be missing. > If that were true, then /bin/ls and everything else in there would fail. > All those things in /bin link to /usr/lib/libc.so.1 and related shared > object libraries. libgcc_s.so is only included if the program tries to do something that cann= ot=20 be done on the hardware directly and instead uses a small function for=20 equivalent functionality. None of the programs in /bin or the C library=20 itself require libgcc_s.so. Again, a program linked with the available C compiler *may* not run. > Exercise for reader: adjust your MANPATH environment variable to search > man pages in the preferred order. Ahh! Thank you, it seems to be pulled out of order from xheir. > But for now I have manually adjusted the time clocks for eceserv and > harshrealm so they are in sync with IST's time server, and commented on > your other issues. Thank you. > I do like and appreciate your willingness to speak up, but there is a tone > of condescention in your letter, just a small one, but perceptible > nontheless. If so, I apologise. It was not intentional. > And speaking frankly, I consider getting skynet (Sun E6500 - 30 CPUs - 30 > GB RAM) going for the ASIC group to be a much higher priority than this, > unless you have more information about your urgencies. [moved] > But I have other things that are higher on the list. So prove to me this > matters and I will do something about it. As some one currently working as a systems adminstrator, I understand you h= ave=20 many things to contend with at once. Only you and your manager are able to= =20 prioritise your work. I believe that some of what I have raised is importan= t=20 (i.e., fixing it will reduce problems in the future), but it is not urgent= =20 (i.e., calling for immediate attention). I hope my message did not imply an= =20 urgency that was not intended. =2D-=20 =2D-Andre Masella (apmasell@engmail, www.eng/~apmasell, 0x10ECBAE0) Every program expands until it can send mail...except Exchange.=20 --nextPart1167787.cyBqjolT1X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBD5NnxTGn8QhDsuuARAhHJAKCEHgMGJ8NcU9fd0l/heYVvDtqoRgCffQZv vW2i2eKwko9YuR7s44txYto= =cDfN -----END PGP SIGNATURE----- --nextPart1167787.cyBqjolT1X-- From ssingh@swen.uwaterloo.ca Fri Feb 3 20:25:09 2006 Return-Path: Received: from swen.uwaterloo.ca (swen.uwaterloo.ca [129.97.92.100]) by engmail.uwaterloo.ca (8.13.1/8.13.1) with ESMTP id k141PHsS066683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 3 Feb 2006 20:25:18 -0500 (EST) (envelope-from ssingh@swen.uwaterloo.ca) Received: from localhost (localhost [127.0.0.1]) by swen.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id k141P9304126 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 3 Feb 2006 20:25:10 -0500 (EST) Date: Fri, 3 Feb 2006 20:25:09 -0500 (EST) From: Sanjay Singh To: Andre Masella cc: wmott@uwaterloo.ca Subject: discussion ... Re: Problems Noted on HarshRealm In-Reply-To: <200602012042.42503.apmasell@engmail.uwaterloo.ca> Message-ID: References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (swen.uwaterloo.ca [127.0.0.1]); Fri, 03 Feb 2006 20:25:10 -0500 (EST) X-Miltered: at persephone with ID 43E40275.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV 0.86.2/1275/Fri Feb 3 13:00:42 2006 on engmail.uwaterloo.ca X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on engmail.uwaterloo.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=ham version=3.0.3 X-Length: 5672 X-UID: 186 Status: RO X-Status: ORAC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: On Wed, 1 Feb 2006, Andre Masella wrote: > I was working on Harsh Realm and I noticed three problems that should be > addressed. > > 1) There is a clock skew between HarshRealm and the NFS server on ECEServ. > This can be demonstrated by running: > touch file; date ; stat -c %y file; rm file > It shows a clear ~20second clock skew. I am surprised NTP is not in use. Look, I'm all for continually improving the systems, but this is the first complaint I have heard about clock variation. Yes, I know about NTP, and I could get it going easily enough, but its not clear to me exactly WHY this is such a big issue for you. Is there an actual impediment to your productivity in some way? If so, I would like to know how. When I was getting harshrealm going, I made an effort to clean up non essential processes and packages, and I may have included the xhier NTP among them. Its easy enough to resync the system clocks off of IST's time server, if its that important. But I have other things that are higher on the list. So prove to me this matters and I will do something about it. > 2) GCC will link against /usr/local/lib/libgcc_s.so, but /usr/local/lib is not > the the default library path. I think you are transferring your Linuxisms to Solaris. Solaris does not use a /var/ld/ld.config so far as I know. Linker paths are held in an environment variable, and this should only be necessary if you don't compile a library search path into your binary. I forget the argumentation, but there are compiler arguments to do this. Are you having problems compiling on harshrealm? I compiled the ddd (data display debugger) package and it chugged along for a half an hour (on a single CPU) or just a few minutes with parallel make jobs and I had no problems... its in /opt/ddd-3.3.11 ... ditto for electric-7.00+sfs > ``crle'' shows only /usr/lib in the default > library path. This means a program linked with the native C compiler may not > run! The Solaris dynamic linker configuration in /var/ld/ld.config seems to > be missing. If that were true, then /bin/ls and everything else in there would fail. All those things in /bin link to /usr/lib/libc.so.1 and related shared object libraries. And there is no Sun native C compiler on the system. Most stuff can be accomplished just fine with gcc. And since Linux seems to be where you cut your teeth, gcc will do you just fine. I can throw one on there if someone needs to run extremely optimized code, but by and large most people prefer gcc cause they know it better, and would not spend the time tweaking Sun's compiler for maximum effect for things like particular processor family and cache sizes, etc. > 3) Many of the manual pages are wrong. When testing the clock skew, I went to > read the ``date'' manual, and discovered it was the GNU date manual page > which is entirely unhelpful for the Solaris date binary. This is true of wc, > df, ln, dd and almost anything I pick randomly from the GNU coreutils. Exercise for reader: adjust your MANPATH environment variable to search man pages in the preferred order. > There problems are a impediment to usage of HarshRealm. I hope then can be > easily fixed. Thank you. I was away for 3 days to see my parents. I do not know if this was forwarded to Bernie or not. But for now I have manually adjusted the time clocks for eceserv and harshrealm so they are in sync with IST's time server, and commented on your other issues. I do like and appreciate your willingness to speak up, but there is a tone of condescention in your letter, just a small one, but perceptible nontheless. And speaking frankly, I consider getting skynet (Sun E6500 - 30 CPUs - 30 GB RAM) going for the ASIC group to be a much higher priority than this, unless you have more information about your urgencies. === E-mail me again if you want to discuss this further. S. From ssingh@swen.uwaterloo.ca Sat Feb 4 14:11:04 2006 Return-Path: Received: from swen.uwaterloo.ca (swen.uwaterloo.ca [129.97.92.100]) by engmail.uwaterloo.ca (8.13.1/8.13.1) with ESMTP id k14JBAIg079268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sat, 4 Feb 2006 14:11:10 -0500 (EST) (envelope-from ssingh@swen.uwaterloo.ca) Received: from localhost (localhost [127.0.0.1]) by swen.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id k14JB4h00491 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sat, 4 Feb 2006 14:11:04 -0500 (EST) Date: Sat, 4 Feb 2006 14:11:04 -0500 (EST) From: Sanjay Singh To: Andre Masella cc: wmott@uwaterloo.ca Subject: Re: discussion ... Re: Problems Noted on HarshRealm In-Reply-To: <200602041144.33886.apmasell@engmail.uwaterloo.ca> Message-ID: References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> <200602041144.33886.apmasell@engmail.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (swen.uwaterloo.ca [127.0.0.1]); Sat, 04 Feb 2006 14:11:05 -0500 (EST) X-Miltered: at rhadamanthus with ID 43E4FC48.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV 0.86.2/1276/Sat Feb 4 10:29:35 2006 on engmail.uwaterloo.ca X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on engmail.uwaterloo.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.3 X-Length: 2950 X-UID: 187 Status: RO X-Status: RC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: Andre, thanks for your reply. You are doing this for 4th year work, and thats sufficient cause for me to optimize things. Now that I know the actual context of your request, I can see you are not fooling around with trivialities. I will probably have more discussion with you as I dig into this. Sometime this weekend I will start looking around in depth. === The time discrepency is definitely relevant to your ability to do your work. And the compiler stuff too, though I have not tuned things to this extent before. You do know your way around Unix. Quite often I get waylaid by recent Linux converts who whine about having /bin/bash for the simple reason that they can use the cursor keys for their command line history; no other reason than that. All of the other advantages of Solaris, like its stability and multiprocessor support are lost on them. Normally on Solaris with gcc, I just compile and it goes, but I have set my LD_LIBRARY_PATH to search through several default library locations and the like. I will get back to you as this evolves. More details to come. S. From ssingh@swen.uwaterloo.ca Fri Feb 3 20:25:09 2006 Return-Path: Received: from swen.uwaterloo.ca (swen.uwaterloo.ca [129.97.92.100]) by engmail.uwaterloo.ca (8.13.1/8.13.1) with ESMTP id k141PHsS066683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 3 Feb 2006 20:25:18 -0500 (EST) (envelope-from ssingh@swen.uwaterloo.ca) Received: from localhost (localhost [127.0.0.1]) by swen.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id k141P9304126 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 3 Feb 2006 20:25:10 -0500 (EST) Date: Fri, 3 Feb 2006 20:25:09 -0500 (EST) From: Sanjay Singh To: Andre Masella cc: wmott@uwaterloo.ca Subject: discussion ... Re: Problems Noted on HarshRealm In-Reply-To: <200602012042.42503.apmasell@engmail.uwaterloo.ca> Message-ID: References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (swen.uwaterloo.ca [127.0.0.1]); Fri, 03 Feb 2006 20:25:10 -0500 (EST) X-Miltered: at persephone with ID 43E40275.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV 0.86.2/1275/Fri Feb 3 13:00:42 2006 on engmail.uwaterloo.ca X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on engmail.uwaterloo.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=ham version=3.0.3 X-Length: 5672 X-UID: 186 Status: RO X-Status: ORAC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: On Wed, 1 Feb 2006, Andre Masella wrote: > I was working on Harsh Realm and I noticed three problems that should be > addressed. > > 1) There is a clock skew between HarshRealm and the NFS server on ECEServ. > This can be demonstrated by running: > touch file; date ; stat -c %y file; rm file > It shows a clear ~20second clock skew. I am surprised NTP is not in use. Look, I'm all for continually improving the systems, but this is the first complaint I have heard about clock variation. Yes, I know about NTP, and I could get it going easily enough, but its not clear to me exactly WHY this is such a big issue for you. Is there an actual impediment to your productivity in some way? If so, I would like to know how. When I was getting harshrealm going, I made an effort to clean up non essential processes and packages, and I may have included the xhier NTP among them. Its easy enough to resync the system clocks off of IST's time server, if its that important. But I have other things that are higher on the list. So prove to me this matters and I will do something about it. > 2) GCC will link against /usr/local/lib/libgcc_s.so, but /usr/local/lib is not > the the default library path. I think you are transferring your Linuxisms to Solaris. Solaris does not use a /var/ld/ld.config so far as I know. Linker paths are held in an environment variable, and this should only be necessary if you don't compile a library search path into your binary. I forget the argumentation, but there are compiler arguments to do this. Are you having problems compiling on harshrealm? I compiled the ddd (data display debugger) package and it chugged along for a half an hour (on a single CPU) or just a few minutes with parallel make jobs and I had no problems... its in /opt/ddd-3.3.11 ... ditto for electric-7.00+sfs > ``crle'' shows only /usr/lib in the default > library path. This means a program linked with the native C compiler may not > run! The Solaris dynamic linker configuration in /var/ld/ld.config seems to > be missing. If that were true, then /bin/ls and everything else in there would fail. All those things in /bin link to /usr/lib/libc.so.1 and related shared object libraries. And there is no Sun native C compiler on the system. Most stuff can be accomplished just fine with gcc. And since Linux seems to be where you cut your teeth, gcc will do you just fine. I can throw one on there if someone needs to run extremely optimized code, but by and large most people prefer gcc cause they know it better, and would not spend the time tweaking Sun's compiler for maximum effect for things like particular processor family and cache sizes, etc. > 3) Many of the manual pages are wrong. When testing the clock skew, I went to > read the ``date'' manual, and discovered it was the GNU date manual page > which is entirely unhelpful for the Solaris date binary. This is true of wc, > df, ln, dd and almost anything I pick randomly from the GNU coreutils. Exercise for reader: adjust your MANPATH environment variable to search man pages in the preferred order. > There problems are a impediment to usage of HarshRealm. I hope then can be > easily fixed. Thank you. I was away for 3 days to see my parents. I do not know if this was forwarded to Bernie or not. But for now I have manually adjusted the time clocks for eceserv and harshrealm so they are in sync with IST's time server, and commented on your other issues. I do like and appreciate your willingness to speak up, but there is a tone of condescention in your letter, just a small one, but perceptible nontheless. And speaking frankly, I consider getting skynet (Sun E6500 - 30 CPUs - 30 GB RAM) going for the ASIC group to be a much higher priority than this, unless you have more information about your urgencies. === E-mail me again if you want to discuss this further. S. From apmasell@engmail.uwaterloo.ca Sat Feb 4 11:44:23 2006 From: Andre Masella Organization: University of Waterloo X-KMail-Identity: 1195284952 X-KMail-Transport: EngMail To: Sanjay Singh Subject: Re: discussion ... Re: Problems Noted on HarshRealm Date: Sat, 4 Feb 2006 11:44:23 -0500 User-Agent: KMail/1.9 References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> In-Reply-To: X-KMail-Link-Message: 20703 X-KMail-Link-Type: reply Cc: wmott@uwaterloo.ca MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1167787.cyBqjolT1X"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602041144.33886.apmasell@engmail.uwaterloo.ca> X-Original-Status: RO X-Original-X-Status: RSC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: X-Length: 6490 X-UID: 100 Status: RO X-Status: ORSC --nextPart1167787.cyBqjolT1X Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Look, I'm all for continually improving the systems, but this is the first > complaint I have heard about clock variation. > Yes, I know about NTP, and I could get it going easily enough, but its not > clear to me exactly WHY this is such a big issue for you. > Is there an actual impediment to your productivity in some way? If so, I > would like to know how. We are using make for our design project and make is complaining about the= =20 clock skew and giving me incomplete builds. I've actually used make before on HarshRealm without problems. This seems=20 recent. > > 2) GCC will link against /usr/local/lib/libgcc_s.so, but /usr/local/lib > > is not the the default library path. > I think you are transferring your Linuxisms to Solaris. Solaris does not > use a /var/ld/ld.config so far as I know. Sorry, no. Linux and BSD use an /etc/ld.so.conf. Solaris=20 uses /var/ld/ld.config. This information is in the crle manual page. > Linker paths are held in an environment variable, and this should only be > necessary if you don't compile a library search path into your binary. I > forget the argumentation, but there are compiler arguments to do this. I am familiar with this. The LD_LIBARY_PATH can hold a path for the dynamic= =20 linker to search for shared libraries. However, the dynamic linker will als= o=20 search its own system-wide path found in /var/ld/ld.config. The RPATH/RUNPA= TH=20 can be fed to the linker (with -R). I did add /usr/local/lib to my RPATH to= =20 link my binary. This seems to be some inconsistency in GCC. Solaris's default path for ELF= =20 library (according to the crle manual) is only /usr/lib. However, gcc was=20 compiled and built into /usr/local and correspondingly put it's libraries=20 in /usr/local/lib, out of reach of the Solaris dynamic linker. How odd. > Are you having problems compiling on harshrealm? I compiled the ddd (data > display debugger) package and it chugged along for a half an hour (on a > single CPU) or just a few minutes with parallel make jobs and I had no > problems... its in /opt/ddd-3.3.11 ... ditto for electric-7.00+sfs Looking at these binaries, only ddd uses libgcc_s.so and it managed to pick= up=20 the RPATH since I was able to extract it from the binary. electric however,= =20 does not include /usr/local/lib in the RPATH, and will not run for me as it= =20 requires libgcc_s.so and libstdc++.so. If I create a simple C++ program: #include using namespace std; int main () { string first_name =3D "Bjarne"; return 0; } It will compile, but then fail to run as it can't find libstdc++.so. If I a= dd=20 ``-R /usr/local/lib'', it will then work. I have no LD_LIBRARY_PATH set, as= =20 there is none in /etc/profile. > > ``crle'' shows only /usr/lib in the default > > library path. This means a program linked with the native C compiler may > > not run! The Solaris dynamic linker configuration in /var/ld/ld.config > > seems to be missing. > If that were true, then /bin/ls and everything else in there would fail. > All those things in /bin link to /usr/lib/libc.so.1 and related shared > object libraries. libgcc_s.so is only included if the program tries to do something that cann= ot=20 be done on the hardware directly and instead uses a small function for=20 equivalent functionality. None of the programs in /bin or the C library=20 itself require libgcc_s.so. Again, a program linked with the available C compiler *may* not run. > Exercise for reader: adjust your MANPATH environment variable to search > man pages in the preferred order. Ahh! Thank you, it seems to be pulled out of order from xheir. > But for now I have manually adjusted the time clocks for eceserv and > harshrealm so they are in sync with IST's time server, and commented on > your other issues. Thank you. > I do like and appreciate your willingness to speak up, but there is a tone > of condescention in your letter, just a small one, but perceptible > nontheless. If so, I apologise. It was not intentional. > And speaking frankly, I consider getting skynet (Sun E6500 - 30 CPUs - 30 > GB RAM) going for the ASIC group to be a much higher priority than this, > unless you have more information about your urgencies. [moved] > But I have other things that are higher on the list. So prove to me this > matters and I will do something about it. As some one currently working as a systems adminstrator, I understand you h= ave=20 many things to contend with at once. Only you and your manager are able to= =20 prioritise your work. I believe that some of what I have raised is importan= t=20 (i.e., fixing it will reduce problems in the future), but it is not urgent= =20 (i.e., calling for immediate attention). I hope my message did not imply an= =20 urgency that was not intended. =2D-=20 =2D-Andre Masella (apmasell@engmail, www.eng/~apmasell, 0x10ECBAE0) Every program expands until it can send mail...except Exchange.=20 --nextPart1167787.cyBqjolT1X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBD5NnxTGn8QhDsuuARAhHJAKCEHgMGJ8NcU9fd0l/heYVvDtqoRgCffQZv vW2i2eKwko9YuR7s44txYto= =cDfN -----END PGP SIGNATURE----- --nextPart1167787.cyBqjolT1X-- From ssingh@swen.uwaterloo.ca Sat Feb 4 14:11:04 2006 Return-Path: Received: from swen.uwaterloo.ca (swen.uwaterloo.ca [129.97.92.100]) by engmail.uwaterloo.ca (8.13.1/8.13.1) with ESMTP id k14JBAIg079268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sat, 4 Feb 2006 14:11:10 -0500 (EST) (envelope-from ssingh@swen.uwaterloo.ca) Received: from localhost (localhost [127.0.0.1]) by swen.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id k14JB4h00491 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sat, 4 Feb 2006 14:11:04 -0500 (EST) Date: Sat, 4 Feb 2006 14:11:04 -0500 (EST) From: Sanjay Singh To: Andre Masella cc: wmott@uwaterloo.ca Subject: Re: discussion ... Re: Problems Noted on HarshRealm In-Reply-To: <200602041144.33886.apmasell@engmail.uwaterloo.ca> Message-ID: References: <200602012042.42503.apmasell@engmail.uwaterloo.ca> <200602041144.33886.apmasell@engmail.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (swen.uwaterloo.ca [127.0.0.1]); Sat, 04 Feb 2006 14:11:05 -0500 (EST) X-Miltered: at rhadamanthus with ID 43E4FC48.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV 0.86.2/1276/Sat Feb 4 10:29:35 2006 on engmail.uwaterloo.ca X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on engmail.uwaterloo.ca X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.3 X-Length: 2950 X-UID: 187 Status: RO X-Status: RC X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: Andre, thanks for your reply. You are doing this for 4th year work, and thats sufficient cause for me to optimize things. Now that I know the actual context of your request, I can see you are not fooling around with trivialities. I will probably have more discussion with you as I dig into this. Sometime this weekend I will start looking around in depth. === The time discrepency is definitely relevant to your ability to do your work. And the compiler stuff too, though I have not tuned things to this extent before. You do know your way around Unix. Quite often I get waylaid by recent Linux converts who whine about having /bin/bash for the simple reason that they can use the cursor keys for their command line history; no other reason than that. All of the other advantages of Solaris, like its stability and multiprocessor support are lost on them. Normally on Solaris with gcc, I just compile and it goes, but I have set my LD_LIBRARY_PATH to search through several default library locations and the like. I will get back to you as this evolves. More details to come. S.