From msokolov Tue May 2 19:38:25 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA08703; Tue, 2 May 00 19:38:22 CDT Date: Tue, 2 May 00 19:38:22 CDT From: msokolov (Michael Sokolov) Message-Id: <0005030038.AA08703@ivan.Harhan.ORG> To: pilot-unix@hcirisc.cs.binghamton.edu Subject: New mailing list for prc-tools-0.6.0 Cc: ese-palmos-tools UNIX-based PalmOS developers, I have just set up a mailing list for all discussions, including use, development, and promotion, of the PalmOS development tools developed, maintained, and/or distributed by the IFCTF Embedded Systems Engineering (ESE) group. Currently it's prc-tools-0.6.0, but as I've already explained before, this will be changing. The list posting address is: ese-palmos-tools@ivan.Harhan.ORG to subscribe, send a message to: ese-palmos-tools-request@ivan.Harhan.ORG I have set up the list initially with several members who in the past have expressed an interest in prc-tools-0.6.0. I'm Cc'ing this to the new list, so if you are on it, you'll know it. Everyone who uses or supports prc-tools-0.6.0 is urged to subscribe! As Palm is promoting its own version so as to make us extinct, we need your support more than ever before! Subscribe to this list and show the world that we are not and will not be extinct! -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Sat May 6 17:14:44 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA16384; Sat, 6 May 00 17:14:06 CDT Date: Sat, 6 May 00 17:14:06 CDT From: msokolov (Michael Sokolov) Message-Id: <0005062214.AA16384@ivan.Harhan.ORG> To: ese-palmos-tools Subject: ESE PalmOS tools plans Welcome to the ESE PalmOS tools mailing list! ESE is the Embedded Systems Engineering group at the IFCTF (International Free Computing Task Force), the group that does some major work with the GNU toolchain targeting embedded systems, working closely with its maintainers at Cygnus Sourceware. How does this matter for PalmOS tools development will become clear shortly. PalmOS tools-wise, our current software product is prc-tools-0.6.0. Up until now prc-tools have been living up to their cause very well, and with the help of all of you loyal supporters on this list (thank you all!), we have shown the world, or at least those who were willing to listen, that our cause is not dead and we won't let it die. However, I believe that we should do some restructuring of our software, which I believe will not deviate from our cause but will only bring us more in line with it. Here are the issues with the current prc-tools. The main one, or one of the main ones, can be summarized in what Mark W. Eichin wrote on the pilot-unix mailing list: : I've always seen : it as a bug that the palm-targetted toolchain is anything more than : that, a target. Having it mainline would make the maintenance quality : *potentially* higher [not to knock anyone's current work, but forks : are always, inherently, behind the mainline] and simplify my *real* : goal of ending up with an Ada95 (GNAT) cross toolchain. I agree with this of course, in general. The way prc-tools have been so far (containing everything, including a special hacked version of the GNU toolchain, in a single package) effectively forces us, PalmOS developers, to deal with issues that we really shouldn't be burdened with. For example, prc- tools-0.5.0 contained patches to the GNU toolchain not only for targeting PalmOS, but also fixing some problems building under Cygwin. I did not include the latter in prc-tools-0.6.0. This was NOT, however, meant as an offense or disrespect to Cygwin users. It's just that making the GNU toolchain build on any host platform, whatever it is, is none of my business. That must be left to its maintainers. Similarly, John Marshall's toolchain patches include, in addition to PalmOS and Cygwin ones, patches to build HTML docs. I did not include the latter in prc-tools-0.6.0 either. Again, this has nothing to do with me objecting to HTML docs per se, it's just that this is not my call to make. These decisions belong to the GNU toolchain maintainers and no one else. This is an issue of not only distribution, but also support. I don't want to answer questions like "why don't you support platform X?" or "when building the GNU toolchain targeting PalmOS under host platform X I get this error, what do I do?", regardless of what platform X is. Such questions belong on the GNU toolchain mailing lists. People asking these questions there will actually find people interested in supporting host platform X and helping them with their problems, whereas people asking these questions to me won't. And not only host platforms, but high-level language front-ends as well. John Marshall developed C++ support for PalmOS gcc. That is praiseworthy and that work is obviously useful to a lot of people, but I couldn't include it in my prc-tools-0.6.0 distribution as I don't know C++ and am not qualified to handle any issues related to it. I as a low-level developer supporting the back-end for a particular target cannot be expected to support every high-level language front-end someone may develop and have a use for. It isn't just C++. What about FORTRAN, Objc, Chill, Ada, Java, etc? The proper solution to all these problems is to put ourselves in a position where we won't have to address them. Make PalmOS support a regular target in the mainstream GNU toolchain, just like any other target, and have everyone just use the mainstream GNU toolchain. Then our job will simply be to maintain this target. We won't be responsible for anything else and thus no one will be able to blame us for not doing anything else. *ALL* questions about the GNU toolchain should go to the appropriate mailing lists, period, no matter what host, target, or language. There on those lists the right people can answer questions about their aspects of the toolchain. We would be the ones for the PalmOS target. This requires stopping making patches against old releases of the toolchain and instead getting everything necessary into the current CVS. This is where the IFCTF ESE group comes into the pictures. Working on the mainstream toolchain requires a lot of skill and responsibility. Above all, someone working on the toolchain must have be conscious about the toolchain overall and not just his/her specific platform. Some of the issues addressed by the PalmOS patches to old toolchain releases are specific to PalmOS, others are not PalmOS- specific but are m68k-specific, and still others are general. Separating these and addressing each properly requires someone who is committed to improving the GNU toolchain in general, rather than someone who just gets his closed-minded patch checked in and disappears. This is what the IFCTF ESE group is for. Having someone who is a regular GNU toolchain developer and at the same time works on PalmOS gcc is going to be a real win for the PalmOS gcc community. Then after everything we need in the GNU toolchain is there, we still need some other pieces. We will need what I call the PalmOS gcc Support Environment (PGSE), which is already in the current prc-tools and consists of these components: obj-res post-linker, crt code, support components for GLibs and multiple code segments, standard libc and libmf libraries, and the palmos_link.ld link script (currently buried in the gcc patches, which is the wrong place for it). These will components will form the PGSE package. It will essentially play the same role for the GNU toolchain targeting PalmOS as do the native system libraries and kernel services on traditional UNIX targets. Therefore, I don't think that the existence of and need for this add-on package to the GNU toolchain targeting PalmOS goes against PalmOS being just another target, and it should actually make it more like the traditional UNIX targets. By configuring, building, and installing the standard GNU toolchain for the PalmOS target (GNU target name is TBD), and then downloading, building, and installing PGSE, one would get what I loosely call the PalmOS gcc programming environment, or simply PalmOS gcc. There is more in the current prc-tools than what belongs in PalmOS gcc. There are build-prc and PilRC that are not specific to PalmOS gcc or to the GNU toolchain. They are really standalone resource / resource database / PRC manipulation tools that should be just that, standalone. I also want more tools of this type. I want to replace build-prc with djw's par, which can build PRCs just as good as build-prc, but also does much more, including ripping PRCs back into their constituent resources. I also want to add a PilRC decompiler and tools to convert from and to Mac resource formats. These should be in a standalone package. The name prc-tools may actually be appropriate for this package or it may not be, this is something to discuss. The above summarizes my plans for restructuring our software. I'm posting them here on the list best suited for such discussions to give everyone with interest in the current prc-tools a chance to know about these plans and to discuss any issues or concerns. I don't want to do anything that people would have a problem with, and when I see a need for reorganization, I want to discuss it with everyone interested. Besides being beneficial for us, this reorganization would be a step toward reconciling our conflict of interest with the competing prc-tools project, provided that the other side cooperates. This reorganization provides a clear division of responsibility. IFCTF ESE will be responsible for and in charge of the PalmOS target in the GNU toolchain, PGSE, and possibly the resource and PRC manipulation package (I'm the only one so far arguing that this package is necessary, so I don't think anyone else would be interested in maintaining it). The GNU maintainers are and have always been responsible for their toolchain overall and its issues like buildability on different host platforms. This organization will allow John Marshall and others from the competing project, if they cooperate, to have all the features they want without keeping their own competing project. Currently AFAIK there are only two features in their prc-tools that aren't in ours: C++ support and binary distributions. When we get the PalmOS target into the standard toolchain, C++ support as well as support for all other languages should happen automatically, as the standard toolchain supports them of course. And if this support doesn't work automagically and has to be fixed explicitly, John or whoever can take the time to put the fix in the acceptable form and get it checked into the toolchain or the C++ support libraries. As for binary distributions, c'mon, you can compile a binary for any platform for anything. People who want to provide binaries for some platforms can build them from the official component sources from GNU and from us. The same goes for support. We do our job and maintain and support PGSE. The GNU maintainers, who are very numerous and will include us among their ranks when the PalmOS target is in the standard toolchain, do their job and maintain and support the toolchain. No one is forced to take responsibility for all. If someone wants to do that like John Marshall does, he can do it on his own as he sees fit. All he has to do is to clearly indicate that he is just providing volunteer support and that someone who wants to get the official source and talk to the official maintainers should go to: http://sourceware.cygnus.com/binutils/ for binutils, http://gcc.gnu.org/ for gcc, and ftp://ivan.Harhan.ORG/pub/embedded/palmos/ for PGSE. The likely area of conflict will be PGSE and the PalmOS target in the GNU toolchain. I insist on being in charge of these, and John and his team would likely object to this. Let me address these two (toolchain and PGSE) separately. As far as the toolchain goes, John has said that he plans to switch to the standard PalmOS toolchain some day and get the PalmOS support in there. The rub is, while he is planning to do it some day, I'm already working on it right now, and when he starts, I will be done. Working on the GNU toolchain, doing it in the officially right way, structuring the additions and enhancements in an acceptable way, and getting them accepted takes responsibility and skill. The IFCTF ESE group has been doing this for a long time, and I myself have recently started doing this, i.e., right now I'm already doing work on the GNU toolchain (not PalmOS-specific!) and getting my patches checked in. Some of my patches are already on the release branch for the upcoming binutils-2.10 release and you'll see me in the released ChangeLogs in a couple of weeks. I have been preparing myself for this for the past several months. Somehow I just can't imagine John coming out of the blue and doing this. I really don't see how he would be able to compete with me in the official GNU toolchain. As for PGSE (once again, this is obj-res, crt, support for GLibs and multiple code segments, and the link script), there are currently two versions of it, one in my prc-tools-0.6.0 and one in John's prc-tools-2.0. The two practically don't share a single line of code. The only common code is the little bit in obj-res I borrowed from John for data resource compression, but that's peripheral to the core of PGSE. In each version of PGSE the core design and code are completely by that version's author. One version will have to stay and the other will have to go, no way around it. As far as I know, my version of PGSE completely supercedes John's, i.e., I don't know of anything that works in John's version that doesn't work in mine. The other way around is obviously not the case, with John's version lacking GLibs of any kind, A4-based data access, and many smaller things. (OK, when C++ support is added to the PalmOS target in the mainstream GNU toolchain, there may be some hooks needed for it in the crt code and the link script, but those would be trivial 5-minute tweaks.) So what this all means is that John and others in the competing project can bring much more benefit to the PalmOS community that they do now by closing their competing project and instead working with us as outlined above, and our model will allow them to develop C++ support or whatever else they want. I'm not asking that they close their project immediately, as it will take us some time to implement all the above and obviously John and others can't start on making the PalmOS target back-end work with the C++ front-end until I add the PalmOS target in the first place, but if they agree to do this in the future when everything is ready, at least change their WWW pages to clearly list the two projects as they are now and indicate that in the future they agree to close their project, agree to ours, and merge their features into it. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Tue May 16 14:52:02 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA05026; Tue, 16 May 00 14:50:54 CDT Received: by aero.org id <17132-3>; Tue, 16 May 2000 12:50:38 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa16936; Tue May 16 12:50:13 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id MAA01067 for ; Tue, 16 May 2000 12:50:12 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id MAA29554; Tue, 16 May 2000 12:50:12 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ese-palmos-tools@ivan.Harhan.ORG Subject: latest prc-tools-0.6 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14625.42377.669937.6395@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Tue, 16 May 2000 12:50:19 -0700 Where can I find the latest prc-tools-0.6? The site ftp://ivan.Harhan.ORG/pub/embedded/palmos/ doesn't respond. From setuid@linuxcare.com Tue May 16 19:33:34 2000 Received: from [216.88.157.131] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA05409; Tue, 16 May 00 19:33:30 CDT Received: (qmail 24476 invoked from network); 17 May 2000 00:31:59 -0000 Received: from view.linuxcare.com (HELO lnxc-181.i.linuxcare.com) (216.88.157.130) by smtp.linuxcare.com with SMTP; 17 May 2000 00:31:59 -0000 Date: Tue, 16 May 2000 17:32:27 -0700 (PDT) From: "David A. Desrosiers" X-Sender: hacker@broccoli.linuxcare.com To: Jeffery.D.Collins@aero.org Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: latest prc-tools-0.6 In-Reply-To: <14625.42377.669937.6395@malibu.aero.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Where can I find the latest prc-tools-0.6? The site > ftp://ivan.Harhan.ORG/pub/embedded/palmos/ doesn't respond. You can find it at ftp.jpsystems.com. Good luck! From msokolov Tue May 16 20:55:28 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA05526; Tue, 16 May 00 20:55:24 CDT Date: Tue, 16 May 00 20:55:24 CDT From: msokolov (Michael Sokolov) Message-Id: <0005170155.AA05526@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: latest prc-tools-0.6 Jeff Collins wrote: > Where can I find the latest prc-tools-0.6? Note that the latest is still the beta from January. I am working on the prc- tools-0.6.0 full release, and I promise I'll have it real real soon. > The site ftp://ivan.Harhan.ORG/pub/embedded/palmos/ doesn't > respond. It sure does, I have been logged in all day. :-) However, there appears to be some bug in the FTP server that prevents passive mode from working. Just don't use passive mode. I plan to fix that one too when I get to it. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Tue May 16 21:22:59 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA05657; Tue, 16 May 00 21:22:57 CDT Date: Tue, 16 May 00 21:22:57 CDT From: msokolov (Michael Sokolov) Message-Id: <0005170222.AA05657@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: latest prc-tools-0.6 David A. Desrosiers wrote: > > Where can I find the latest prc-tools-0.6? The site > > ftp://ivan.Harhan.ORG/pub/embedded/palmos/ doesn't respond. > > You can find it at ftp.jpsystems.com. Good luck! That's my civilian employer's site. Unfortunately they have sided with Palm, Com. Marshall, and their hobbled version, and don't cooperate with my prc-tools project. Therefore, I don't really want to use their site for distribution. ivan.Harhan.ORG is the official distribution site. (I promise, I *will* fix the passive mode problem!) -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Thu May 18 13:05:27 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02437; Thu, 18 May 00 13:05:14 CDT Date: Thu, 18 May 00 13:05:14 CDT From: msokolov (Michael Sokolov) Message-Id: <0005181805.AA02437@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Fw: Install Issues for PRC Tools 0.6.0 I'm posting the following private E-mail from John Peterson to the list, taking his saying that he wanted to post it but didn't know the posting address as implied permission. I'll respond to it momentarily. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) Forwarded message follows: >From john_peterson@usa.net Thu May 18 10:31:47 2000 Received: from nwcst278.netaddress.usa.net by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02056; Thu, 18 May 00 10:31:45 CDT Received: (qmail 20066 invoked by uid 60001); 18 May 2000 15:31:40 -0000 Message-Id: <20000518153140.20065.qmail@nwcst278.netaddress.usa.net> Received: from 204.68.23.23 by nwcst278 for [128.194.119.90] via web-mailer(34FM1.4.02C) on Thu May 18 15:31:39 GMT 2000 Date: 18 May 00 10:31:39 CDT From: John Peterson To: Michael Sokolov Subject: Install Issues for PRC Tools 0.6.0 X-Mailer: USANET web-mailer (34FM1.4.02C) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Status: RO Michael, I think this e-mail would have been a good candidate for posting on the listserv, but I was unsure of where to send the e-mail to. So in the mea= ntime I'm sending it directly to you. Anyway, I am trying to build the PRC too= ls that I downloaded from ivan.harhan.org on a Win98 box. I have downloaded= and installed the cygnus stuff (they have a really slick setup.exe file in th= eir latest folder on their FTP site) = The problem is that I am missing a few C header files. More specifically= fcntl.h, stdlib.h, and netinet/in.h (so far). I have versions of these f= iles that came with Visual Studio and Borland's C Compiler, but I think it wou= ld be unwise to use them because I have no idea if they are up to date or not. = So if you could point me to where to get the new header files I would be muc= h obliged (sounds Texan eh?). Also, I changed line 89 in the Makefile you provided to correctly point t= o the stdio.h provided with your tools... It is... OLD: $(CC) $(CFLAGS) -I$(PREFIX)/include -c obj-res.c NEW: $(CC) $(CFLAGS) -I$(PREFIX)/$(LIBCDIR)/include -c obj-res.c Just so you know my experience level. I am comfortable with Linux, but I= have never setup a cross-compiler so I think I'll be a good test subject for t= his stuff. I'll be sure and tell you of any difficulties I have and any chan= ges I make so that others can benefit from my experience. Thanks for all your help. -John Peterson "Life's a journey, enjoy the ride" http://real.dyndns.org ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From msokolov Thu May 18 13:20:23 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02497; Thu, 18 May 00 13:20:20 CDT Date: Thu, 18 May 00 13:20:20 CDT From: msokolov (Michael Sokolov) Message-Id: <0005181820.AA02497@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Install Issues for PRC Tools 0.6.0 John Peterson wrote: > I think this e-mail would have been a good candidate for posting on the > listserv, but I was unsure of where to send the e-mail to. The list posting address is: ese-palmos-tools@ivan.Harhan.ORG > Anyway, I am trying to build the PRC too= > ls > that I downloaded from ivan.harhan.org on a Win98 box. I have downloaded= > and > installed the cygnus stuff (they have a really slick setup.exe file in th= > eir > latest folder on their FTP site) = Hari on this list has successfully done this, so I know it's possible. > The problem is that I am missing a few C header files. More specifically= > > fcntl.h, stdlib.h, and netinet/in.h (so far). > > [stdio.h mentioned later too] Then your Cygwin installation is broken! stdlib.h and stdio.h are mandatory for any ISO C compiler, which gcc/Cygwin certainly is, fcntl.h is such a basic UNIX header file that Cygwin certainly has it, and it probably has netinet/in.h too. So I'm sure Cygwin has all these header files. Hari, you didn't have any problems with header files building prc-tools for Cygwin, did you? > Also, I changed line 89 in the Makefile you provided to correctly point t= > o the > stdio.h provided with your tools... It is... > > OLD: $(CC) $(CFLAGS) -I$(PREFIX)/include -c obj-res.c > NEW: $(CC) $(CFLAGS) -I$(PREFIX)/$(LIBCDIR)/include -c obj-res.c Don't ever do this! The header files in libc.0.1.2/include in prc-tools are for the *target*, not the host! > I am comfortable with Linux [...] Do you have it? If you do, why are you bothering with Cygwin? Why do you need a UNIX-under-Weendoze emulator when you have real UNIX? Why do you need prostetics when you have both of your legs? All tools in question are for UNIX. That is their native environment. Cygwin is a source-level UNIX emulator that runs under Weendoze. I understand that an emulator may be necessary if you just don't have a UNIX account, but if you do have real UNIX, why do you need the emulator? No emulator can ever be as good as the real thing. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From hari@kerala.jpsystems.com Thu May 18 13:28:49 2000 Received: from [209.184.70.147] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02549; Thu, 18 May 00 13:28:45 CDT Received: (from hari@localhost) by kerala.jpsystems.com (8.9.3/8.9.3) id MAA08964; Thu, 18 May 2000 12:30:58 -0500 Date: Thu, 18 May 2000 12:30:58 -0500 From: Hari Bhaskaran To: john_peterson@usa.net Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Fw: Install Issues for PRC Tools 0.6.0 Message-Id: <20000518123058.A8929@kerala.jpsystems.com> References: <0005181805.AA02437@ivan.Harhan.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <0005181805.AA02437@ivan.Harhan.ORG>; from msokolov@ivan.Harhan.ORG on Thu, May 18, 2000 at 01:05:14PM -0500 I built prc-tools on my win 98 machine once. I didn't have much problems. I had written a readme file, but I can't get to it now. I don't use cgywin/prc-tools regularly, but I just tried to build it once. Couple of things:- 1. Download the full version of Cygwin ( I don't know if they have any such distinction anymore.) 2. You must download source of gcc, binutils & gdb (if needed) from gnu.org. They *must* be the same version mentioned in the docs. 3. Once you patch your files, the patch program somehow converts all include files to DOS style - CRLF format. You may have to convert them back to Unix style - use dos2unix or an editor like vim (vim.org) (Or do the patch first on a unix machine and then bring it over to win) 4. If you are installing prc-tools in /usr/local/palm (or C:\cygwin\...\usr\local\palm), put that in the path before you start your build. This way you can make sure m68k-binutils is available in path before you build gcc. 5.Executable built will have a .exe extension, so the Makefile's should change appropriately. -- Hari On Thu, May 18, 2000 at 01:05:14PM -0500, Michael Sokolov wrote: > I'm posting the following private E-mail from John Peterson to the list, taking > his saying that he wanted to post it but didn't know the posting address as > implied permission. > > I'll respond to it momentarily. > > -- > Michael Sokolov Harhan Engineering Laboratory > Public Service Agent International Free Computing Task Force > International Engineering and Science Task Force > 615 N GOOD LATIMER EXPY STE #4 > DALLAS TX 75204-5852 USA > > Phone: +1-214-824-7693 (Harhan Eng Lab office) > E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) > > Forwarded message follows: > > >From john_peterson@usa.net Thu May 18 10:31:47 2000 > Received: from nwcst278.netaddress.usa.net by ivan.Harhan.ORG (5.61.1.1/1.36) > id AA02056; Thu, 18 May 00 10:31:45 CDT > Received: (qmail 20066 invoked by uid 60001); 18 May 2000 15:31:40 -0000 > Message-Id: <20000518153140.20065.qmail@nwcst278.netaddress.usa.net> > Received: from 204.68.23.23 by nwcst278 for [128.194.119.90] via web-mailer(34FM1.4.02C) on Thu May 18 15:31:39 GMT 2000 > Date: 18 May 00 10:31:39 CDT > From: John Peterson > To: Michael Sokolov > Subject: Install Issues for PRC Tools 0.6.0 > X-Mailer: USANET web-mailer (34FM1.4.02C) > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > Status: RO > > Michael, > > I think this e-mail would have been a good candidate for posting on the > listserv, but I was unsure of where to send the e-mail to. So in the mea= > ntime > I'm sending it directly to you. Anyway, I am trying to build the PRC too= > ls > that I downloaded from ivan.harhan.org on a Win98 box. I have downloaded= > and > installed the cygnus stuff (they have a really slick setup.exe file in th= > eir > latest folder on their FTP site) = > > The problem is that I am missing a few C header files. More specifically= > > fcntl.h, stdlib.h, and netinet/in.h (so far). I have versions of these f= > iles > that came with Visual Studio and Borland's C Compiler, but I think it wou= > ld be > unwise to use them because I have no idea if they are up to date or not. = > So > if you could point me to where to get the new header files I would be muc= > h > obliged (sounds Texan eh?). > > Also, I changed line 89 in the Makefile you provided to correctly point t= > o the > stdio.h provided with your tools... It is... > > OLD: $(CC) $(CFLAGS) -I$(PREFIX)/include -c obj-res.c > NEW: $(CC) $(CFLAGS) -I$(PREFIX)/$(LIBCDIR)/include -c obj-res.c > > Just so you know my experience level. I am comfortable with Linux, but I= > have > never setup a cross-compiler so I think I'll be a good test subject for t= > his > stuff. I'll be sure and tell you of any difficulties I have and any chan= > ges I > make so that others can benefit from my experience. Thanks for all your > help. > > -John Peterson > > > "Life's a journey, enjoy the ride" > http://real.dyndns.org > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=3D= > 1 -- Hari Bhaskaran 972-277-8334 Main: 972-484-5432 888-937-3607 ------------------ From hari@kerala.jpsystems.com Thu May 18 13:41:50 2000 Received: from [209.184.70.147] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02609; Thu, 18 May 00 13:41:47 CDT Received: (from hari@localhost) by kerala.jpsystems.com (8.9.3/8.9.3) id MAA08990; Thu, 18 May 2000 12:43:49 -0500 Date: Thu, 18 May 2000 12:43:49 -0500 From: Hari Bhaskaran To: john_peterson@usa.net Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Install Issues for PRC Tools 0.6.0 Message-Id: <20000518124349.A8967@kerala.jpsystems.com> References: <0005181820.AA02497@ivan.Harhan.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <0005181820.AA02497@ivan.Harhan.ORG>; from msokolov@ivan.Harhan.ORG on Thu, May 18, 2000 at 01:20:20PM -0500 > > Don't ever do this! The header files in libc.0.1.2/include in prc-tools are for > the *target*, not the host! > > > I am comfortable with Linux [...] I guess the problem is that installation process is not explained in detail. 1. cygwin comes with gcc - but you can't use *that* gcc to build PalmOS programs. You have to download gcc-2.95.2, binutils-2.9.1 etc (as you see in prc-tools-0.6.0/Makefile) from ftp.gnu.org/pub/gnu. 2. As the next step, you unzip, untar and *patch* the soure of these tools to generate a binutils for m68k-palmos-coff hosted on Windows. Notice only the patch files are given with prc-tools. The source for gcc, binutils themselves have to be downloaded from gnu.org 3. Install binutils, make sure it is in the path and then install gcc. (same step: Unzip, untar, patch, make, make install) 4. Select a prefix like /usr/local/prctools or /usr/local/palm so that it doesn't mix with native-gcc (pass this argument to ./configure) -- Hari From msokolov Thu May 18 13:57:21 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02660; Thu, 18 May 00 13:57:14 CDT Date: Thu, 18 May 00 13:57:14 CDT From: msokolov (Michael Sokolov) Message-Id: <0005181857.AA02660@ivan.Harhan.ORG> To: ese-palmos-tools Subject: RE: Visor GCC Trouble Cc: BPetersen@Handspring.com Bob Petersen wrote on a Palm-hosted mailing list that I can't post to: > ps: For your second question on the forum, either Win98 with the Handspring > tools or Linux with the prc-tools 2.0 package from Palm are viable options. > With the prc-tools package, you won't be able to use the Handspring-specific > APIs out of the box. With Palm's hoarded prc-tools, that is. With the real prc-tools, current version 0.6.0, HS calls work out of the box. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Thu May 18 14:02:09 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02678; Thu, 18 May 00 14:02:04 CDT Received: by aero.org id <17511-5>; Thu, 18 May 2000 12:01:49 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa25268; Thu May 18 11:43:07 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id LAA23955 for ; Thu, 18 May 2000 11:43:02 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id LAA05666; Thu, 18 May 2000 11:43:02 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ese-palmos-tools@ivan.Harhan.ORG Subject: Illegal Instruction X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14628.13110.573596.683565@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Thu, 18 May 2000 11:43:30 -0700 I am porting an interpreter to the Palm using prc-tools-0.6beta. The interpreter is stored in a shared multi-segmented (13 of them) GLib. Applications can call into the library in the usual way, taking care to properly open the library and to maintain a4. To get the Glib to work properly, the makefile was modified as follows: grc.stamp: $(OURLIB) $(OBJRES) -c code 2 -d data 0 -D 1 $(OURLIB) $(SEGMENT_LIST) $(OBJRES) -l -D 1 $(OURLIB) $(SEGMENT_LIST) mv GLib0000.$(OURLIB).grc tmp \rm GLib000*grc mv tmp GLib0000.$(OURLIB).grc touch grc.stamp This was necessary to create one GLib0000.x.grc and one data resource and multiple code resources. I now have a set of resources for the library "lib" that look like: -rw-r--r-- 1 collins rassd 20748 May 16 16:32 GLib0000.lib.grc -rw-r--r-- 1 collins rassd 6538 May 16 16:32 code0002.lib.grc -rw-r--r-- 1 collins rassd 13122 May 16 16:32 code0003.lib.grc -rw-r--r-- 1 collins rassd 22294 May 16 16:32 code0004.lib.grc -rw-r--r-- 1 collins rassd 20226 May 16 16:32 code0005.lib.grc -rw-r--r-- 1 collins rassd 20290 May 16 16:32 code0006.lib.grc -rw-r--r-- 1 collins rassd 21826 May 16 16:32 code0007.lib.grc -rw-r--r-- 1 collins rassd 32242 May 16 16:32 code0008.lib.grc -rw-r--r-- 1 collins rassd 23090 May 16 16:32 code0009.lib.grc -rw-r--r-- 1 collins rassd 24950 May 16 16:32 code000a.lib.grc -rw-r--r-- 1 collins rassd 4218 May 16 16:32 code000b.lib.grc -rw-r--r-- 1 collins rassd 17510 May 16 16:32 data0000.lib.grc >From a test application on the Palm, I'm able to call into an initialization routine in the library. The call starts out well, printing expected check values to the screen, but when a certain (consistent) point in the code is reached, an "Illegal Instruction" error occurs. What can cause such an error? Is memory getting corrupted in some way? Any hints on this would be appreciated. Thanks, Jeff From msokolov Thu May 18 14:20:01 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA02720; Thu, 18 May 00 14:19:56 CDT Date: Thu, 18 May 00 14:19:56 CDT From: msokolov (Michael Sokolov) Message-Id: <0005181919.AA02720@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Illegal Instruction Jeff Collins wrote: > -rw-r--r-- 1 collins rassd 20748 May 16 16:32 GLib0000.lib.grc > -rw-r--r-- 1 collins rassd 6538 May 16 16:32 code0002.lib.grc > -rw-r--r-- 1 collins rassd 13122 May 16 16:32 code0003.lib.grc > -rw-r--r-- 1 collins rassd 22294 May 16 16:32 code0004.lib.grc > -rw-r--r-- 1 collins rassd 20226 May 16 16:32 code0005.lib.grc > -rw-r--r-- 1 collins rassd 20290 May 16 16:32 code0006.lib.grc > -rw-r--r-- 1 collins rassd 21826 May 16 16:32 code0007.lib.grc > -rw-r--r-- 1 collins rassd 32242 May 16 16:32 code0008.lib.grc > -rw-r--r-- 1 collins rassd 23090 May 16 16:32 code0009.lib.grc > -rw-r--r-- 1 collins rassd 24950 May 16 16:32 code000a.lib.grc > -rw-r--r-- 1 collins rassd 4218 May 16 16:32 code000b.lib.grc > -rw-r--r-- 1 collins rassd 17510 May 16 16:32 data0000.lib.grc > > [preceded by a Makefile kludge to make the resources look like this] This is not how it should be. All code resources in a GLib should be GLibXXXX, i.e., GLib0000, GLib0002, GLib0003, etc. I think this is stated clearly in the manual. This resource layout results automatically from simply running: m68k-palmos-coff-obj-res -l mylib
What is not documented anywhere except the source, however, is that for a multisegment GLib multisegstubgen must be run with -l as well. This will cause the multiple code segment loader to look for the extra code segments in GLib N resources instead of code N. This is not documented anywhere right now because my intent is for this to be in the multisegstubgen(1) man page, which hasn't been written yet. BTW, reducing data resource compression with -D 1 is not necessary. In /pub/embedded/palmos/prc-tools.0.6.0beta-fixes on ivan.Harhan.ORG you'll find a fixed version of manufdata.c for the libcrt.a library that no longer has the bug crashing on some data resource compression patterns, and you can safely use the maximum data resource compression (-D 5, which is the default). > From a test application on the Palm, I'm able to call into an > initialization routine in the library. The call starts out well, > printing expected check values to the screen, but when a certain > (consistent) point in the code is reached, an "Illegal Instruction" > error occurs. > > What can cause such an error? Is memory getting corrupted in some > way? You're going to have to tell us more. Post the code fragment causing the error. Also if you can, single-step through the code in gdb and point to the exact instruction catching the trap. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Thu May 18 17:07:20 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA03344; Thu, 18 May 00 17:07:04 CDT Received: by aero.org id <17092-4>; Thu, 18 May 2000 15:06:49 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa15004; Thu May 18 15:06:41 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id PAA26289; Thu, 18 May 2000 15:06:40 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id PAA06140; Thu, 18 May 2000 15:06:40 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Illegal Instruction In-Reply-To: <0005181919.AA02720@ivan.Harhan.ORG> References: <0005181919.AA02720@ivan.Harhan.ORG> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14628.26009.220609.284837@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Thu, 18 May 2000 15:06:48 -0700 Michael Sokolov writes: > Jeff Collins wrote: > > > -rw-r--r-- 1 collins rassd 20748 May 16 16:32 GLib0000.lib.grc > > -rw-r--r-- 1 collins rassd 6538 May 16 16:32 code0002.lib.grc > > -rw-r--r-- 1 collins rassd 13122 May 16 16:32 code0003.lib.grc > > -rw-r--r-- 1 collins rassd 22294 May 16 16:32 code0004.lib.grc > > -rw-r--r-- 1 collins rassd 20226 May 16 16:32 code0005.lib.grc > > -rw-r--r-- 1 collins rassd 20290 May 16 16:32 code0006.lib.grc > > -rw-r--r-- 1 collins rassd 21826 May 16 16:32 code0007.lib.grc > > -rw-r--r-- 1 collins rassd 32242 May 16 16:32 code0008.lib.grc > > -rw-r--r-- 1 collins rassd 23090 May 16 16:32 code0009.lib.grc > > -rw-r--r-- 1 collins rassd 24950 May 16 16:32 code000a.lib.grc > > -rw-r--r-- 1 collins rassd 4218 May 16 16:32 code000b.lib.grc > > -rw-r--r-- 1 collins rassd 17510 May 16 16:32 data0000.lib.grc > > > > [preceded by a Makefile kludge to make the resources look like this] > > This is not how it should be. All code resources in a GLib should be GLibXXXX, > i.e., GLib0000, GLib0002, GLib0003, etc. I think this is stated clearly in the > manual. This resource layout results automatically from simply running: > > m68k-palmos-coff-obj-res -l mylib
> > What is not documented anywhere except the source, however, is that for a > multisegment GLib multisegstubgen must be run with -l as well. This will cause > the multiple code segment loader to look for the extra code segments in GLib N > resources instead of code N. This is not documented anywhere right now because > my intent is for this to be in the multisegstubgen(1) man page, which hasn't > been written yet. I did _not_ call multisegstubgen with a "-l". > > BTW, reducing data resource compression with -D 1 is not necessary. In > /pub/embedded/palmos/prc-tools.0.6.0beta-fixes on ivan.Harhan.ORG you'll find a > fixed version of manufdata.c for the libcrt.a library that no longer has the > bug crashing on some data resource compression patterns, and you can safely use > the maximum data resource compression (-D 5, which is the default). Thanks for the fix - I'll try it. > > > From a test application on the Palm, I'm able to call into an > > initialization routine in the library. The call starts out well, > > printing expected check values to the screen, but when a certain > > (consistent) point in the code is reached, an "Illegal Instruction" > > error occurs. > > > > What can cause such an error? Is memory getting corrupted in some > > way? > > You're going to have to tell us more. Post the code fragment causing the error. > Also if you can, single-step through the code in gdb and point to the exact > instruction catching the trap. Perhaps I should create one big multisegmented application and move the offending code into the main segment for debugging. Jeff From msokolov Thu May 18 19:02:13 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA03701; Thu, 18 May 00 19:02:07 CDT Date: Thu, 18 May 00 19:02:07 CDT From: msokolov (Michael Sokolov) Message-Id: <0005190002.AA03701@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Illegal Instruction Jeff Collins wrote: > I did _not_ call multisegstubgen with a "-l". You should. If you do, you would be able to run obj-res normally. > Perhaps I should create one big multisegmented application and move > the offending code into the main segment for debugging. It is true that gdb sees the symbolic information only for the first segment. However, the debugged program entity doesn't have to be an application. It can be any type of program entity, including a GLib. Put a _gdb_hook() (as described in Appendix D of the manual) at the point where you want it to trip into gdb (e.g., at the entry point which is crashing) and run m68k-palmos-coff- gdb with the GLib's intermediate file on the command line. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Fri May 19 15:37:36 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA05159; Fri, 19 May 00 15:36:37 CDT Received: by aero.org id <17122-1>; Fri, 19 May 2000 13:36:05 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa02486; Fri May 19 13:35:56 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id NAA05891; Fri, 19 May 2000 13:35:55 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id NAA08428; Fri, 19 May 2000 13:35:56 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Update (was Illegal Instruction) In-Reply-To: <0005190002.AA03701@ivan.Harhan.ORG> References: <0005190002.AA03701@ivan.Harhan.ORG> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14629.41892.336666.495582@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Fri, 19 May 2000 13:36:00 -0700 I had overlooked a function that had been declared in two places (one extern), each with a different segment label. After resolving the conflict, the errors disappeared! Thanks for the help, Jeff From msokolov Sat May 20 14:47:49 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA06406; Sat, 20 May 00 14:47:46 CDT Date: Sat, 20 May 00 14:47:46 CDT From: msokolov (Michael Sokolov) Message-Id: <0005201947.AA06406@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Update (was Illegal Instruction) Jeff Collins wrote: > I had overlooked a function that had been declared in two places (one > extern), each with a different segment label. After resolving the > conflict, the errors disappeared! That's one of the issues with the current implementation of multiple code segments via gcc call sequence hacks. Life will be much better with call and reference instruction sequence transformation in the relaxing linker. Note for people who have already developed significant projects using section attributes for code segment division. This way will still work with the new implementation. Section attributes by themselves aren't a hack, they exist and work fine in the standard gcc, it's their use for call sequences that's a hack. This hack will go away and section attributes will work like they do for all other targets. You'll be able to divide code into sections using section attributes (at source level / compile time), link scripts (at link time), or in any other way. The link relaxer will only look at the final section arrangement in the intermediate file (sec->output_section in BFD). -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Sun May 21 16:46:11 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA09255; Sun, 21 May 00 16:46:04 CDT Received: by aero.org id <17101-5>; Sun, 21 May 2000 14:45:59 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa26642; Sun May 21 14:31:04 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id OAA20700; Sun, 21 May 2000 14:31:03 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id OAA02410; Sun, 21 May 2000 14:31:04 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Update (was Illegal Instruction) In-Reply-To: <0005201947.AA06406@ivan.Harhan.ORG> References: <0005201947.AA06406@ivan.Harhan.ORG> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14632.21397.671015.105641@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Sun, 21 May 2000 14:34:20 -0700 Michael Sokolov writes: > Jeff Collins wrote: > > > I had overlooked a function that had been declared in two places (one > > extern), each with a different segment label. After resolving the > > conflict, the errors disappeared! > > That's one of the issues with the current implementation of multiple code > segments via gcc call sequence hacks. Life will be much better with call and > reference instruction sequence transformation in the relaxing linker. One more issue has arisen as I look through the code. There are several function pointer declarations, some of which have been marked with section attributes and some that have not (by my semi-automated sectioning scheme). Which is the correct way? If they must be marked, then what about binding to functions defined other sections? > > Note for people who have already developed significant projects using section > attributes for code segment division. This way will still work with the new > implementation. Section attributes by themselves aren't a hack, they exist and > work fine in the standard gcc, it's their use for call sequences that's a hack. > This hack will go away and section attributes will work like they do for all > other targets. You'll be able to divide code into sections using section > attributes (at source level / compile time), link scripts (at link time), or in > any other way. The link relaxer will only look at the final section arrangement > in the intermediate file (sec->output_section in BFD). I can't wait for this. Most of my problems so far have involved the misuse of the tools, though the tools themselves appear pretty solid. Jeff From msokolov Sun May 21 22:19:38 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA09670; Sun, 21 May 00 22:19:34 CDT Date: Sun, 21 May 00 22:19:34 CDT From: msokolov (Michael Sokolov) Message-Id: <0005220319.AA09670@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Update (was Illegal Instruction) Jeff Collins wrote: > One more issue has arisen as I look through the code. There are > several function pointer declarations, some of which have been marked > with section attributes and some that have not (by my semi-automated > sectioning scheme). Which is the correct way? If they must be > marked, then what about binding to functions defined other sections? No, don't ever put section attributes on function pointers, or for that matter, on any other pointers or any variables in general. Section attributes are *only* for declarations corresponding to function bodies. Section attributes are meaningful only for objects for which the compiler allocates or directly references space in the program image. This includes function bodies and global and static variables, as well as external references to them, but not function parameters or automatic variables. "In the program image" means in some section thereof. The section attribute specifies which. In the case of PalmOS, text objects (function bodies) go into different code sections/segments, making section attributes useful for them. However, data objects (variables of any kind, pointers are no different from any others) must always go into where the compiler puts them by default. Putting them anywhere else with a section attribute will cause a spectacular crash. Now if you are wondering if pointers need to be associated with sections in order to correctly point to whatever they are pointing to, no, they don't. Remember, this is 68000 we're talking about, not 80x86! The actual address space is perfectly flat, and once you have an address in your hand (i.e., a pointer), you can forget about segments and sections. It's just that locating an object by direct reference is made difficult by the PalmOS memory architecture. > I can't wait for this. I understand this, and I wasn't telling you to. I was just telling you and everyone that the current way will still work even when a better one becomes available, so your efforts aren't completely wasted. > Most of my problems so far have involved the > misuse of the tools, though the tools themselves appear pretty solid. The tools are solid, but the section attribute thingy does make them very easy to misuse indeed! Also the lack of man pages, and thus the documentation that I intended to go in them, makes it impossible to learn about certain features or how to do some things right without studying the source. I will have the man pages in the 0.6.0 full release. (Writing them is one of the things that's holding it back...) -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From john_peterson@usa.net Wed May 24 10:52:14 2000 Received: from [204.68.24.37] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA14752; Wed, 24 May 00 10:52:06 CDT Received: (qmail 14221 invoked by uid 60001); 24 May 2000 15:52:27 -0000 Message-Id: <20000524155227.14220.qmail@www0h.netaddress.usa.net> Received: from 204.68.24.37 by www0h for [128.194.119.90] via web-mailer(34FM1.4.02C) on Wed May 24 15:52:27 GMT 2000 Date: 24 May 00 10:52:27 CDT From: John Peterson To: Subject: OK to update PilRC? X-Mailer: USANET web-mailer (34FM1.4.02C) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable After installing prc-tools-0.6.0 beta I noticed that the PilRC tool is a = bit old. The version being used is 1.5 and the crurrent version on the PilRC= webpage is at 2.5 (http://www.hig.se/~ardiri/development/palmIII/pilrc/index.html). Do you guys think it would be ok to upgrade to a newer version? Would it= break anything? I really want to add a version newer than 1.9 so that I = can use AUTOID in my .rcp files. JOhn "Life's a journey, enjoy the ride" http://real.dyndns.org ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From john_peterson@usa.net Wed May 24 13:13:56 2000 Received: from nwcst267.netaddress.usa.net by ivan.Harhan.ORG (5.61.1.1/1.36) id AA14919; Wed, 24 May 00 13:13:53 CDT Received: (qmail 25913 invoked by uid 60001); 24 May 2000 18:14:10 -0000 Message-Id: <20000524181410.25912.qmail@nwcst267.netaddress.usa.net> Received: from 204.68.23.12 by nwcst267 for [128.194.119.90] via web-mailer(34FM1.4.02C) on Wed May 24 18:14:10 GMT 2000 Date: 24 May 00 13:14:10 CDT From: John Peterson To: Subject: PRC Tools Version #s X-Mailer: USANET web-mailer (34FM1.4.02C) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Why are their multiple versions of PRC Tools? I think Michael may have addressed this before, but how come there is a version 0.6.0 (which I am using) and a version 2.0 on Palm's page? JOhn "Life's a journey, enjoy the ride" http://real.dyndns.org ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From john_w_marshall@palm.com Wed May 24 17:34:58 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA15236; Wed, 24 May 00 17:34:54 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA18367; Wed, 24 May 2000 15:33:07 -0700 (PDT) Received: from kovalevskaya.palm.com (johnm@kovalevskaya.OPS.3Com.COM [139.87.32.94]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA15946; Wed, 24 May 2000 15:33:05 -0700 (PDT) Received: (from johnm@localhost) by kovalevskaya.palm.com (8.9.3/8.8.7) id PAA15589; Wed, 24 May 2000 15:31:54 -0700 From: John Marshall Message-Id: <200005242231.PAA15589@kovalevskaya.palm.com> Subject: Re: PRC Tools Version #s To: john_peterson@usa.net (John Peterson) Date: Wed, 24 May 2000 15:31:54 -0700 (PDT) Cc: ese-palmos-tools@ivan.Harhan.ORG In-Reply-To: <882568E9.007B50B5.00@hqpalmsmtp.palm.com> from "John Peterson" at May 24, 2000 11:14:05 AM X-Mailer: ELM [version 2.5 PL0pre8] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Peterson writes: > Why are their multiple versions of PRC Tools? Someone summarized the situation in this pilot-unix posting: http://hcirisc.cs.binghamton.edu/lists/pilot-unix/hypermail/1990.html John From msokolov Fri May 26 16:35:03 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA19141; Fri, 26 May 00 16:34:48 CDT Date: Fri, 26 May 00 16:34:48 CDT From: msokolov (Michael Sokolov) Message-Id: <0005262134.AA19141@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: PRC Tools Version #s John Peterson wrote: > Why are their multiple versions of PRC Tools? I think Michael may have > addressed this before, but how come there is a version 0.6.0 (which I am > using) and a version 2.0 on Palm's page? Because prc-tools have been hoarded by Palm. Palm decided to take over prc- tools and did so without asking us, the original prc-tools community, whether we want to be taken over. That's how they produced their "prc-tools-2.0". We, however, have no intention of accepting a taken-over position and will continue maintaining the real prc-tools. Our current version is 0.6.0. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Fri May 26 17:13:24 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA19184; Fri, 26 May 00 17:13:21 CDT Date: Fri, 26 May 00 17:13:21 CDT From: msokolov (Michael Sokolov) Message-Id: <0005262213.AA19184@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: PRC Tools Version #s John Marshall wrote: > Someone summarized the situation in this pilot-unix posting: > > http://hcirisc.cs.binghamton.edu/lists/pilot-unix/hypermail/1990.html Thank you for the very helpful pointer, John. The old-timers already know this, but for the newcomers, John Marshall has been Palm's chief accomplice in their hoarding of prc-tools, aiding them by providing them with a competing divergent and severely hobbled version of prc-tools and getting a job there maintaining it. Now just to reassure everyone that in the Palm-free original prc-tools community I'm the rightful maintainer, that Palm is nothing but a free software hoarder, and that John is only their accomplice, here is my prc-tools maintainership affidavit: >From 1997 till last fall prc-tools have been in cryostasis, and during that dark period the real prc-tools were essentially dead. Yes, I know that John Marshall's version has existed for quite a while during that dark period. John has definitely done a great deal of good work and his contribution should be acknowledged. However, (no personal offense intended, John, really) he has not done a satisfactory job at project management. First I would say that just the fact that John had no reservations about removing crucial features and user experience elements of prc-tools-0.5.0 and changed its mission and purpose as he felt like it disqualifies his version as the trunk successor to 0.5.0. But there is more of what I have to classify as unsatisfactory project management. Believe me, I perfectly understand the free software rules of cooperation and respecting the existing maintainer when there is one. Therefore, when I first started working on prc-tools I asked on 21-OCT-1999, *before* I started working, on the pilot-unix mailing list, the list where the original UNIX prc- tools were developed, the main list of the pilot-unix aficionados, who are the original and rightful prc-tools community, and the list most qualified as the official prc-tools mailing list, if there was a prc-tools maintainer I could contact. I was pointed to John Marshall, which is how I first learned of him. The very same day, 21-OCT-1999, I sent him an E-mail explaining what I was doing, which at that time consisted of just some GLib enhancements, no plans to fully take over prc-tools. I never got a response either to that E-mail or to any of my postings on pilot-unix, which I would expect to be read regularly by someone who is the prc-tools maintainer. That got me worried. Unfortunately, we all know all too well the typical story with open source software in cryostasis: the original maintainer is gone, there are people running around with ideas of reviving the project, but nothing really gets done. As that was the case with all pilot-unix software (pilot-link, prc-tools, pilrc, etc.) during the dark period, I was thinking that this was happening with prc-tools. As John failed to provide me with any indications to the contrary, I had no choice but to assume that this was indeed the case, and although John's efforts were noble, nothing of substance would come out of them (again, at that time there were no indications to the contrary, from John or from anyone). The above by itself is an instance of unsatisfactory project management. A real maintainer must keep his/her project visible and respond "Here!" to people looking for the maintainer of a project that otherwise seems dead. But while not hearing anything from John or anyone else indicating a living actively maintained project, I proceeded with my work. By then it became clear that my work could not be contained in a simple add-on or replacement component to prc- tools-0.5.0 and that a new complete version of prc-tools was needed. A new complete version requires a maintainer. Once again not seeing any indication of a living actively maintained project, I decided that I had the right to assume the maintainership of prc-tools. I still maintain my stand that I indeed had this right back in the fall of 1999. By January 2000 my project was almost complete. Although I never released it, I did in fact at that time have on my machine (and still do) the complete GNU toolchain and prc-tools that I developed completely by myself, without using anything from John Marshall. Thus I had effectively completed the major new version of prc-tools under assumption of my maintainership, and it was too late to turn back. And at the same time, John Marshall's version finally started to show signs of life. Thus I knew (as early as 4-JAN-2000 by what I could dig up) that an inevitable maintainership clash was coming. By then it was clear that his version as it existed then was how it was going to be released. I looked at it and evaluated it. It was definitely an improvement over what he had before in that it was packaged up in a way that conveyed that he really was serious about being the maintainer, instead of giving an impression of a quickie hack by someone who just slapped it together without any thought of maintenance or project management, as his previous stuff did (again, no personal offense intended, I'm simply stating how it looked from the viewpoint of assering maintainership). However, it was still missing several crucial features and user experience elements of prc-tools-0.5.0, and it really didn't follow the original mission and purpose of prc-tools. My version, however, at that time already did everything that prc-tools-0.5.0 does, most features were significantly enhanced, and major new features were added in a way that was logically consistent with the original design of prc-tools. There was a clear maintainership clash. Rather than a case of two people arguing over one piece of code as to who should start changing it and be the maintainer of these changes, this was a case of two independently developed versions with a common ancestor inherited from a no-longer-active maintainer, having very little code in common, competing over which should be considered the trunk successor and which is a branch. Given how John Marshall effectively failed to assert himself as the maintainer when I was just starting my project and as I was working on it, an argument that John already was the maintainer before and I failed to respect him as such doesn't apply. Since I consider my original assumption of maintainership in fall 1999 to be justified, my continued maintainership after I have developed the product is also justified. Aside from maintainership justification, there was the issue of simply what would be in the best interest of the community. Each version has some features that the other lacks. Any argument over which features are more important will be divided along party lines and reach no consensus. I do, however, firmly believe that the people who have supported prc-tools from day one and who are and have always been fighting for their cause, regardless of whether they are a majority or a minority, simply because they are the original supporters of prc- tools have the right to see the name prc-tools given to the version that supports their world view. That is simply The Right Thing To Do. And the features missing in John Marshall's version are from the original prc-tools. And so I decided that it was the right thing to do for me to maintain that my version, rather than John Marshall's, is the trunk prc-tools. It was very painful for everyone, but it had to be done. I released my version, giving it the trunk version number 0.6.0. My own toolchain (which I never released) was still incomplete (all the framework for multiple code segments was there, but actual intersegment references could be made only in assembly, not in C, making it not end-user-usable) and I borrowed John's as a temporary measure while I was completing my own, which I knew would take a long time and which I'm still doing. It was still my version, however, as the set of features and the user experience are determined much more by the support environment, which is completely my own, than by the toolchain. Having released prc-tools-0.6.0beta, I had to support it in the mailing lists. This has angered some people, some of whom were at my civilian employer's office where I was hosting the project at that time. As a result, I was away from PalmOS-related mailing lists for two months from early February till early April. It was then that Palm stabbed our community in the back. Cowardly and schemingly taking advantage of my absence from the list due to the interference from the reactionaries at my civilian employer's office and my inablility to voice protest, Palm has put John Marshall's version of prc-tools, which by the above argument is deemed divergent and not mainstream, on the development tools pages for the target OS. As it is a divergent version, they must have given it its own name, clearly stated that it's a divergent version made from prc-tools, and pointed to the site for the current maintainer of the original prc-tools, who is me. They did exactly the opposite, however, and misrepresented it as the original software, i.e., as prc-tools. This constitutes free software hoarding and is extremely damaging to our community. They have no right to do this and we must stop them, doing whatever it takes, to save ourselves from extinction. And extinction is what our community is threatened with by Palm's actions. As prc-tools have been in cryostasis for so long, a lot of people now have no idea as to their actual status. Since the development tools pages for the target OS is the most logical place to start, most people start there. If that's all they look at, Palm's feature-missing divergent version is all they will see. And what if that newcomer is a prc-tools-0.5.0 user/fan who believes in its cause and searches for a new version along the same line? Palm's misrepresentation of prc-tools will send the poor fellow the message that the original prc-tools are dead and that only Palm's hobbled divergent version exists. The poor fellow will never have the chance to learn that the original prc-tools are alive and well. Ever since my return to the mailing lists in early April I have been fighting to make Palm stop their damaging actions. As they consistently failed to cooperate, I had to resort to compensating for their misrepresentation of prc- tools on the development tools pages by actively voicing protest on their mailing lists, continuously alerting people to the misrepresentation, and providing the otherwise unavailable pointers to and support for the real prc- tools. Then on 1-MAY-2000 Palm retaliated against my efforts to stop the misrepresentation and further crippled our community by banning me from their mailing lists. This outlandishly crosses all lines of purposely damaging and retaliatory behavior and requires prompt and concerted action from our community to stop, which we must do to save ourselves from extinction. Now that we have our own mailing list, we need to gather all the users and supporters of the true prc- tools to sign a petition to Palm affirming our version of prc-tools as the true one and demanding that Palm stops its representation of our software and reinstates all banned members of our community to their mailing lists with a public apology. If they still don't comply, we will need to seek advice from the FSF on how to stop free software hoarding, probably with a lawsuit. But in any case, we must be firm and show the world that free software hoarding will not be tolerated! Finally, note that none of these issues would exist if John Marshall and others working on the competing prc-tools realized that neither they nor the PalmOS community have anything to gain by competing with us and making their own divergent version, and that they would be much better off and doing a much better service to the PalmOS development community by instead implementing their features (features that their version has and ours doesn't, like C++ support) in the framework of our mainstream version. I as the maintainer would be very willing to make it possible for them to do so if they were to cooperate. As for future development of the tools, in the archive of this mailing list (ivan.Harhan.ORG:/fs1/mailing-lists/ese-palmos-tools.archive) you can see my posting which explains where and how will the future development of our tools will proceed and shows how the competing version has no future. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Fri May 26 17:37:24 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA19214; Fri, 26 May 00 17:37:22 CDT Date: Fri, 26 May 00 17:37:22 CDT From: msokolov (Michael Sokolov) Message-Id: <0005262237.AA19214@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: OK to update PilRC? John Peterson wrote: > After installing prc-tools-0.6.0 beta I noticed that the PilRC tool is a = > bit > old. The version being used is 1.5 [...] That's because when I was making that beta, I had no room whatsoever in my mind for PilRC, not even for looking into what versions exist, so it shipped with exactly the same PilRC as prc-tools-0.5.0. > [...] the crurrent version on the PilRC= > > webpage is at 2.5 > (http://www.hig.se/~ardiri/development/palmIII/pilrc/index.html). > > Do you guys think it would be ok to upgrade to a newer version? Would it= > > break anything? Sure, you can use any PilRC version you want. Wes Cherry developed PilRC up to version 2.4. After that Aaron Ardiri took over and made version 2.5. I myself have no interest in maintaining PilRC and no one else seems to, so I had no problem with him maintaining it. However, at the end of April he started making personal attacks on me, disrespecting our project, and defending Palm's hoarding of prc-tools. As a result, I probably won't be able to include any software from him in any project or package maintained or distributed by the IFCTF ESE group, unless he changes his attitude. This means that I will probably have to ship PilRC version 2.4, the last version from Wes Cherry, unless someone else here volunteers as the PilRC maintainer. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Tue Jun 6 14:55:49 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA14368; Tue, 6 Jun 00 14:55:29 CDT Received: by aero.org id <17215-1>; Tue, 6 Jun 2000 12:55:40 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa21274; Tue Jun 6 12:51:55 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id MAA04372 for ; Tue, 6 Jun 2000 12:51:54 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id MAA01211; Tue, 6 Jun 2000 12:51:54 -0700 (PDT) Message-Id: <200006061951.MAA01211@malibu.aero.org> From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ese-palmos-tools@ivan.Harhan.ORG Subject: coaxing data into text Date: Tue, 6 Jun 2000 12:51:58 -0700 I recently found that my application is storing constant data in the .data section. Since the data segment is loaded onto the heap during initialization, the heap is being unnecessarily consumed. To circumvent this problem, I have modified many of the declarations/definitions to "const" (where applicable), which places the data in the read-only text section instead. This has freed up a considerable amount of heap by shinking the compressed data segment from 18K to 8K. The problem is that it doesn't go far enough. Typical, scaled-down problem: typedef struct { const int a; const char * const b; } label; const static label arr[] = { {1,"some text"}, {1,"more text"} }; Here, the literal text is placed in the text segment, but the arr is not, even though it and its contents are const. Is it even possible to do this, given the pointer in the label struct? Thanks, Jeff From John_W_Marshall@palm.com Tue Jun 6 15:12:07 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA14441; Tue, 6 Jun 00 15:12:04 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA12440; Tue, 6 Jun 2000 13:12:22 -0700 (PDT) Received: from hqpalmsmtp.palm.com (hqpalmsmtp.OPS.3Com.COM [139.87.49.252]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id NAA07529; Tue, 6 Jun 2000 13:12:13 -0700 (PDT) From: John_W_Marshall@palm.com Received: by hqpalmsmtp.palm.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882568F6.006F24E3 ; Tue, 6 Jun 2000 13:13:59 -0700 X-Lotus-Fromdomain: 3COM To: Jeff Collins Cc: ese-palmos-tools@ivan.Harhan.ORG Message-Id: <882568F6.006F243C.00@hqpalmsmtp.palm.com> Date: Tue, 6 Jun 2000 13:11:38 -0700 Subject: Re: coaxing data into text Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jeff Collins wrote: > Here, the literal text is placed in the text segment, but the arr > is not, even though it and its contents are const. Is it even > possible to do this, given the pointer in the label struct? Alas, no, the pointer kills it. See news://news.massena.com/LLWByUVd$GA.219@www.massena.com John From msokolov Tue Jun 6 15:23:06 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA14481; Tue, 6 Jun 00 15:23:03 CDT Date: Tue, 6 Jun 00 15:23:03 CDT From: msokolov (Michael Sokolov) Message-Id: <0006062023.AA14481@ivan.Harhan.ORG> To: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: coaxing data into text Jeff Collins wrote: > I recently found that my application is storing constant data in the > .data section. Since the data segment is loaded onto the heap during > initialization, the heap is being unnecessarily consumed. To > circumvent this problem, I have modified many of the > declarations/definitions to "const" (where applicable), which places > the data in the read-only text section instead. This has > freed up a considerable amount of heap by shinking the compressed data > segment from 18K to 8K. Yep! > The problem is that it doesn't go far enough. > > [...] > > Here, the literal text is placed in the text segment, but the arr > is not, even though it and its contents are const. Is it even > possible to do this, given the pointer in the label struct? No, it isn't. The whole point of position-independent code (PIC) is that it can't contain absolute addresses! A pointer is an absolute address. An initialized pointer is an absolute address deposited into the program image. This is impossible in code segments and in fact it is possible in the data segment only because this version of the PalmOS gcc programming environment does special work to make it possible, as explained in Chapter 10 of the manual. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Sat Jun 10 16:09:38 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA21734; Sat, 10 Jun 00 16:09:31 CDT Date: Sat, 10 Jun 00 16:09:31 CDT From: msokolov (Michael Sokolov) Message-Id: <0006102109.AA21734@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Replacing build-prc with par ESE PalmOS tools users, I'm replacing the build-prc program that has been in all prc-tools versions so far with David Williams' par, which can be downloaded from: http://www.djw.org/product/palm/par/index.html par can build PRCs just like build-prc, but unlike build-prc it sets the timestamp correctly, allows the database version and flags to be set, allows examining PRCs and ripping them apart, and does all this with PDBs as well. I have written a build-prc.sh Bourne shell script that emulates the build-prc functionality and syntax using par. It is in ivan.Harhan.ORG:/pub/embedded/palmos/build-prc.sh -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From John_W_Marshall@palm.com Sat Jun 10 17:12:26 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA21812; Sat, 10 Jun 00 17:12:22 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA03946; Sat, 10 Jun 2000 15:13:01 -0700 (PDT) Received: from hqpalmsmtp.palm.com (hqpalmsmtp.OPS.3Com.COM [139.87.49.252]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id PAA12254; Sat, 10 Jun 2000 15:12:51 -0700 (PDT) From: John_W_Marshall@palm.com Received: by hqpalmsmtp.palm.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882568FA.007A3D83 ; Sat, 10 Jun 2000 15:15:11 -0700 X-Lotus-Fromdomain: 3COM To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG, djw@djw.org Message-Id: <882568FA.007A3C35.00@hqpalmsmtp.palm.com> Date: Sat, 10 Jun 2000 15:12:20 -0700 Subject: Re: Replacing build-prc with par Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Michael Sokolov writes: > I'm replacing the build-prc program that has been in all prc-tools versions so > far with David Williams' par [...] > par can build PRCs just like build-prc, but unlike build-prc it sets the > timestamp correctly, allows the database version and flags to be set, allows > examining PRCs and ripping them apart, and does all this with PDBs as well. FYI, par (including v00.03) does not handle host timezones correctly. You seen to be implying that all versions of build-prc suffer from all the problems listed. That is not true. John From msokolov Sat Jun 10 18:24:10 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA21893; Sat, 10 Jun 00 18:24:04 CDT Date: Sat, 10 Jun 00 18:24:04 CDT From: msokolov (Michael Sokolov) Message-Id: <0006102324.AA21893@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Replacing build-prc with par Cc: djw@djw.org John_W_Marshall@palm.com wrote: > FYI, par (including v00.03) does not handle host timezones correctly. Well, it's still better I think than putting in a hardcoded constant date some time in 1996 as build-prc currently does. :-) If this is a bug in par, David, do you want to fix it? If you don't have time or aren't interested, I may do it later when I'm done with more urgent stuff, or anyone else who needs this fixed badly enough can do it. > You seen to be implying that all versions of build-prc suffer from all the > problems listed. That is not true. It is true for all versions of prc-tools from 0.1.0 (original) to 0.6.0 (current). -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From John_W_Marshall@palm.com Sat Jun 10 19:11:25 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA21942; Sat, 10 Jun 00 19:11:21 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA12099; Sat, 10 Jun 2000 17:11:57 -0700 (PDT) Received: from hqpalmsmtp.palm.com (hqpalmsmtp.OPS.3Com.COM [139.87.49.252]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id RAA21129; Sat, 10 Jun 2000 17:11:47 -0700 (PDT) From: John_W_Marshall@palm.com Received: by hqpalmsmtp.palm.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882568FB.000148A4 ; Sat, 10 Jun 2000 17:14:01 -0700 X-Lotus-Fromdomain: 3COM To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG, djw@djw.org Message-Id: <882568FB.000147F2.00@hqpalmsmtp.palm.com> Date: Sat, 10 Jun 2000 17:11:11 -0700 Subject: Re: Replacing build-prc with par Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Well, it's still better I think than putting in a hardcoded constant date > some time in 1996 as build-prc currently does. :-) Build-prc v2.0, which is also current, handles timestamps and timezones in this situation (struct tm <-> Palm OS time) with no known problems. The code already exists. There is no reason not to use it. (Except licensing. Par's licensing is unclear.) John From msokolov Sat Jun 10 19:29:14 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA21974; Sat, 10 Jun 00 19:29:08 CDT Date: Sat, 10 Jun 00 19:29:08 CDT From: msokolov (Michael Sokolov) Message-Id: <0006110029.AA21974@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Replacing build-prc with par Cc: djw@djw.org John_W_Marshall@palm.com wrote: > Build-prc v2.0, which is also current, handles timestamps and timezones > in this situation (struct tm <-> Palm OS time) with no known problems. > > The code already exists. There is no reason not to use it. OK, then it's a matter of getting it into par, or fixing par in some other way. David or John, do you want to do it? If not, and no one else volunteers, I may do it, but right now I have higher priorities. Using build-prc v2.0 is not an option for me. It has nothing to do with it being good or bad, it simply isn't what I need here. It has GNU toolchain bits in it, and here I need a standalone tool that just manages resources and PRCs without caring whether they are program code or graphics or whatever, much less whether code is compiled with the Metrowerks compiler or with gcc, let alone which version of gcc. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Mon Jun 12 13:23:31 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA23927; Mon, 12 Jun 00 13:23:16 CDT Date: Mon, 12 Jun 00 13:23:16 CDT From: msokolov (Michael Sokolov) Message-Id: <0006121823.AA23927@ivan.Harhan.ORG> To: Bruce_Thompson@palm.com, ardiri@palmgear.com, dfedor@palm.com, ese-palmos-tools, pilot-unix@hcirisc.cs.binghamton.edu, prc-tools-devel@lists.sourceforge.net, wecs@technosis.com Subject: I'm disengaging from PRC-Tools and starting IPGPE instead Everyone concerned, I'm disengaging from PRC-Tools and instead starting a new project (under the IFCTF Embedded Systems Engineering command) which I named the IFCTF PalmOS GNU Programming Environment (IPGPE). The reference to the IFCTF in its name will unambiguously distinguish it from any other environments anyone else may develop which target PalmOS and/or use GNU tools. My new software will not be PRC-Tools because it will not produce PRCs. In this project I want to concentrate on compiling, building, debugging, and managing code only. PRCs can and do have more than just code. The final output from IPGPE will be a set of code and data resources. To bundle them into a PRC, use David Williams' par (http://www.djw.org/product/palm/par/index.html). To add UI resources to it, use PilRC maintained by Aaron Ardiri (http://www.ardiri.com/index.cfm?redir=palm&cat=pilrc). My primary reason for disengaging from PRC-Tools and starting the IPGPE project instead is that I want something that can be integrated into the Cygnus/GNU software development toolchain as a regular target. PRC-Tools cannot be. In the IPGPE project I hope to develop something that can and will be. Everything in this toolchain is fundamentally associated with a target and a configuration triplet. An m68k-coff toolchain is different from an m68k-elf toolchain. The way you manage resources and PRCs, however, has nothing to do what GNU configuration triplet you are using. There is no connection whatsoever between resources and PRCs, and, say, m68k-coff or m68k-elf. Indeed, it has nothing to do with the GNU toolchain at all. Therefore, building PRCs does not belong in the Cygnus/GNU toolchain, ruling out PRC-Tools. The first alpha version of IPGPE will be released soon. Its features and user experience will be as close as possible to my January 2000 distribution of prc- tools-0.6.0beta. Initially it will use many of the components developed for PRC-Tools, but as our work progresses, it will move closer and closer to our goal of becoming just a target in the Cygnus/GNU software development toolchain. My disengagement with PRC-Tools cancels all claims I have made of PRC-Tools maintainership. Palm's prc-tools-2.0 distribution and the prc-tools SourceForge project are the only current PRC-Tools to my knowledge. I will provide user support for my January 2000 prc-tools-0.6.0beta distribution until I release the first alpha version of IPGPE, but after that I will move it into an "old" subdirectory marking that it's preserved for archival purposes only and disclaiming maintainership. Anyone will be free to choose the programming environment they want: PRC-Tools, IPGPE, CodeWarrior, and Pila are the ones I know. When I release IPGPE and declare my January 2000 prc-tools-0.6.0beta distribution obsolete, I will encourage its users to switch to a currently supported environment. Those using prc-tools-0.6.0beta features and wishing to stick with them will get all of them in IPGPE. Those wishing to use PRC-Tools and work with their maintainer to get whatever features they need can go to the prc-tools SourceForge project instead. To my knowledge the main functional differences between prc-tools-2.0 and my current internal version of IPGPE, which is currently functionally identical to prc-tools-0.6.0beta and which won't change significantly in the first public alpha version, are as follows: * PRC-Tools support C++, IPGPE doesn't. * IPGPE supports GLib shared libraries, PRC-Tools don't. * Both PRC-Tools and IPGPE allow you to use either A4-based or A5-based data in applications, but the application startup code in PRC-Tools supports A5-based only, whereas that in IPGPE supports both. * Currently neither PRC-Tools nor IPGPE multilib on A4-based vs. A5-based data. PRC-Tools default to A5-based, making standard gcc libraries available to applications without hassle, but making them unavailable to GLibs and others at all. IPGPE defaults to A4-based, making these libraries available to anyone, but requires applications to maintain A4 in order for these libraries not to crash. * IPGPE provides clear unambiguous documented explicit support for building arbitrary custom program entities, PRC-Tools don't. My primary host platforms are 4.3 BSD UNIX (VAX) and FreeBSD. I have heard reports of users successfully building prc-tools-0.6.0beta for Linux and Windows without any difficulties, and I expect the same to be the case for IPGPE. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From djw@djw.org Tue Jun 13 22:53:26 2000 Received: from [140.174.164.2] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA26532; Tue, 13 Jun 00 22:53:19 CDT Received: from djw.org (h-D14EE128.avantgo.com [209.78.225.40]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id UAA1580084; Tue, 13 Jun 2000 20:53:44 -0700 (PDT) Sender: djw@meer.meer.net Message-Id: <39470194.2E29B48D@djw.org> Date: Tue, 13 Jun 2000 20:52:52 -0700 From: David Williams Organization: Guild of Machine Operators X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: John_W_Marshall@palm.com Cc: Michael Sokolov , ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Replacing build-prc with par References: <882568FA.007A3C35.00@hqpalmsmtp.palm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry for not responding earlier, I've been out of email range for a few days. John_W_Marshall@palm.com wrote: > > FYI, par (including v00.03) does not handle host timezones correctly. Could you expand on what that means John? Par just gets the time from time() and converts it from Unix time to Palm time. What should it do? As PalmOS devices only have "the time", I figured this was the best approach. Last time I checked par creates databases with the same time stamp that the desktop would in a similar temporal situation. > You seen to be implying that all versions of build-prc suffer from all the > problems listed. That is not true. But I'd have to agree with Michael that build-prc does seem to be a single purpose tool that might much more useful if it were more general. John_W_Marshall@palm.com wrote: > > Build-prc v2.0, which is also current, handles timestamps and timezones > in this situation (struct tm <-> Palm OS time) with no known problems. Par used to use struct tm, but I took it out because it's so unportable and could not see any real value. Maybe I missed something. I'd be happy if par got into the standard toolset, that was my intention. djw From msokolov Wed Jun 14 13:45:34 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA27678; Wed, 14 Jun 00 13:45:19 CDT Date: Wed, 14 Jun 00 13:45:19 CDT From: msokolov (Michael Sokolov) Message-Id: <0006141845.AA27678@ivan.Harhan.ORG> To: djw@djw.org, ese-palmos-tools Subject: Re: Replacing build-prc with par David Williams wrote: > I'd be happy if par got into the standard toolset, that was my > intention. I'm assuming you've seen my announcement of my disengagement from PRC-Tools and launch of IPGPE, haven't you? Assuming that you have, which standard toolset are you talking about? For PRC-Tools you would have to talk to John. IPGPE won't deal with PRCs at all, for reasons I have already explained: build-prc or par can only exist as build-prc or par, it's meaningless to have m68k-palmos- coff-build-prc or m68k-palmos-coff-par. I plan, however, on creating another toolkit, called PalmOS Resource Kit, in which I plan to include par, PilRC, a PilRC decompiler, and tools for converting resources from and to Mac formats. More on this later. David, you are welcome to subscribe to the ese-palmos-tools mailing list. Send a message to ese-palmos-tools-request@ivan.Harhan.ORG. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From djw@djw.org Wed Jun 14 14:43:45 2000 Received: from meer.meer.net by ivan.Harhan.ORG (5.61.1.1/1.36) id AA27775; Wed, 14 Jun 00 14:43:41 CDT Received: from djw.org (h-D14EE128.avantgo.com [209.78.225.40]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id MAA1717852; Wed, 14 Jun 2000 12:44:37 -0700 (PDT) Sender: djw@meer.meer.net Message-Id: <3947E072.DB30E569@djw.org> Date: Wed, 14 Jun 2000 12:43:46 -0700 From: David Williams Organization: Guild of Machine Operators X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Michael Sokolov Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: Re: Replacing build-prc with par References: <0006141845.AA27678@ivan.Harhan.ORG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Sokolov wrote: > > David Williams wrote: > > > I'd be happy if par got into the standard toolset, that was my > > intention. > > I'm assuming you've seen my announcement of my disengagement from PRC-Tools and > launch of IPGPE, haven't you? No, well not the latter. > Assuming that you have, which standard toolset are you talking about? Any and all. I would just like hackers to have access to the tool. I think it's useful, and I think libprc is a good foundation for writing other prc/pdb manipulating tools. There is no need for this code to be rewritten every time a new tool is needed. That was the point of the exorcise. > For PRC-Tools you would have to talk to John. IPGPE > won't deal with PRCs at all, for reasons I have already explained: build-prc or > par can only exist as build-prc or par, it's meaningless to have m68k-palmos- > coff-build-prc or m68k-palmos-coff-par. I agree with your logic. > I plan, however, on creating another toolkit, called PalmOS Resource Kit, in > which I plan to include par, PilRC, a PilRC decompiler, and tools for > converting resources from and to Mac formats. More on this later. > > David, you are welcome to subscribe to the ese-palmos-tools mailing list. Send > a message to ese-palmos-tools-request@ivan.Harhan.ORG. Ok, I will do that. djw From john_w_marshall@palm.com Wed Jun 14 17:09:00 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA27984; Wed, 14 Jun 00 17:08:56 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA09438; Wed, 14 Jun 2000 15:08:34 -0700 (PDT) Received: from kovalevskaya.palm.com (johnm@kovalevskaya.OPS.3Com.COM [139.87.32.94]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA07316; Wed, 14 Jun 2000 15:08:22 -0700 (PDT) Received: (from johnm@localhost) by kovalevskaya.palm.com (8.9.3/8.8.7) id PAA21651; Wed, 14 Jun 2000 15:06:09 -0700 From: John Marshall Message-Id: <200006142206.PAA21651@kovalevskaya.palm.com> Subject: Re: Replacing build-prc with par To: djw@djw.org (David Williams) Date: Wed, 14 Jun 2000 15:06:09 -0700 (PDT) Cc: john_w_marshall@palm.com, msokolov@ivan.Harhan.ORG, ese-palmos-tools@ivan.Harhan.ORG, prc-tools-devel@lists.sourceforge.net (pdevel) In-Reply-To: <882568FE.006825FF.00@hqpalmsmtp.palm.com> from "David Williams" at Jun 14, 2000 11:54:20 AM X-Mailer: ELM [version 2.5 PL0pre8] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Williams wrote: > John_W_Marshall@palm.com wrote: >> FYI, par (including v00.03) does not handle host timezones correctly. > > Could you expand on what that means John? Par just gets the time from > time() and converts it from Unix time to Palm time. It needs to handle time zones on the host. For example: /* prctime() in time.c */ if (time(&utime) == (time_t)-1) return (prc_time_t)-1; ptime = UNIX_TO_MAC_TIME(utime); First off, you're assuming that utime is a count of seconds since 1970. This is not required by Standard C, so this code is inherently unportable. But perhaps that is a POSIX requirement (I can't remember), so maybe the code is portable between POSIX systems... Okay, I just checked and POSIX defines the format of time_t to be a count of seconds since 1970 UTC. So you're fine if you restrict yourself to POSIX platforms. But utime is *UTC*. Well... this is hard to talk about, but hopefully you get the idea. utime is in UTC, but you want local time. Here's an example of what goes wrong: $ date Wed Jun 14 14:35:36 PDT 2000 $ par c foo.pdb blah blah blah $ par h foo.pdb | grep ctime ctime: 200006141435 $ TZ=Pacific/Auckland par h foo.pdb | grep ctime ctime: 200006150935 It ought to output the same thing regardless of what time zone the host happens to be in. It's also noticeable because `par h' outputs the wrong times for databases created with build-prc v2. (And I know that build-prc is right because it agrees with the way TimSecondsToDateTime interprets the values on the device.) > Last time I checked par creates databases with the same time > stamp that the desktop would in a similar temporal situation. When you hotsync a database onto the device, the device sets the creation and modified dates to now, i.e., the creation time is the time the database was created on that particular device. So if you are checking what par does compared to the desktop by looking at databases on the device, your results are being masked by this. (This also means that the datestamps you write are mostly ignored, so this bug doesn't matter too much :-)) Assuming it seems to be worth fixing, here's the story: Since palm time has no concept of time zones, the thing to do seems to be to use UTC and gmtime and friends instead of local time. Hence: * prctimetostr should use gmtime instead of localtime. * prctime and prcstrtotime need to correct for the host local time zone. I believe this is impossible using the Standard C time facilities -- and I've tried very hard! If you can depend on the tzname, timezone, daylight side-effects that Linux's localtime() has (is this POSIX?), it may be possible. > Par used to use struct tm Because of that impossibility and the lack of portability anyway, I gave up on trying to use the standard library routines, and just used a struct tm as a container and wrote some non-timezone-aware date functions. The code is in pfdtime.c and it's not a lot of fun to write. :-) John From john_w_marshall@palm.com Wed Jun 14 18:01:55 2000 Received: from seattle.3com.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA28065; Wed, 14 Jun 00 18:01:51 CDT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA25576; Wed, 14 Jun 2000 15:45:18 -0700 (PDT) Received: from kovalevskaya.palm.com (johnm@kovalevskaya.OPS.3Com.COM [139.87.32.94]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA28800; Wed, 14 Jun 2000 15:45:04 -0700 (PDT) Received: (from johnm@localhost) by kovalevskaya.palm.com (8.9.3/8.8.7) id PAA21787; Wed, 14 Jun 2000 15:42:51 -0700 From: John Marshall Message-Id: <200006142242.PAA21787@kovalevskaya.palm.com> Subject: Re: Replacing build-prc with par To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Date: Wed, 14 Jun 2000 15:42:50 -0700 (PDT) Cc: john_w_marshall@palm.com, msokolov@ivan.Harhan.ORG, ese-palmos-tools@ivan.Harhan.ORG In-Reply-To: <882568FE.0068204B.00@hqpalmsmtp.palm.com> from "Michael Sokolov" at Jun 14, 2000 11:54:05 AM X-Mailer: ELM [version 2.5 PL0pre8] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Sokolov wrote: > I plan, however, on creating another toolkit, called PalmOS Resource Kit, in > which I plan to include par, PilRC, a PilRC decompiler, and tools for > converting resources from and to Mac formats. More on this later. Whatever. All these tools already exist. It would be useful to make a collection of links to them all, and perhaps a distribution of them -- which would be subject to all the usual caveats about up-to-dateness. > David, you are welcome to subscribe to the ese-palmos-tools mailing list. Send > a message to ese-palmos-tools-request@ivan.Harhan.ORG. Ditto http://lists.sourceforge.net/mailman/listinfo/prc-tools-devel of course. John From msokolov Fri Jul 14 13:17:44 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA01305; Fri, 14 Jul 00 13:17:29 CDT Date: Fri, 14 Jul 00 13:17:29 CDT From: msokolov (Michael Sokolov) Message-Id: <0007141817.AA01305@ivan.Harhan.ORG> To: ese-palmos-tools Subject: ESE PalmOS tools status update ESE PalmOS tools users, This is just to let you all know that I haven't forgotten about you and that I will still be developing PalmOS tools. However, I do have to let you know that in the past my work on PalmOS tools was partially in connection with me working at JP Systems where I developed PalmOS software, and I no longer work there. I will not abandon my ESE PalmOS tools as a result of leaving JP Systems, but they are now a couple levels lower in my priority queue. I've salvaged all my PalmOS tools sources from the old place, but right now I just have them sitting in tarballs, as I haven't set up a new development host yet. But I promise that I won't abandon this stuff, and eventually I will release everything I wanted to release, even if it takes a very long time. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From collins@manhattan.aero.org Fri Jul 14 14:19:52 2000 Received: from aero.org by ivan.Harhan.ORG (5.61.1.1/1.36) id AA01388; Fri, 14 Jul 00 14:19:45 CDT Received: by aero.org id <17148-3>; Fri, 14 Jul 2000 12:20:34 -0700 Received: from manhattan.aero.org(130.221.117.45) via SMTP by aero.org, id smtpdAAAa22210; Fri Jul 14 12:19:34 2000 Received: from malibu.aero.org (malibu.aero.org [130.221.117.20]) by manhattan.aero.org (8.9.3+Sun/8.9.1) with ESMTP id MAA23706; Fri, 14 Jul 2000 12:19:32 -0700 (PDT) Received: (from collins@localhost) by malibu.aero.org (8.8.8+Sun/8.8.8) id MAA17831; Fri, 14 Jul 2000 12:19:33 -0700 (PDT) From: Jeff Collins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: msokolov@ivan.Harhan.ORG (Michael Sokolov) Cc: ese-palmos-tools@ivan.Harhan.ORG Subject: ESE PalmOS tools status update In-Reply-To: <0007141817.AA01305@ivan.Harhan.ORG> References: <0007141817.AA01305@ivan.Harhan.ORG> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <14703.25611.694853.829458@malibu.aero.org> Reply-To: Jeffery.D.Collins@aero.org Date: Fri, 14 Jul 2000 12:19:39 -0700 I have used prc-tools-0.6b (haven't checked out ESE Palm tools) to port Python to the Palm (http://www.isr.uci.edu/projects/sensos/python) because of the multisegmented GLib support. I performed a previous port using the original prc-tools-0.5 tools, but the result was unacceptable. Your significant contribution to this toolset has made my job alot easier and this port possible. A word about the port: the Python VM has been ported and a very simple interface (non-interactive) developed for demonstration purposes. A fully interactive interface has yet to be developed and the Python VM is currently being integrated with the PalmOS. Jeff Michael Sokolov writes: > ESE PalmOS tools users, > > This is just to let you all know that I haven't forgotten about you and that I > will still be developing PalmOS tools. However, I do have to let you know that > in the past my work on PalmOS tools was partially in connection with me working > at JP Systems where I developed PalmOS software, and I no longer work there. I > will not abandon my ESE PalmOS tools as a result of leaving JP Systems, but > they are now a couple levels lower in my priority queue. I've salvaged all my > PalmOS tools sources from the old place, but right now I just have them sitting > in tarballs, as I haven't set up a new development host yet. But I promise that > I won't abandon this stuff, and eventually I will release everything I wanted > to release, even if it takes a very long time. > > -- > Michael Sokolov Harhan Engineering Laboratory > Public Service Agent International Free Computing Task Force > International Engineering and Science Task Force > 615 N GOOD LATIMER EXPY STE #4 > DALLAS TX 75204-5852 USA > > Phone: +1-214-824-7693 (Harhan Eng Lab office) > E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) > From msokolov Fri Jul 14 16:34:30 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA01596; Fri, 14 Jul 00 16:34:27 CDT Date: Fri, 14 Jul 00 16:34:27 CDT From: msokolov (Michael Sokolov) Message-Id: <0007142134.AA01596@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: ESE PalmOS tools status update Jeff Collins wrote: > I have used prc-tools-0.6b (haven't checked out ESE Palm tools) [...] Ahh, let's get the terminology straight. ESE stands for Embedded Systems Engineering, it's the IFCTF group that handles most cross-compilers and similar tools. All tools I've ever developed for PalmOS, including prc-tools-0.6.0beta and everything I have in store for the future are collectively called ESE PalmOS tools. > [...] to > port Python to the Palm > (http://www.isr.uci.edu/projects/sensos/python) because of the > multisegmented GLib support. I performed a previous port using the > original prc-tools-0.5 tools, but the result was unacceptable. Your > significant contribution to this toolset has made my job alot easier > and this port possible. That's good to hear. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Tue Sep 5 03:31:48 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA28563; Tue, 5 Sep 00 03:31:34 CDT Date: Tue, 5 Sep 00 03:31:34 CDT From: msokolov (Michael Sokolov) Message-Id: <0009050831.AA28563@ivan.Harhan.ORG> To: Bruce_Thompson@palm.com, ardiri@palmgear.com, dfedor@palm.com, ese-palmos-tools, krollin@palm.com, pilot-unix@hcirisc.cs.binghamton.edu Subject: IPGPE first alpha version GNU-based PalmOS software developers, On 12-JUN-2000 I had announced that I started developing a new software development environment for PalmOS, the IFCTF PalmOS GNU Programming Environment (IPGPE). Now I'm pleased to announce the public availability of the first alpha version. You can find it on ivan.Harhan.ORG in /pub/embedded/palmos/ipgpe-alpha. For those of you who prefer URLs, it is: ftp://ivan.Harhan.ORG/pub/embedded/palmos/ipgpe-alpha/ IPGPE is copyrighted by the International Free Computing Task Force and released under the GNU General Public License (GPL), except for the target libraries, which are in the public domain so that you can freely link them into your programs without any restrictions. Building and installation is currently not for the faint of heart and gdb debugging is currently missing, but it's still exciting. The debugging gap will be filled real soon. I no longer work at the company where I did my PalmOS development before, but I am now doing a new PalmOS software development contract. This one is at Palm itself. :-) I'm still maintaining IPGPE and other tools in my IFCTF capacity, though, and they are still copyrighted and controlled by the IFCTF. However, the fact that I'm doing PalmOS development helps these projects, as otherwise they would have had a substantially lower priority relative to other IFCTF and IESTF projects. Enjoy IPGPE! -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From msokolov Thu Sep 21 10:44:24 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA07171; Thu, 21 Sep 00 10:44:10 CDT Date: Thu, 21 Sep 00 10:44:10 CDT From: msokolov (Michael Sokolov) Message-Id: <0009211544.AA07171@ivan.Harhan.ORG> To: ese-palmos-tools, pilot-unix@hcirisc.cs.binghamton.edu Subject: IPGPE status update Cc: Bruce_Thompson@palm.com, aaron@ardiri.com, dfedor@palm.com, krollin@palm.com When announcing the first alpha release of IPGPE, I wrote: : I no longer work at the company where I did my PalmOS development before, but I : am now doing a new PalmOS software development contract. This one is at Palm : itself. :-) I'm still maintaining IPGPE and other tools in my IFCTF capacity, : though, and they are still copyrighted and controlled by the IFCTF. However, : the fact that I'm doing PalmOS development helps these projects, as otherwise : they would have had a substantially lower priority relative to other IFCTF and : IESTF projects. There have been some changes, namely the project at Palm didn't pan out due to management miscommunication (based on this and other instances, I can say fairly certainly that Palm's management is screwed up) and instead I'm starting another job as the Director of Mobile Applications at an Orange County, CA based start-up company. This should be good news for the developer community using my development tools, as I will now be doing PalmOS development in a position with greater leadership and authority, which means more opportunity for the deployment of my development tools. As for the upcoming IPGPE enhancements, I'm hoping to lift the 32K barrier real soon now. As you should remember, although an unlimited number of segments is supported and there are no artificially set limits on segment size, there is a de facto limit of 32K per segment due to intrasegment calls and references being signed 16-bit displacements only. I'm hoping to release a new version of IPGPE-Alpha soon with this limit lifted. I've posted a patch to the binutils list last week restructuring the relaxer in GNU m68k as (the relaxer is the part of the assembler that auto-sizes jumps and other PC-relative references), which is currently waiting for binutils head maintainer Nick Clifton's approval. When that is done, I'll make another patch for gas to be able to generate 68000 instruction sequences that have the effect of 32-bit PC-relative displacements, which will automatically lift the 32K limits in all 68000 embedded PIC systems such as IPGPE. Stay tuned! -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From amoroso@mclink.it Wed Oct 18 02:46:51 2000 Received: from net128-053.mclink.it by ivan.Harhan.ORG (5.61.1.1/1.36) id AA16917; Wed, 18 Oct 00 02:46:39 CDT Received: from net145-038.mclink.it (net145-038.mclink.it [195.110.145.38]) by mail.mclink.it (8.9.3/8.9.0) with SMTP id JAA19536 for ; Wed, 18 Oct 2000 09:50:59 +0200 (CEST) From: Paolo Amoroso To: ese-palmos-tools@ivan.Harhan.ORG Subject: Size of IPGPE and related binaries on Linux Date: Wed, 18 Oct 2000 09:50:48 +0100 Organization: Paolo Amoroso - Milan, ITALY Message-Id: X-Mailer: Forte Agent 1.6/32.525 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to know the approximate disk space required on Linux by the current IPGPE and all related _binaries_, i.e. IPGPE + GCC toolchain + Palm OS SDK (anything else?). I don't need an exact figure, a rough estimate would do. I guess the size of the first production release will not differ much from the current pre-Alpha distribution, right? Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/ From msokolov Wed Oct 18 11:36:10 2000 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA17356; Wed, 18 Oct 00 11:36:06 CDT Date: Wed, 18 Oct 00 11:36:06 CDT From: msokolov (Michael Sokolov) Message-Id: <0010181636.AA17356@ivan.Harhan.ORG> To: ese-palmos-tools Subject: Re: Size of IPGPE and related binaries on Linux Paolo Amoroso wrote: > I would like to know the approximate disk space required on Linux by the > current IPGPE and all related _binaries_, i.e. IPGPE + GCC toolchain + Palm > OS SDK (anything else?). I don't need an exact figure, a rough estimate > would do. Dunno about Linux, my UNIX/VAX binaries total about 12 MB. > I guess the size of the first production release will not differ > much from the current pre-Alpha distribution, right? Right. In fact, it isn't really different for IPGPE from the toolchain for any other target. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) From jtacoma@chat.carleton.ca Sun Nov 26 00:32:09 2000 Received: from [134.117.1.98] by ivan.Harhan.ORG (5.61.1.1/1.36) id AA01148; Sun, 26 Nov 00 02:31:54 CST Received: from prince (jtacoma@prince.chat.carleton.ca [134.117.1.224]) by wabakimi.chat.carleton.ca (8.9.1a/8.9.1) with ESMTP id DAA02158; Sun, 26 Nov 2000 03:33:00 -0500 (EST) From: Joshua Tacoma Received: by prince (8.9.3+Sun/Sun-Client) id IAA16649; Sun, 26 Nov 2000 08:32:59 GMT Date: Sun, 26 Nov 2000 08:32:59 GMT Message-Id: <200011260832.IAA16649@prince> To: ese-palmos-tools@ivan.Harhan.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Url: http://www.einstein.org/pilot/current/0082.html X-Mailer: Lynx, Version 2.8.2rel.1 Subject: subscribe joshtacoma@hotmail.com Cc: jtacoma@chat.carleton.ca From manojkoushik@hotmail.com Sun Nov 26 12:14:48 2000 Received: from oe25.law7.hotmail.com by ivan.Harhan.ORG (5.61.1.1/1.36) id AA01797; Sun, 26 Nov 00 14:14:44 CST Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 12:15:48 -0800 X-Originating-Ip: [128.6.157.151] From: "Manoj Koushik" To: Subject: subscribe Date: Sun, 26 Nov 2000 15:20:35 -0500 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C057BC.6CE72650" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300 Message-Id: X-Originalarrivaltime: 26 Nov 2000 20:15:48.0634 (UTC) FILETIME=[AA84EFA0:01C057E5] This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C057BC.6CE72650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0029_01C057BC.6CE72650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0029_01C057BC.6CE72650-- From msokolov Wed Apr 25 13:49:37 2001 Received: by ivan.Harhan.ORG (5.61.1.1/1.36) id AA16684; Wed, 25 Apr 01 13:49:37 PDT Date: Wed, 25 Apr 01 13:49:37 PDT From: msokolov (Michael Sokolov) Message-Id: <0104252049.AA16684@ivan.Harhan.ORG> To: ese-palmos-tools Subject: I'm stepping down as PalmOS tools developer Cc: Alex.Farcasiu@JPSystems.com, Bobby.Kolev@JPSystems.com, Bruce_Thompson@palm.com, aaron@ardiri.com, dfedor@palm.com Dear ESE PalmOS tools users, This announcement is to inform you that unfortunately, I can no longer justify working on PalmOS and therefore I will have to leave the ESE PalmOS tools project. While I have the utmost respect and solidarity for *all* segments of the world free hacker community, regardless of what technology or platform it is concerned with (which fully coincides with the mission of the International Free Computing Task Force to fight for freedom in all computingdom), I have limited resources, and I simply cannot justify spending a large amount of time or resources on a project that I have no personal need or interest in, which is not a critical IFCTF project, and which concerns technology (handheld computing and especially Palm) that by both my judgment and that of IFCTF is of very little community value. I worked on ESE PalmOS tools in the past because PalmOS was my day job (actually through the end of year 2000 it was two full-time jobs and a number of contracts), and I could not tolerate the absolutely mediocre development tools otherwise available for PalmOS. However, I no longer work with PalmOS in any capacity (my current day job is maintaining Linux on certain very high-end PowerPC hardware for the telecom industry), and I can no longer justify working on PalmOS tools or anything else for PalmOS. The free hacker community is welcome to take over any and all of the software I have developed or maintained for PalmOS. To my knowledge I do not have any code for any of this software that hasn't already been made public in one way or another. The last work I have done on ESE PalmOS tools can be found in ivan.Harhan.ORG:/pub/embedded/palmos I can still host the ese-palmos-tools mailing list (which you should feel free to use as you wish), or if someone else wants to host it, I'll gladly pass along the list of subscribers. I may still be able to provide machine accounts for some active developers as promised previously, but this is not a guarantee. With the best wishes to anyone who wants to take over the project, -- Michael Sokolov Public Service Agent International Engineering and Science Task Force 1351 VINE AVE APT 27 Phone: +1-714-738-5409 FULLERTON CA 92833-4291 USA (home office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)