Linux-Development-Sys Digest #99, Volume #7 Tue, 24 Aug 99 07:13:57 EDT
Contents:
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: Reverse engineer of serial protocol or Ericsson SH888 (Grahame M. Kelly)
Re: C++ templates: More than Turing Complete? (Davin McCall)
Re: glibc-2.1.1 problems (Mike Dowling)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
("Noam K")
Re: TAO: the ultimate OS ("[EMAIL PROTECTED]")
Re: TAO: the ultimate OS (Donal K. Fellows)
Re: glibc-2.1.1 problems (Andreas Jaeger)
----------------------------------------------------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Aug 1999 06:41:17 GMT
In comp.os.misc John Simpson <[EMAIL PROTECTED]> wrote:
: Could you please provide a brief "diff" between this post and your
: previous posts on "TAO" so that those of us who lived through the last
: flamage don't have to go through it all again. Thanks.
wow, an oldtimer in cyberspace. I think I posted about 60 days
ago or something like that. the mind reels that anyone
can remember that far back.
to be honest, the essay is not different. but then again, neither is the
current commercial/open OS landscape. <g>
the main reason I am reposting is to announce my mailing list
for interested contributors.
btw, what would be the problem with going through all the flamage
again? I enjoyed it a lot. haha
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: [EMAIL PROTECTED] (Grahame M. Kelly)
Subject: Re: Reverse engineer of serial protocol or Ericsson SH888
Date: 24 Aug 1999 05:49:21 GMT
> In article <[EMAIL PROTECTED]>,
> Nigel Tamplin <[EMAIL PROTECTED]> writes:
>> Hi,
>>
>> Some months ago I came across a discussion where someone was capturing
>> the
>> serial data between a Windows machine and the scanner so that they could
>> reverse engineer the protocol.
>>
>> I would like to know how this is done.
>>
>
I am presently reverse engineering a connection between my Win98 and
Nikon E950 camera to try and work out what needs to be added by the
gPhoto group to get Nikon E950 Coolpix to work correctly on Gphoto.
I found that I had to make a buffered RS232 device to over come
line noise and ground loop problems when I originally just connected
the RS232 Tx lines to two Rx lines.
You only need 1 x 1488 IC, and 1 x 1489 IC (about $1) and a
+5, +12 and -12dc power (I used a old PC PSU with a old
harddisk as a PSU load device - as 2 IC are not enough load
on a switching power supply.
Anyhow, I have made a double buffered RS232 device as follows;
a> Transmit from Camera goto a 1489 (RS232 to TTL logic) gate (pin 1),
output (pin 3) of this gate goto a 1488 (TTL to RS232 logic driver, pin 1),
which in turn its output (pin 3) connects to the Win98 computer RS232 (Com1)
recieve pin (2).
b> Transmit from Win98 RS232 device (pin 3) goto another 1489 gate (pin 4),
output (pin 6) of which is connected to another 1488 (pin 13 & 12)
which in turn its output (pin 11) is connected to the Camera Recieve pin.
c> Camera and Computer RS232 device (pin 5) are connected to
each other as usual.
d> I have a wire from Camera (a.k.a Tx 1489 output in <a> pin 3)
connecting to another RS232 driver section of a 1488 IC (pin 4 & 5).
The output of this driver (pin 6) is
feed to another computer (Linux) RS232 port (say /dev/ttyS0)
DB9 pin 2.
e> Wire from Win98 Com1 port (a.k.a Tx 1489 output in <b> pin 6)
connecting to another RS232 driver 1488 IC section (pins 9 & 10)
whos output (pin 8) is feed to the Linux computer DB9 (pin 2) of
port /dev/ttyS1.
f> Linux ports /dev/ttyS0 & ttyS1 DB9 pin 5 are connected to Camera
and Win98 RS232 DB9 pin 5 as well (i.e. Common Ground).
(Get a IC layout of a 1488 & and a 1489 IC and I am sure you can follow
my points a to f above).
Now I simply set up one minicom terminal monitoring and capturing
data from Camera to Win98 (i.e. /dev/ttyS0) and another minicom
terminal monitoring the Win98 to Camera (i.e. /dev/ttyS1) communications.
I capture all monitored activity to different log files e.g. /tmp/camera
and /tmp/w98. I then do "hexdump /tmp/camera" to see a hex dump of the
information sent from the camera and "hexdump /tmp/w98" to see the
corresponding command data from Win98 driver/application. You can easily
build your own hexdump format file to customise your own debugging and
reverse engineering needs (a.k.a man hexdump).
As it is no longer illegal in Australia to reverse engineer s/w and
hardware devices, I going to get as many of my devices running under
Linux and piss off Win95/98/00. Viva'la'Linux difference.
Once, I have got past this point, its on to the parallel port and
the SANE debugging / reverse engineering of my HP1100A scanner
(well I can dream can't I :)
Hope this helps,
Cheers, Grahame
--
==============================================
Anti-Spamming Enabled in FQDN.
Email: gmkelly (at) zip (dot) com (dot) au
Sydney Linux User Group - Member
http://www.slug.org.au
==============================================
------------------------------
From: [EMAIL PROTECTED] (Davin McCall)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: C++ templates: More than Turing Complete?
Date: Tue, 24 Aug 1999 07:54:05 GMT
On Mon, 23 Aug 1999 20:43:15 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote:
> No, it's a defect in the example. If templates are Turing complete, it
>is theoretically possible to create examples of C++ code that, while
>legal, can never be compiled into valid code because the existence of
>the valid code would be logically equivalent to a proof that the
>compilation could not terminate.
I think you misunderstood what I was saying. The example may be
defective (if what you say is true, the example *is* defective), I
haven't yet disagreed with the principle it was trying to demonstrate,
only pointed out the problem with the example itself...
> It's kind of like the equivalent of, "Though this sentence is true, you
>will never realize it." Obviously, you can never realize that that
>sentence is true (because if you did, you'd have proven that you
>couldn't). But since that's what it says, it _is_ true, right? Oh, wait,
>...
...Paradox. I am also familiar with the halting problem.
> If C++ is turing complete, it should be possible to construct similarly
>self-referencial pieces of code. They would be syntactically valid.
>Obviously, they could not be compiled.
Could you do so? (I'd just like to see such a piece of code out of
interest, it's not that I doubt you; I'm not even sure what "turing
complete" means).
Davin.
__________________________________________________________
*** davmac - sharkin'!! [EMAIL PROTECTED] ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
------------------------------
From: [EMAIL PROTECTED] (Mike Dowling)
Subject: Re: glibc-2.1.1 problems
Date: 24 Aug 1999 08:45:07 GMT
On 21 Aug 1999 16:00:14 GMT, Mike Dowling <[EMAIL PROTECTED]> wrote:
>I have two computers. Strangely, when I upgraded to glibc-2.1.1 on one of
>them (a pentuim II), I experienced only teething problems. On the other, a
>Pentium, I'm having major problems.
Let me explain in more detail.
With the Pentium II, glibc-2.1.1 compiled and installed without
difficulty. It did break a handful of binaries, notably emacs, perl,
ssh2, archie, and hostname. In each case, the solution was merely to
re-compile the sources. The sole exception was archie, which is
probably antiquated anyway. (Archie fails with the error message
archie failed: Recvfrom failed (dirsend).)
On the Pentium PC, I even had problems compiling glibc. For a start,
the configure script usually could not discern the type of system I had,
so I had to include --host=i586-pc-linux-gnu as a parameter to the
configure script. When this happened, the sources would compile, but
the "make install" failed. Here is the relevant excerpt from the "make
install" output:
make -C elf ldso_install
make[2]: Entering directory `/usr/src/glibc-2.1.1/elf'
/bin/install -c /usr/src/glibc-build/elf/ld.so /lib/ld-2.1.1.so.new
mv -f /lib/ld-2.1.1.so.new /lib/ld-2.1.1.so
rm -f /lib/ld-linux.so.2
ln -s ld-2.1.1.so /lib/ld-linux.so.2
make[2]: ln: Command not found
make[2]: *** [/lib/ld-linux.so.2] Error 127
make[2]: Leaving directory `/usr/src/glibc-2.1.1/elf'
make[1]: *** [elf/ldso_install] Error 2
make[1]: Leaving directory `/usr/src/glibc-2.1.1'
make: *** [install] Error 2
Well, it is obvious why that failed, but it is less obvious to me how to
fix the problem. This happens immedaitly after make has determined that
there is nothing left to be made, and so begins the installation
process, so when it fails, only ld-2.1.1.so has been installed. I
suspect strongly that this install failure and the failure to determine
the system type are linked.
I have tried to compile and install glibc-2.1.1 on the Pentium many
times, and, inexplicably, on rare occasions the configure script *could*
determine the system type. Attempts at reproducing this behaviour have
still failed to indicate what exactly I do differently to get the
different behaviour. (It does not happen often enough for experimention
to be effective.) Nevertheless, when the configure script correctly
determines the system type, the "make install" continues to what appears
to be almost its conclusion. All (as far as I can tell) of the
libraries are installed before the "make install" crashes with something
like
test ! -x /usr/src/glibc-build/elf/ldconfig | l \
/usr/src/glibc-build/elf/ldconfig -d /lib /usr/lib
whereupon I get the error message
/bin/sh: error loading shared libraries:
/bin/sh: undefined symbol: __setfpucw
At this stage, almost every binary is broken. Almost every binary
produces this "undefined symbol: __setfpucw" error, and exits.
According to the FAQ, effects like this can be expected if the
ld_linux.so and the version of glibc do not tally, but in my case they
do.
Unfortunately, when this happens, there is nothing I can do but to
restore the system to its pristine state. Fortunately, I took the
precaution of backing up my system on a MO device from which I can boot,
and copy the old system back again. I cannot re-compile all the
binaries on the system even if I had the time and inclination; among
other binaries that fail, make does as well, thereby making it
impossible to compile anything.
At the moment, the only solution that I can think of, and I am very
reluctant to do it, is to buy a new Pentium II computer for private use,
replacing the Pentium, and to copy the entire system from my office
computer, the Pentium II. (I backed up the Pentium II system after
installing glibc-2.1.1, and, on booting the backup from the Pentium, I
could demonstrate that the Pentium binaries are indeed not compatible
with the Pentium architecture.)
A second alternative might be to give up doing everything myself, and to
start using some distribution. I regard this as being almost as time
consuming as doing everything myself, as I am unlikely to be very
satisfied with any distribution, and so would inevitably had to start
customising everything.
Therefore, any suggestions would be gratefully and thankfully
appreciated.
Cheers,
Mike Dowling
--
My email address [EMAIL PROTECTED] above is a valid email address.
It is, in fact, a sendmail alias; the digit 'N' is incremented regularly.
Spammed aliases will be deleted. Currently, mike[5,7-9,12,13,16] have been
deleted. If email to mikeN bounces, try mikeN+1.
------------------------------
From: "Noam K" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Sun, 22 Aug 1999 23:32:10 +0300
Ulrich Weigand wrote in message
<7ppc7p$[EMAIL PROTECTED]>...
>Provided you use binutils version 2.9.1 or later, there is a way around
>this: you can 'localize' symbols using the objcopy -L flag, which means
>the symbol is treated from now on as if it were local (had been declared
>'static' in C).
>
>So, you link all your library objects together into one big .o file
>(using ld -r or so), apply objcopy -L to localize all symbols you
>don't want to export, and then create the shared object from the
>resulting .o file ...
>
>While this is somewhat convoluted, it should work :-/
>
>--
> Ulrich Weigand,
> IMMD 1, Universitaet Erlangen-Nuernberg,
> Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
Thanks Ulrich, this works great!
Noam
------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Tue, 24 Aug 1999 10:45:09 +0100
Reply-To: [EMAIL PROTECTED]
"Vladimir Z. Nuri" wrote:
>
> an HTML version of this article can be found at:
>
> http://www8.pair.com/mnajtiv/tao.html
>
Please don't post this to comp.os.linux.advocacy (I personally don't think
it's appropriate for any Linux group).
And, if you do post to more than 2 groups at least set your followups so
all the replies don't go to all the groups you posted to. This will also
prevent the inevitable replies that include your entire message because
many people have no idea how to use their newsreaders to edit replies these
days.
Doesn't anyone follow usenet etiquette anymore?!? It's not difficult and
takes only a little common sense.
followups set to comp.os.misc
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Aug 1999 10:07:15 GMT
In article <7ps2vu$[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
> the ultimate OS
Not again! Please, everyone, read the last incarnation of this thread
(same title) on www.deja.com first so you can understand the deep
reservations held by many on this topic (and this author!) <massive
sigh>
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1.1 problems
Date: 24 Aug 1999 11:59:32 +0200
>>>>> Mike Dowling writes:
Mike> On 21 Aug 1999 16:00:14 GMT, Mike Dowling <[EMAIL PROTECTED]>
wrote:
>> I have two computers. Strangely, when I upgraded to glibc-2.1.1 on one of
>> them (a pentuim II), I experienced only teething problems. On the other, a
>> Pentium, I'm having major problems.
Mike> Let me explain in more detail.
Mike> With the Pentium II, glibc-2.1.1 compiled and installed without
Mike> difficulty. It did break a handful of binaries, notably emacs, perl,
Mike> ssh2, archie, and hostname. In each case, the solution was merely to
Mike> re-compile the sources. The sole exception was archie, which is
Mike> probably antiquated anyway. (Archie fails with the error message
Mike> archie failed: Recvfrom failed (dirsend).)
Mike> On the Pentium PC, I even had problems compiling glibc. For a start,
Mike> the configure script usually could not discern the type of system I had,
Mike> so I had to include --host=i586-pc-linux-gnu as a parameter to the
Mike> configure script. When this happened, the sources would compile, but
You can run config.guess by hand or with sh -xv to see what goes
wrong. I advise to resolve this first.
Mike> the "make install" failed. Here is the relevant excerpt from the "make
Mike> install" output:
Mike> make -C elf ldso_install
Mike> make[2]: Entering directory `/usr/src/glibc-2.1.1/elf'
Mike> /bin/install -c /usr/src/glibc-build/elf/ld.so /lib/ld-2.1.1.so.new
Mike> mv -f /lib/ld-2.1.1.so.new /lib/ld-2.1.1.so
Mike> rm -f /lib/ld-linux.so.2
Mike> ln -s ld-2.1.1.so /lib/ld-linux.so.2
Mike> make[2]: ln: Command not found
Mike> make[2]: *** [/lib/ld-linux.so.2] Error 127
Mike> make[2]: Leaving directory `/usr/src/glibc-2.1.1/elf'
Mike> make[1]: *** [elf/ldso_install] Error 2
Mike> make[1]: Leaving directory `/usr/src/glibc-2.1.1'
Mike> make: *** [install] Error 2
Mike> Well, it is obvious why that failed, but it is less obvious to me how to
Mike> fix the problem. This happens immedaitly after make has determined that
Mike> there is nothing left to be made, and so begins the installation
Mike> process, so when it fails, only ld-2.1.1.so has been installed. I
Mike> suspect strongly that this install failure and the failure to determine
Mike> the system type are linked.
How did you call configure?
Mike> I have tried to compile and install glibc-2.1.1 on the Pentium many
Mike> times, and, inexplicably, on rare occasions the configure script *could*
Mike> determine the system type. Attempts at reproducing this behaviour have
Mike> still failed to indicate what exactly I do differently to get the
Mike> different behaviour. (It does not happen often enough for experimention
Mike> to be effective.) Nevertheless, when the configure script correctly
Mike> determines the system type, the "make install" continues to what appears
Mike> to be almost its conclusion. All (as far as I can tell) of the
Mike> libraries are installed before the "make install" crashes with something
Mike> like
Mike> test ! -x /usr/src/glibc-build/elf/ldconfig | l \
Mike> /usr/src/glibc-build/elf/ldconfig -d /lib /usr/lib
Mike> whereupon I get the error message
Mike> /bin/sh: error loading shared libraries:
Mike> /bin/sh: undefined symbol: __setfpucw
Mike> At this stage, almost every binary is broken. Almost every binary
Mike> produces this "undefined symbol: __setfpucw" error, and exits.
Mike> According to the FAQ, effects like this can be expected if the
Mike> ld_linux.so and the version of glibc do not tally, but in my case they
Mike> do.
Mike> Unfortunately, when this happens, there is nothing I can do but to
Mike> restore the system to its pristine state. Fortunately, I took the
Mike> precaution of backing up my system on a MO device from which I can boot,
Mike> and copy the old system back again. I cannot re-compile all the
Mike> binaries on the system even if I had the time and inclination; among
Mike> other binaries that fail, make does as well, thereby making it
Mike> impossible to compile anything.
Please try the following:
- Install into a temporary directory with make install
install_root=/tmp/glibc
- play around in this temporary directory with (see FAQ 3.18):
LD_LIBRARY_PATH=/tmp/glibc/lib /tmp/glibc/lib/ld-linux.so.2 /some/binary
and check if this works - or not.
If you're confident that everything is ok, tar/cpio the temporary
directory to it's permanent place.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
