drew@cgfsv1.dec.com (Steve Drew) (10/03/86)
Since I have had a number of requests for my Manx improved version
of Matt's shell I will be posting it to the moderator for mod.sources's.
Hopefully you'll see it very soon.
Steve Drew at ENET: CGFSV1::DREW
ARPA: drew%cfgsv1.dec.com@decwrl.dec.com
USENET: {decvax!decwrl}!cgfsv1.dec.com!drew star@fluke.UUCP (David Whitlock) (10/11/86)
> > Since I have had a number of requests for my Manx improved version > of Matt's shell I will be posting it to the moderator for mod.sources's. > Hopefully you'll see it very soon. > Being new to the MANX compiler (but loving it), you make a reference in the makefile to ln -o SHELL ..... -lc32. What is that thing! (-lc32)! Somewhere I must have missed a 'thread' on this one. I assume is the call to search library file 'c32.lib' but where do I find this. It was not part of the archived sources posted to mod.amiga.sources. Can anyone shed some light. -- Dave Whitlock {decvax!microsof,uw-beaver,ssc-vax,allegra,lbl-csam}!fluke!star --John Fluke Mfg. Co., 33031 Schoolcraft Road, Livonia, MI 48150
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (10/13/86)
In article <3647@vax4.fluke.UUCP> star@fluke.UUCP (David Whitlock) writes: >... >Being new to the MANX compiler (but loving it), you make a reference in the >makefile to ln -o SHELL ..... -lc32. What is that thing! (-lc32)! Somewhere >I must have missed a 'thread' on this one. I assume is the call to search >library file 'c32.lib' but where do I find this. It was not part of the >archived sources posted to mod.amiga.sources. > >Can anyone shed some light. >-- >Dave Whitlock > {decvax!microsof,uw-beaver,ssc-vax,allegra,lbl-csam}!fluke!star >--John Fluke Mfg. Co., 33031 Schoolcraft Road, Livonia, MI 48150 Sounds to me like you're not a REGISTERED owner of the Manx system! If you were, you would know what c32.lib is. It's the 32 bit version of c.lib which is included in the package. If I'm wrong, I apologize in advance, but if you OWNED the package, I don't see how you could NOT know this. Paul. Disclaimer: I don't work for anybody, and opinions expressed are my own.
hull@hao.UUCP (Howard Hull) (10/14/86)
In article <3647@vax4.fluke.UUCP>, star@fluke.UUCP (David Whitlock) writes: > > Being new to the MANX compiler (but loving it), you make a reference in the > makefile to ln -o SHELL ..... -lc32. What is that thing! (-lc32)! Somewhere > I must have missed a 'thread' on this one. I assume is the call to search > library file 'c32.lib' but where do I find this. It was not part of the > archived sources posted to mod.amiga.sources. > I don't know what the people who know what they're doing do about this, but I located the 'c32.lib' on "Aztec C68K 3.20a Disk 2" in the "lib" directory. So when I get a source that has Intuition calls involving 32-bit pointers, I boot up with "Aztec C68K 3.20a 2/27/86" (Disk 1, really) in df0: , and my source disk in df1: (with the cd in the appropriate df1: directory), do the compile with cc snarf.c +L , then pick up the linker with Copy df0:c/ln to Ram:ln , then Assign SYS: "Aztec C68K 3.20a Disk 2:" Whereupon AmigaDOS will get suspicious about what I'm up to, will began to wonder whether I really have Disk 2, and will ask to see it by posting a requester requiring me to put the disk in any drive. I put it in df0: As soon as AmigaDOS is satisfied, I then do the actual link with the command: Ram:ln snarf.o -lc32 -o snarf , or if it's floating point code, I use: Ram:ln snarf.o -lm32 -lc32 -o snarf , tell it to look for mathlibs 1st. I have, incidently, had weird results with the Manx floating point, so I may be doing the latter one wrong. But I find that if I put the c32 lib first, the program usually hails the Guru outright on invocation. Hope this helps. Regards, H. "Gosh, here's a program I haven't changed yet, I wonder what it does..." Hull {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull
danny@convex.UUCP (10/17/86)
You're using a strange environment. If you have at least 512K, you'll want to copy your library into ram: and link like: ln snarf.c ram:c32.lib (or c.lib) There's no sense in copying ln to ram because it takes little noticable time to load but there's an incredible time gain with the library in ram. Also, how in the world can you stand to type those HUGE disk names? I've got my disks (backups) renamed to: Az: for disk 1 Aex: for disk 2 (Aztec Examples) Generally, keeping commands on disk and data files in memory has sped up things to a much more acceptable level (besides, my disk drive makes noises reminding of an Apple II drive grinding and such when linking) Dan Wallach
hamilton@uiucuxc.CSO.UIUC.EDU (10/17/86)
> You're using a strange environment. If you have at least 512K, you'll want > to copy your library into ram: and link like: > > ln snarf.c ram:c32.lib (or c.lib) better yet, use the "set" command redirect ln to ram: by default, then just say "ln snarf.o -lc". makes makefiles more portable too. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton