[lug] re: Make error and bash
Ian Vaughn Bevan
Ian.Bevan at Colorado.EDU
Mon Oct 1 13:50:30 MDT 2001
Thanks for the responses, Ken hit the nail on the head. I altered my $PATH to
inlcude the directory w/ ar in it and all is well.
Ian Bevan Ian.Bevan at colorado.edu
Information Technology Services 303.887.9223
University of Colorado
> Message: 2
> Date: Mon, 1 Oct 2001 10:06:02 -0600
> From: Ken Weinert <kenw at ihs.com>
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Make error w/ bash
> Reply-To: lug at lug.boulder.co.us
>
>
> --P7Tqkd/m/Jnohiaz
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> I'll bet that you don't have a definition for the AR macro (archiver)
> and the "cr" is actually the arguments. You'll probably see something
> like:
>
> $(AR) cr libbuiltins.a $(OBJS)
>
> in the Makefile.
>
> And, since this is a sun, I'd also bet that you can find the ar
> command
> in /usr/ccs/bin.
>
> * Ian Vaughn Bevan (Ian.Bevan at Colorado.EDU) [011001 16:00]:
> > I am trying to install bash-2.05 on a Sparcstation running Solaris
> 2.6. '=
> make'
> > runs all the way through, then erros out with the following message:
> >=20
> > make[1]: cr: Command not found
> > make[1]: *** [libbuiltins.a] Error 127
> > make[1]: Leaving directory `/local/usr/bash-2.05/builtins'
> > make: *** [builtins/libbuiltins.a] Error 1
> >=20
> > It's an old machine, could I be missing a library or something?
> >=20
> > Ian Bevan Ian.Bevan at colorado.edu
> > Information Technology Services 303.887.9223
> > University of Colorado
> > _______________________________________________
> > Web Page: http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>
> --=20
> Ken Weinert kenw at ihs.com 303-858-6956 (V) 303-705-4258 (F)
> GnuPG KeyID: 9274F1CE GnuPG available at
> http://www.gnupg.org/
> GnuPG Key Fingerprint: 1D87 3720 BB77 4489 A928 79D6 F8EC DD76 9274
> F1CE
> The biggest conspiracy has always been the fact that there
> is no conspiracy. Nobody's out to get you. Nobody gives a
> shit whether you live or die. There, you feel better now?
> --Dennis Miller
>
>
> --P7Tqkd/m/Jnohiaz
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.3 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAju4lGoACgkQ+OzddpJ08c6IwwCgq/5IWO/IqlzKvhP9+9m6KbiM
> pnIAn1glWYcmXqk6qPus7gq+FksXiVDP
> =h0ua
> -----END PGP SIGNATURE-----
>
> --P7Tqkd/m/Jnohiaz--
>
> --__--__--
>
> Message: 3
> Date: Mon, 1 Oct 2001 03:37:40 -0600 (MDT)
> From: "J. Wayde Allen" <wallen at lug.boulder.co.us>
> To: "List: Boulder Linux User's Group" <lug at lug.boulder.co.us>
> Subject: Re: [lug] Inexpensive Laser Printer (a quick review)
> Reply-To: lug at lug.boulder.co.us
>
> On Sun, 30 Sep 2001, Rob Riggs wrote:
>
> > Installing this printer gave me a glimpse of one of the uglier aspects
>
> > of Linux (and Unix in general). There is no standard printing
> subsystem.
>
> Printing under *nix always seems to be an issue. I have to admit that
> it
> took me several days to figure out printing under Linux the first time
> around. The problem is that I'm not sure what should be done, if
> anything. So ... this seems like a really valid topic for discussion.
>
> Not intending to be too pedantic, I know that Rob probably knows more
> about this than I, I'm thinking it might be worth digging back into
> the
> design philosophy for Unix. Rather than me typing a lot here, it
> would
> probably be instructive to refer everyone to the "newbie" columns I
> was
> writing several years back. These can be found at
> <http://lug.boulder.co.us/docs.html>.
>
> The key issue has always been that *nix has tried NOT to embed
> hardware
> specific code into the general OS software. Designers have always
> striven
> to keep hardware specific features at the kernel level and the kernel
> is
> supposed to allow each device to be accessible to the higher level OS
> structure as simple files. File contents are handled by the higher
> level
> programs. The idea has been to minimize the coding required to adapt
> a
> new piece of hardware to the system. After all, Unix was invented at
> a
> time when computer hardware was far less standard than it is today.
>
> The printing subsystem, if I understand what is meant here, would then
> be
> the lpr command. This allowed one to specify the low level printer
> characteristics such as where the printer is located (parallel, serial,
> or
> network port), its name, and how to talk to it. You'd then send print
> jobs to the printer of your choice using:
>
> lpr -Pprinter_name file_to_print
>
> You could also send a print job to the printer directly by typing
>
> cp file_to_print /dev/printer
>
> ,but the lpr command in concert with lpd was designed to handle print
> spooling etc.. This subsystem provides the mechanism and logistics
> for
> getting the file you want to print to the appropriate printer, and
> since
> it doesn't care about the file contents should work for any kind of
> printer you'd care to use. It was left up to the user, and/or the
> program
> creating the print file to create a file of the type that the printer
> could understand (ASCII, PCL, Postscript, etc.) My guess is that it
> is
> this last point where most of the problems lie. You can't just send a
> binary file to the printer without first converting to a format the
> printer understands.
>
> Here is where things get a bit sticky. In MSDOS/MSWindows you have
> the
> so-called device driver. This is philosophically a bit different that
> a
> kernel module in Linux since the driver contains both the hardware
> interface code, and often the data conversion code. In Linux the idea
> with the lpr command is to use data "filters". Filters are supposed to
> be
> the code that converts one specialize file format into the language
> that
> the printer recognizes. You can write your own, and/or find these
> filters
> on the net. The lpr command has a series of filter identifiers
> (c,d,f,g,l,n,p,t,v) that specify which filter should be used. Some of
> these may be hard coded in the lpr specification, but as memory serves
> you
> have to specify the path to the filter location associated with each
> of
> these letters in the /etc/printcap file along with the printer
> description. I think that lpr is "old" in the sense that there are only
> a
> limited number of printer filter identifies. However, there has been
> a
> solution.
>
> When building the printer description in the /etc/printcap file one
> specifies the default filter to be used when no filter option is
> specified. Then what has typically been done is to write this default
> filter so that it can read the magic numbers out of the printer files
> and
> decide what if any conversion needs to be done. These filters are
> usually
> called "magic filters" and eliminate the need for the user to know
> what
> kind of file conversion needs to be done.
>
> The advantage in this kind of world is that programs that want to
> print
> somewhere don't need to know anything about the printers. They simply
> need to create a file that is understood by the magic filter and to
> send
> their output through the lpr print subsystem.
>
> > Samsung has to provide seperate packages and give seperate
> instructions
> > for every major distribution. There is no way to distribute a seperate
>
> > ghostscript driver (ghostscript device drivers are all compiled into a
>
> > monolithic program). These problems have to be addressed if we are to
>
> > ever see better printer support under Linux.
>
> This is unfortunate, and I wonder if it is caused by approaching this as
> a
> printer "driver" problem? If they used the *nix philosophy it should
> be
> relatively simple to create a kernel module with the minimum code
> needed
> to talk to the device. Then they'd only need to build a magic filter
> designed to print standard file formats (ASCII, JPEG, TIFF,
> Postscript,
> PCL, etc.).
>
> My guess is that there are actually several issues:
>
> - Misunderstanding the *nix design philosophy and treating this as
> MSWindows style driver
>
> - Use of non-standard, proprietary printer languages
>
> - Confusion about just where these files should go in a
> distribution
>
> Of course, I may also have just completely missed the point. In any
> case,
> printing is a common topic with some serious stumbling blocks that
> should
> probably be discussed.
>
> - Wayde
> (wallen at lug.boulder.co.us)
>
>
> --__--__--
>
> Message: 4
> Date: Mon, 1 Oct 2001 11:42:26 -0600 (MDT)
> From: Shannon Johnston <nunar at nunar.com>
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Make error w/ bash
> Reply-To: lug at lug.boulder.co.us
>
> Didn't I read somewhere that the Solaris make had some BIG problems??
> Maybe it was the sparc gcc....
>
> Shannon Johnston
> nunar at nunar.com
> --------------------------------
>
> Hiroshima '45 Chernobyl '86 Windows '95
>
> --------------------------------
>
> On Mon, 1 Oct 2001, Ken Weinert wrote:
>
> > I'll bet that you don't have a definition for the AR macro
> (archiver)
> > and the "cr" is actually the arguments. You'll probably see
> something
> > like:
> >
> > $(AR) cr libbuiltins.a $(OBJS)
> >
> > in the Makefile.
> >
> > And, since this is a sun, I'd also bet that you can find the ar
> command
> > in /usr/ccs/bin.
> >
> > * Ian Vaughn Bevan (Ian.Bevan at Colorado.EDU) [011001 16:00]:
> > > I am trying to install bash-2.05 on a Sparcstation running Solaris
> 2.6. 'make'
> > > runs all the way through, then erros out with the following
> message:
> > >
> > > make[1]: cr: Command not found
> > > make[1]: *** [libbuiltins.a] Error 127
> > > make[1]: Leaving directory `/local/usr/bash-2.05/builtins'
> > > make: *** [builtins/libbuiltins.a] Error 1
> > >
> > > It's an old machine, could I be missing a library or something?
> > >
> > > Ian Bevan Ian.Bevan at colorado.edu
> > > Information Technology Services 303.887.9223
> > > University of Colorado
> > > _______________________________________________
> > > Web Page: http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> > --
> > Ken Weinert kenw at ihs.com 303-858-6956 (V) 303-705-4258 (F)
> > GnuPG KeyID: 9274F1CE GnuPG available at
> http://www.gnupg.org/
> > GnuPG Key Fingerprint: 1D87 3720 BB77 4489 A928 79D6 F8EC DD76 9274
> F1CE
> > The biggest conspiracy has always been the fact that there
> > is no conspiracy. Nobody's out to get you. Nobody gives a
> > shit whether you live or die. There, you feel better now?
> > --Dennis Miller
> >
> >
>
>
>
> --__--__--
>
> _______________________________________________
> LUG mailing list
> LUG at lug.boulder.co.us
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
>
>
> End of LUG Digest
>
More information about the LUG
mailing list