RedHat6.1/linux-2.4.4/rtlinux-3.1/emc-1.1-17/libstdc++-2-libc6.1-1-2.9.0 compiled

[Mr F <emclist.user-at-dynolink.org>]

Hi,

I'm an EMC newby.

First I would like to say thank you to everyone who helped make emc
exist!

The following is a loooooong post for those interested in COMPILING emc
with:

RedHat 6.1 (this equals magical (gcc)egcs 2.91.66 and
libstdc++-2-libc6.1-1-2.9.0 combination)
Linux-2.4.4 (needs egcs 2.91.66 but not libstdc++-2-libc6.1-1-2.9.0)
rtlinux-3.1
emc-1.1-17 (is this the latest stable 'release' ???)

I have a 'somewhat' success report! (a preliminary pre-howto for those
interested)
I didn't see this combination mentioned yet. (I have only been reading
the list archives for about a week, searching)
It is newer linux/rtlinux than what  I have noticed mentioned so I'm
posting what I have found out so far.

It now compiles and executes ./emc.run. (still editing the .ini to
overcome 'crash-when-move') as expected, e2fscking ouch!
(remount read only before test solves 5-10 minutes of fs checking after
each crash)
It works on a normal PC and also in vmware! (with rh6.1 installed)
Now to wire up all my stepper HW & do the 'smoke test' :-)

I will preface the whole shebang with a disqualification of my "c" or
"c++" skills, I B ignorant! (never learnt it 2 good)
alough I have been building linux kernels since '95. (just typing 'make'
mostly :-)

My experience is,,,
it compiles and runs after a few edits!
Best I can recollect from memory, a summary  of _WHAT_ is/was required
follows.....

I used a very slightly edited 'install' file _from_ CVS _with_ the
1.1-17 code. ('generic' I think) I added continue y/n after each plat
for semi-controlled abort when you see the error again you recognize,
and an echo of PLAT RTPLAT HOST etc before begin.
(The latest cvs 'install' ASKS what version of rtlinux U have when the
uname|sed stuff fails)
I think this is due to a change in the rtlinux-3.1 and the emc compile
'uname | sed' stuff.
This made the whole rest of the process WAY less painfull than the
default 1.1-17 install file.
Call it 'inst' or something other than 'install' and it survives a
./clean.

during the rcslib build it missed a "mbuff.h" file that I copied over
but I forget where exactly to/from
(error message indicates needed location) use 'locate mbuff.h'(after an
'updatedb' to find the file needed)
You can save a minute or ten by watching for the mbuff.h file not found
error and ^c ing.

in emc/src/emctask I copied in a few files that the .dep is missing (or
missed on my system for some reason)
(canon.hh  emc.hh  inifile.h  interpl.hh  nml_mod.hh  rcs.hh)

I had to make a couple of symbolic links in /usr/src  (quick & dirty)
This seemd to take the least amount of edits
(there are also a couple 2.2 compiler switches set but unharmful (so
far)

I never did make a link to linux from within the rtlinux-3.1 dir, I
guess it found the /usr/src/linux link

untar rtlinux-3.1 in the /usr/src dir and it makes
/usr/src/rtlinux-3.1
then do
ln -s /usr/src/rtlinux-3.1  /usr/src/rtlinux-2.2
ln -s /usr/src/rtlinux-3.1  /usr/src/rtlinux
(make sure to clean in rcslib if this is skipped for even one compile or
it'll never run due to leftovers)

---untar the 2.4.4 kernel into the /usr/src dir AFTER making a directory

mkdir linux-2.4.4-rtl-3.1
mv /usr/src/linux /usr/src/linux.oldsymlink
ln -s /usr/src/linux-2.4.4-rtl-3.1  /usr/src/linux
---untar the 2.4.4 kernel into the /usr/src dir AFTER making a 'mkdir
linux-2.4.4-rtl-3.1' and symlink to linux

ln -s /usr/src/emcin/emc/plat/rtlinux_ 3_1
/usr/src/emcin/emc/plat/rtlinux_
(or edit the .run script and hardcode the RTLINUX=rtlinux_3_1) (another
uname|sed thingy)

additionally I unzipped my emc tarfile into '/usr/src/emcin' so my
/usr/src dir wouldn't get nasty
I only mention this as a few of the flavors of online directions say to
unzip to /usr/src
Fortunately I always do a tar -t before a tar -x  (t=table of contents
x=eXtract)
(always look for any leading "/" in the tar file TOC filenames,
dangerous if not a from trusted binary "package",
and if it's all in a subdir named after the package you can untar
anywhere and move it later if you change your mind)

I had to edit "emc.var" and change the 5220 from 0 to 1 (***found in
FAQ!***)

I decided I was in business when I got the limit exceeded errors during
startup.
I flipped the limit bits in the .ini and I was able then to come out of
stop.

--------            -----------           ----------
---------         ---------
That is about the end of _WHAT_ I did, below a bit more of _HOW_ I
stumbled as far as I did...
(if youre gonna be ignorant, ya gotta be persistant) (dumb/tough)

I am almost sure I can make it work with Slakware 8.0 now that I know it
works with linux-2.4.4/rtlinux-3.1 on redhat61
Just make "egcs" or "gcc" or ???  use libstdc++-2-libc6.1-1-2.9.0 (This
is the default in RedHat 6.1)
This seems to be the key to what distribution version it currently works
with.
I'll bet $0.05 that RedHat has an old egcs rpm that would solve most of
the current  distribution version compiler issues.
Just install the new 'old' compiler and libs to a new dir that is sooner
on your PATH than /usr/bin (usr/local/bin)
After compile U blow away the end of the usr/local/bin dir if the space
is needed. (lower risk of no return)

I _THINK_ all that is needed on a egcs 2.91.66 using newer libs is the
correct "-L/usr/lib -lstdc++"  linker command (plus the  "-2-" file(s)).

and/or some creative file renaming and symlinks (plus the "-2-" version
libstdc++ file)
I was able to get rid of all symbol missing errors, but I had also made
too many other 'edits' at that point.

I suspect the only changes needed for -3-libc6... compile are minor
edits to the rcslib.
I was making great progress when I decided to try redhat. (this has it's
own challenges for a slakware/fvwm2 zealot :-)
All I had to do to get it to compile _more_ was get rid of some more
comment syntax errors.
They _ONLY_ produce 'warnings' but the rest of the syntax/logic fails a
few lines later as a result.
(they were all comments at the end of "c++" code lines using '//') I
hope to find a/the preprocessor switch that 'fixes' it.
(or learn more about sed)

I was as far as having it compile without error and run the sim with the
latest CVS gcc  when I decided to try a redhat install just to see what
c++ libraries were there.  I may have even had it right once, before I
read about the .var file crash edit.
I was definately loading steppermod.o at one point but failing later....
(it's all a blur now)
When all else fails follow the instructions. (I know I coulda just
looked up the RH6.1 info too)

The main thing I did to speed progress with gcc-2.95.3 was to add/edit a
file /etc/modules.conf with path statements to add the  emc/rcs lib and
modules to the depmod search path.

(example of a possible /etc/modules.conf)
path[rtl]=/usr/rtlinux-3.1/modules
path[emc]=/usr/src/emcin/emc/plat/rtlinux_3_1/lib
path[rcslib]=/usr/src/emcin/rcslib/plat/rtlinux_3_1/lib
(the sim stuff always runs fine so I stay away from the nonrealtime plat
dirs (head in sand))

Then after a clean looking compile do a 'depmod -e' and you will _know_
(silence is golden)
It is much faster than the dreaded e2fsck after a crash.
(I think I've had more crashes in a week than in all of 5+ years running
linux)

I started out with "__udivdi3" and "__umoddi3" unresolved symbols when
steppermod.o executed.
Being ignorant of "c" I grepped the emc dirs for "di3" nuthin.....
hmmmmmm
(the double underscore is the dead giveaway that  I totally missed here)

So I tried the grep on the kernel tree. The only references were in some
"arch/xxx" dirs and not the arch/i386....hmmmmmm
So I turned grep loose on the whole disk. (and did something else for a
couple of hours)
Inside a MySQLx.x.x.x text file it found a reference and a line #. (plus
a lot of binaries containing same)
(use "grep -rn di3 /*" and it will recurse all files and dirs and report
line numbers of every instance of 'di3' on the disk)
All the file said about the errors was to use gcc 2.95.2 (I had already
tried that (c++ syntax puke), but not old libs.)
There were other always relevant/good juicy compiler error fixes in
there so I read around a bit.
I found some reference to the "-L" and "-l"(ell) compiler link switches,
and I was off to the rodeo!!!
I had the emcmot stuff failing only on cos,sin symbols at one point.
(created procmath issues in rcslib)
So now I plan finding the rcslib linker switches to force my intentions.

It is also possible that there are just some comment syntax changes
needed in the posemath c++ stuff and
it will build with the newer compiler/libstdc++-3 . I was making good
progress but working in too many directions at once.
All I was doing was removing comments at the end of lines that the newer
gcc cpp didn't like in rcslib and it was movin on.

So _my_ plan A is to work towards the new(er/est) compiler/lib and use
newest stable codebase using full cpu optimizations.
The rtlinux mkdep is based on kernel files, _and_ the kernel uses egcs
2.91.66. The answer lies within...
FYI Slak8 has 2 compilers installed, a new one(2.95.3) and an old
egcs(2.91.66) just for makin kernels...but not the right lib

Now for a few questions!!!
What cvs date is a good/better/best candidate? latest??? How bleeding
edge is it???
Is the 'rtlinux' specific part semi-static yet? (posemath & emcmot)
What is the/a cvs command to see a changelog? Would I find the info I
seek there?
(I tried, but I'm no cvs 'roo)
I'll make a cvs diff file relative to cvs1.1-17 for the dropbox after I
test out bits on pport. (no time promise)
What will a cvs release of Jan. 17, 2002 (for instance) be named
2.1-17??? or is the first 1 a 'version' #

Once again I would like to thank everyone involved in emc!

As always, 'your mileage may vary'

emc.er
\_at_/
dynolink.org