Re: ELKS Development/FAQ Questions

[Phil Goembel <phil-goembel@wi.rr.com>]

[-- 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 --]