From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phil Goembel Subject: Re: ELKS Development/FAQ Questions Date: 01 Aug 2003 09:05:54 -0500 Sender: linux-8086-owner@vger.kernel.org Message-ID: <1059746752.15148.7870.camel@castle> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PSp3OflySQIP3MFkXQQk" Return-path: In-Reply-To: List-Id: To: Riley Williams Cc: Linux ELKS --=-PSp3OflySQIP3MFkXQQk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi again Riley, Thanks for taking the time to reply. On Thu, 2003-07-31 at 01:01, Riley Williams wrote: > Hi Phil. >=20 > > Ok. I'd like to help with the ELKS website, and with the > > documentation. But my main interest is to help with > > development of the ELKS code. > > > > I have virtually no experience with the Linux development > > environment, but I do have experience in cross-development > > for embedded microprocessor systems (in DOS and Win32 > > environments) >=20 > You need to remember here that the tools used for ELKS are of > no use for Linux even though they are for the same processor. > This is because ELKS only uses the x86 processors in what is > called "Real Mode" since the 8086 that ELKS is primarily aimed > at has no other mode, whereas Linux uses it exclusively in > "386 Protected Mode" and, whilst the actual opcodes are mainly > the same, the environment they are used in, and the assumptions > the tools need to make, are completely different. >=20 I understand the difference between "Real" mode and "Protected" mode. That is one reason why I have some reservations about mixing "Real" mode development tools into the same directories as the native "Protected" mode tools and libraries. But, as I have seen from recent posts to the ELKS list, it might be worthwhile to add this to the FAQ. I am also also thinking it=20 might be helpful to explain why programming for the x86 "Real" mode=20 is so different from programming for other MMU-less architectures (like the "Dragonball", e.g.).=20 > > I am trying to follow the FAQ in setting up the environment > > so that I can compile the ELKS kernel, but have almost > > immediately run into a problem. > > > > The FAQ is telling me to install the Dev86 package in the > > root (/) directory. I don't want to do this, and I see no > > reason that I should have to. > > > > I would much rather do all of my cross development in my > > home directory, with my standard user privileges, not root > > privileges. I feel this would be much safer, especially > > since I already have some tools installed that have the same > > name as the Dev86 tools. I don't know where they came from, > > and I'd rather not clobber them. >=20 > Have you ever installed the bin86 package? If so, that's an old > version of the dev86 package, and installing the dev86 package > will just install more recent versions of all of the same tools. >=20 Actually, I appear to have dev86-0.15.5 installed. Looks like I installed it as an RPM package about 2 years ago. Is this version=20 too old?=20 Is there an RPM package for the latest version? If not, would there be any interest in having one?=20 I have created some simple RPM packages before, and am also intent on learning how to create Debian packages (when I said I'm "virtually ignorant" above, I was referring to setting up and troubleshooting problems in a GNU tool-chain - I'm usually at a complete loss when things like "make configure", "make dep", and "make" start spewing out errors). > The Linux C compiler is "gcc" and the associated assembler and > loader are "as" and "ld" respectively. The ELKS compiler is "bcc" > and its associated assembler and loader are "as86" and "ld86" > respectively. As a result, it is not possible to interfere with > one by upgrading the tools associated with the other. >=20 > > Is it possible to set up everything in ~/? If so, how > > is it done? What reasons are there for me NOT to do it that > > way? If I can't set up everything in ~/, please explain why? >=20 > >From a purely practical viewpoint, as long as the relevant tools > are in a directory in the PATH environment variable, and no > earlier directory in that variable contains tools with the same > name, it doesn't actually matter where they are. However, it is > NOT a good idea to put a user directory ahead of the system > binary directory. >=20 I've read before that it is a bad idea to put a user directory ahead of the system binary directories, but never an explanation.=20 Why is this a bad idea? Does it have something to do with the possibility of a malicious third-party placing trojans in the user's directories with the same name as a system binary? One of my reasons for wanting to install the tools in my user directory was because I thought that it would be safer than installing code of uncertain origin in the system binary directories. I don't like using root privileges if I don't have to, but I can change my habits if there are compelling reasons to do so. > The standard place to put personal binaries is in the directory > ~/bin with the same directory appended to the END of the standard > PATH variable with an entry of... >=20 > if [ -d ~/bin ]; then > export PATH=3D${PATH}:~/bin > fi >=20 > ...in your ~/.bashrc file. This ensures that the said directory > is only added if it actually existed when you logged on. >=20 My plan was to have a script to set up a different development environment (tool chain) depending what project I wish to work on. Then I normally would not have ~/bin in my PATH except in the one terminal window I'm using for builds. Or maybe, once I understand the GNU toolchain better, I will set things up so that "make configure" or "./configure" will set up macros with the correct paths for each tool? > > I will gladly update the ELKS FAQ with any answers you can=20 > > give me. >=20 > Hopefully, the above will help you. >=20 > Best wishes from Riley. > --- > * Nothing as pretty as a smile, nothing as ugly as a frown. Everything you've provided has been a help. Thank you. Regards, Phil --=-PSp3OflySQIP3MFkXQQk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/KnO/4YdNs+9S3/8RAokZAJ422jLsRfHcYqQOZwnUfU42aqnlFQCfYYbs aOa5l6puU2SS+8X5c/wS+v8= =hEy9 -----END PGP SIGNATURE----- --=-PSp3OflySQIP3MFkXQQk--