05 Nov 16 17:56, you wrote to me:

 ml>> instead of dynamic... IIRC, paul's build of crashmail 0.71 is built
 ml>> static... file will tell you that if you haven't looked already...

 RC> ummm...$ file ~/crashmail-0.71/bin/crashmail
 RC> /home/rec9140/crashmail-0.71/bin/crashmail: ELF 64-bit LSB  executable,
 RC> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
 RC> GNU/Linux 2.6.24, BuildID[sha1]=27de05981b233984f8ca78c8af4a3d4113d0bd2b,
 RC> stripped

 RC> This shows *dynamically linked (uses shared libs),*

i thought i had seen him say that he compiled something static... oh well... i
didn't go hunting for that post in my bases...

 RC> Guess that is 64b, which is why it runs.. as its "ELF 64-bit LSB" ...
 RC> I don't now... too many things I've looked at...

yes, that's what it says above... i guess you'll know in time if that ace up
your sleeve was really the ace you thought it was...

 ml>> i'm not one of those monkeys either... never have been but i can
 ml>> mostly muddle my way through when necessary... like when i fixed a
 ml>> couple of bugs and added some features to my private build...

 RC> Well unfortunately I know a lot, A LOT more C than I care to admit..
 RC> simply because of lot of things I'd rather not remember....



 RC> I am looking as posted in ehco and the bug report to "fake out" PAN
 RC> and KNode to work with JamNNTPd.. but I need to make sure I've
 RC> resolved any potential of this nonsense in re the corruption of JAM
 RC> bases because of the 32b v. 64b issues..

do we even know if it was an alignement problem yet? no... all we know is that
you were seeing corruption but there's been no detailed analysis of the data
files AFAIK... "detailed analysis" as in studying them under a hex viewer or
similar...

 RC> Thats the point in asking is the SF site and 1.3 good??? No, its
 RC> flawed like post 071 CM II's or if the resolution of an option to
 RC> force m32 solves this.. or only the code form the eljaco.se site
 RC> should be messed with???

i've already stated that i'm running a modified 32bit 1.2 compile over here on
my main system... the one you were using... my main system is/was a beta site
for JAM when it was first introduced... if there's corruption i definitely know
 about it... especially with retaining posts for as long as i do...

 RC> I've put several ideas on faking out PAN/KNode... I just need to find
 RC> a decent c interpreter to play with... its not a project I want to
 RC> take on, but I am forced to.. as using thunderturkey just crankles me
 RC> to no end....

i've used pine, slrn, and similar with no problems... i've never tried knode or
 pan... don't intend to, either... i'm trying to remember the python one i used
 that allowed me to find and fix a bug or two... ahhh... XPN 1.2.6...

 ml>> who needs a real iron clunker when one can run a VM? 

 RC> Unfortunately you can't  virtualize SDR sticks or Line in's for audio.. so
 RC> real hardware at times is what it takes....

who needs an sdr or sound card on a fidonet system?

 RC> Plus I dislike throwing out perfectly working hardware that might need
 RC> a little TLC to upgrde a CPU, max out some RAM or a bigger HD.. and
 RC> then turn it into a VM host for somethings, or run LXC containers, or
 RC> VPN server or .....

 RC> But for the RTL-SDR stuff and some other stuff I am invoved in, I need
 RC> hardware to plug it into.. SDR doesn't work good, no at all under VMWare,

yech... have you tried QEMU/KVM? that's all i use...

 RC> and it has much better USB support than the love child of the Linux
 RC> crowd.. thats why VMWare is my goto VM for anything production.. test
 RC> and play with any thing from VMW to LXC..

oh well :shrug:

 ml>> i'd be really surprised if these packages can be compiled on ARM
 ml>> systems... especially jamnntpd since there's only linux, os2 and
 ml>> win32 headers...

 RC> ARMHF for the PI's probably is not a problem as the Pi's are still
 RC> using 32b.. the Pi3 is or can be 64b, but Raspbian or something was
 RC> not set up that way.. or.. I didn't keep up with it... Raspbian has
 RC> issues in re Jessie and systemd.... justlike post 14.x *buntus...

i understand that they're using a 32bit OS only because there's only 1Gig of
RAM on the things... i've thought about getting one to play with but 1Gig is
not enough for the projects i have in mind... 2Gig is just barely adequate...

 RC> I'd have to find some spare PI's first.. these get gobbled up for
 RC> projects quick!

:lol:

 ml>> i'd be concerned about the switching from unsigned variables to
 ml>> signed ones...

 RC> I don't know.. what was changed...

i specifically looked and read the diff...

 RC> I just know I found it interesting that it showed up, and
 RC> was/is/possibly a result of this whole mess with what ever happened
 RC> past the 071 version..  based on that 64b support... I didn't go any
 RC> further than bookmark it... for later review... its just something
 RC> thats out there...but dormant too.

there's a lot out there... quite a few people have repos where they are working
 on the code and then contributing their work back to a central repo... that's
why your stupid comment about having 1.3 removed from SF was well... stupid...
and people let you know about it... you don't go taking someone else's hard
work away like that when you don't know the condition or even why it is like it
 is... there are choices in life and using ancient broken binaries from some
distribution's repo or pulling newer sources from another repo and compiling
yourself is just part of the linux world... apparently you've been sheltered in
 that respect... that's not a bad thing but it sure is a wake up call, as
you've found out, when you step off into other worlds that are definitely
hobbiest oriented... welcome to the club! maybe you can help in getting some
other things updated and fixed but the first step is seeing the land for what
it really is 

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Law of Combat: No inspection-ready unit has ever passed combat.
---
 * Origin:  (1:3634/12.73)