* Web language codes @ 2003-07-24 19:58 Riley Williams 2003-07-31 0:33 ` ELKS Development/FAQ Questions Phil Goembel 0 siblings, 1 reply; 9+ messages in thread From: Riley Williams @ 2003-07-24 19:58 UTC (permalink / raw) To: Linux ELKS Hi all. I have just added Functions/languages.php to the elksweb2 CVS tree. This is a translation list translating the codes used for various languages into the English names for those languages, implemented as a PHP declaration of an array called $language and ready for use by those wishing to add definitions for any other web pages. At least, I *HOPE* this is valid PHP code. It is based on the code in Functions/data.php but I have to admit that I'm nowhere near being an expert on PHP so I could easily have made some serious mistake in creating this page. Any advice appreciated. Best wishes from Riley. --- * Nothing as pretty as a smile, nothing as ugly as a frown. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 18-Jul-2003 ^ permalink raw reply [flat|nested] 9+ messages in thread
* ELKS Development/FAQ Questions 2003-07-24 19:58 Web language codes Riley Williams @ 2003-07-31 0:33 ` Phil Goembel 2003-07-31 6:01 ` Riley Williams 0 siblings, 1 reply; 9+ messages in thread From: Phil Goembel @ 2003-07-31 0:33 UTC (permalink / raw) To: Linux ELKS [-- Attachment #1: Type: text/plain, Size: 1252 bytes --] 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) 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. 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? I will gladly update the ELKS FAQ with any answers you can give me. Respectfully, Phil [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 0:33 ` ELKS Development/FAQ Questions Phil Goembel @ 2003-07-31 6:01 ` Riley Williams 2003-07-31 9:56 ` Raghavan 2003-08-01 14:05 ` Phil Goembel 0 siblings, 2 replies; 9+ messages in thread From: Riley Williams @ 2003-07-31 6:01 UTC (permalink / raw) To: Phil Goembel, Linux ELKS Hi Phil. > 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) 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. > 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. 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. 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. > 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? 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. 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... if [ -d ~/bin ]; then export PATH=${PATH}:~/bin fi ...in your ~/.bashrc file. This ensures that the said directory is only added if it actually existed when you logged on. > I will gladly update the ELKS FAQ with any answers you can > give me. Hopefully, the above will help you. Best wishes from Riley. --- * Nothing as pretty as a smile, nothing as ugly as a frown. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 6:01 ` Riley Williams @ 2003-07-31 9:56 ` Raghavan 2003-07-31 21:30 ` Phil Goembel 2003-08-01 14:19 ` Phil Goembel 2003-08-01 14:05 ` Phil Goembel 1 sibling, 2 replies; 9+ messages in thread From: Raghavan @ 2003-07-31 9:56 UTC (permalink / raw) To: Riley Williams, Phil Goembel, Linux ELKS Phil, I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my Home directory as a part of making ELKS 1.1 I installed it in ~/ELKS/my_install directory. I had to mention that this was where I wanted to install in my Makefile ( or one of its related config file ) while building the dev86. The, I did a 'make install'. After that , I tweaked PATH as follows to make it see my bcc before the system'c bcc which was there in /usr/bin or /usr/local/bin.. PATH=$HOME/ELKS/my_install/bin:$PATH After that I built ELKS , It just worked fine. No Issues at all. bye, rags ----- Original Message ----- From: "Riley Williams" <Riley@Williams.Name> To: "Phil Goembel" <phil-goembel@wi.rr.com>; "Linux ELKS" <Linux-8086@vger.kernel.org> Sent: Thursday, July 31, 2003 11:31 AM Subject: Re: ELKS Development/FAQ Questions > Hi Phil. > > > 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) > > 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. > > > 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. > > 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. > > 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. > > > 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? > > 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. > > 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... > > if [ -d ~/bin ]; then > export PATH=${PATH}:~/bin > fi > > ...in your ~/.bashrc file. This ensures that the said directory > is only added if it actually existed when you logged on. > > > I will gladly update the ELKS FAQ with any answers you can > > give me. > > Hopefully, the above will help you. > > Best wishes from Riley. > --- > * Nothing as pretty as a smile, nothing as ugly as a frown. > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003 > > - > To unsubscribe from this list: send the line "unsubscribe linux-8086" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 9:56 ` Raghavan @ 2003-07-31 21:30 ` Phil Goembel 2003-07-31 21:41 ` Paul Nasrat 2003-08-01 14:19 ` Phil Goembel 1 sibling, 1 reply; 9+ messages in thread From: Phil Goembel @ 2003-07-31 21:30 UTC (permalink / raw) To: Raghavan, Riley Williams; +Cc: Linux ELKS [-- Attachment #1: Type: text/plain, Size: 5622 bytes --] Raghavan and Riley, Thanks to both of you for responding to my questions. I will start thinking of the best way to add this information to the ELKS website. Of course I will make sure it's not already there, since I seem to have a knack for reading the documentation two or three times before finding what I'm looking for. Be prepared for more questions shortly. What I need right now, I think, is for one of the ELKS SourceForge project administrators to give me developer access to at least the website part of the CVS archive. My SourceForge username is pgoembel. Raghavan and Riley for On Thu, 2003-07-31 at 04:56, Raghavan wrote: > Phil, > > I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my > Home directory as a part of making ELKS 1.1 > > I installed it in ~/ELKS/my_install directory. I had to mention that this > was where I wanted to install in my Makefile ( or one of its related config > file ) while building the dev86. > The, I did a 'make install'. > > After that , I tweaked PATH as follows to make it see my bcc before the > system'c bcc which was there in /usr/bin or /usr/local/bin.. > > PATH=$HOME/ELKS/my_install/bin:$PATH > > After that I built ELKS , It just worked fine. No Issues at all. > > bye, > rags > > ----- Original Message ----- > From: "Riley Williams" <Riley@Williams.Name> > To: "Phil Goembel" <phil-goembel@wi.rr.com>; "Linux ELKS" > <Linux-8086@vger.kernel.org> > Sent: Thursday, July 31, 2003 11:31 AM > Subject: Re: ELKS Development/FAQ Questions > > > > Hi Phil. > > > > > 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) > > > > 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. > > > > > 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. > > > > 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. > > > > 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. > > > > > 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? > > > > 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. > > > > 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... > > > > if [ -d ~/bin ]; then > > export PATH=${PATH}:~/bin > > fi > > > > ...in your ~/.bashrc file. This ensures that the said directory > > is only added if it actually existed when you logged on. > > > > > I will gladly update the ELKS FAQ with any answers you can > > > give me. > > > > Hopefully, the above will help you. > > > > Best wishes from Riley. > > --- > > * Nothing as pretty as a smile, nothing as ugly as a frown. > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003 > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-8086" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-8086" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 21:30 ` Phil Goembel @ 2003-07-31 21:41 ` Paul Nasrat 0 siblings, 0 replies; 9+ messages in thread From: Paul Nasrat @ 2003-07-31 21:41 UTC (permalink / raw) To: Phil Goembel; +Cc: Raghavan, Riley Williams, Linux ELKS On Thu, Jul 31, 2003 at 04:30:51PM -0500, Phil Goembel wrote: > What I need right now, I think, is for one of the ELKS SourceForge > project administrators to give me developer access to at least the > website part of the CVS archive. My SourceForge username is pgoembel. You can check out from pserver and submit patches - that's usually a good start. It's the elksweb module. CVSROOT=:pserver:anonymous@cvs.elks.sf.net:/cvsroot/elks It's a day behind but elks isn't really a moving target :) Paul ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 9:56 ` Raghavan 2003-07-31 21:30 ` Phil Goembel @ 2003-08-01 14:19 ` Phil Goembel 1 sibling, 0 replies; 9+ messages in thread From: Phil Goembel @ 2003-08-01 14:19 UTC (permalink / raw) To: Raghavan; +Cc: Riley Williams, Linux ELKS [-- Attachment #1: Type: text/plain, Size: 1041 bytes --] Hi Rags, Thank you. This is what I want to do. I will take a look at the Makefile for dev86 to see how to specify the install directory. I assume I will have to do one or more of these things: a. edit the Makefile, b. set an environment variable, c. or pass an argument to the make command Is that correct? Regards, Phil On Thu, 2003-07-31 at 04:56, Raghavan wrote: > Phil, > > I got the dev86 sources (dev86-0.16.1 ), built it and installed it in my > Home directory as a part of making ELKS 1.1 > > I installed it in ~/ELKS/my_install directory. I had to mention that this > was where I wanted to install in my Makefile ( or one of its related config > file ) while building the dev86. > The, I did a 'make install'. > > After that , I tweaked PATH as follows to make it see my bcc before the > system'c bcc which was there in /usr/bin or /usr/local/bin.. > > PATH=$HOME/ELKS/my_install/bin:$PATH > > After that I built ELKS , It just worked fine. No Issues at all. > > bye, > rags > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ELKS Development/FAQ Questions 2003-07-31 6:01 ` Riley Williams 2003-07-31 9:56 ` Raghavan @ 2003-08-01 14:05 ` Phil Goembel 2003-08-01 22:42 ` Riley Williams 1 sibling, 1 reply; 9+ messages in thread From: Phil Goembel @ 2003-08-01 14:05 UTC (permalink / raw) To: Riley Williams; +Cc: Linux ELKS [-- Attachment #1: Type: text/plain, Size: 5713 bytes --] Hi again Riley, Thanks for taking the time to reply. On Thu, 2003-07-31 at 01:01, Riley Williams wrote: > Hi Phil. > > > 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) > > 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. > 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 might be helpful to explain why programming for the x86 "Real" mode is so different from programming for other MMU-less architectures (like the "Dragonball", e.g.). > > 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. > > 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. > 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 too old? Is there an RPM package for the latest version? If not, would there be any interest in having one? 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. > > > 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? > > >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. > 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. 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... > > if [ -d ~/bin ]; then > export PATH=${PATH}:~/bin > fi > > ...in your ~/.bashrc file. This ensures that the said directory > is only added if it actually existed when you logged on. > 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 > > give me. > > Hopefully, the above will help you. > > 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: ELKS Development/FAQ Questions 2003-08-01 14:05 ` Phil Goembel @ 2003-08-01 22:42 ` Riley Williams 0 siblings, 0 replies; 9+ messages in thread From: Riley Williams @ 2003-08-01 22:42 UTC (permalink / raw) To: Phil Goembel; +Cc: Linux ELKS Hi Phil. > Thanks for taking the time to reply. NP. >>> 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) >> 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. > 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. There's actually no reason to have reservations about that, as it's no more of a problem than having the binaries for ftp and telnet in the same directory - both are protocols used over the Internet, but have major differences from each other. > 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 thinking it might > be helpful to explain why programming for the x86 "Real" mode is > so different from programming for other MMU-less architectures > (like the "Dragonball", e.g.). There could certainly be reasons for adding a pointer to one of the many excellent websites about the differences between the real and protected modes on the x86 family of processors, but I can't see any reason for rewriting what's already out there. >>> 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. >> 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. > 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 > too old? That's newer than the version I'm using - I show dev86-0.15.0-2 here, a Red Hat Linux 6.2 based system with most updates already applied. > Is there an RPM package for the latest version? I'm just checking ftp://updates.redhat.com/6.2/en/os/ to see whether any updates show thereon - OK, none showing, so presumably nothing on Red Hat's site. I'm not sure offhand where the dev86 development site is, but there's almost certainly an RPM for the latest version there. > 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). That is understandable. >> 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. >>> 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? >> 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. > 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. > 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? Not even that - simply as a result of ignorance, it's possible to create a program with the same name as a standard program. If you have the PATH with ./bin in front of the system directory with that standard command in it, then ANY standard shell script that makes use of the said command will accidentally use your version rather than the standard one. As an example of how widespread this is, I just ran the following on my development system... file /usr/bin/* | fgrep -iw script ...and found 285 shell scripts in that one system binary directory... > 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. As far as the dev86 package is concerned, the only reason to have more than one copy of it installed on your system is if you are helping to debug the existing version and create a new version. >> 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... >> >> if [ -d ~/bin ]; then >> export PATH=${PATH}:~/bin >> fi >> >> ...in your ~/.bashrc file. This ensures that the said directory >> is only added if it actually existed when you logged on. > 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 tool chain better, I > will set things up so that "make configure" or "./configure" > will set up macros with the correct paths for each tool? I have to admit that sounds like a lot of work for next to no gain to me, but you know your setup better than I ever can... >>> I will gladly update the ELKS FAQ with any answers you can >>> give me. >> Hopefully, the above will help you. > Everything you've provided has been a help. Thank you. Thanks for that. Best wishes from Riley. --- * Nothing as pretty as a smile, nothing as ugly as a frown. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.505 / Virus Database: 302 - Release Date: 30-Jul-2003 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-08-01 22:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-24 19:58 Web language codes Riley Williams 2003-07-31 0:33 ` ELKS Development/FAQ Questions Phil Goembel 2003-07-31 6:01 ` Riley Williams 2003-07-31 9:56 ` Raghavan 2003-07-31 21:30 ` Phil Goembel 2003-07-31 21:41 ` Paul Nasrat 2003-08-01 14:19 ` Phil Goembel 2003-08-01 14:05 ` Phil Goembel 2003-08-01 22:42 ` Riley Williams
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.