Linux-Development-Sys Digest #687, Volume #6 Fri, 7 May 99 12:14:12 EDT
Contents:
egcs Warning while building gcc-2.8.1 cross compiler (Tom Daley)
glibc-2.1 and incompatible apps ([EMAIL PROTECTED])
sleep_on / wake_up problem, full-duplex, SoundBlaster 16 ("Regis")
Any program can generate Gif or Jpg (Dove)
Re: Mac-emulation on Linux? (Pasi Korhonen)
Re: Glibc rant (Lou Grinzo)
Re: Glibc rant (Peter Mutsaers)
Re: glibc-2.1 and incompatible apps ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: glibc-2.1 and incompatible apps (David T. Blake)
Re: Glibc rant (David T. Blake)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tom Daley)
Subject: egcs Warning while building gcc-2.8.1 cross compiler
Date: 7 May 1999 04:05:17 GMT
I am having problems compiling gcc-2.8.1 as a cross compiler
using egc-1.1.1. I have two systems, one at work and one at home.
My home system has been running Linux for a long time (since 0.99p12).
The system at work I installed last year when I started working there.
On both systems I have built/installed glibc-2.0.7pre6 and egcs-1.1.1.
Then I built gcc-2.8.1 as a cross compiler on the system at work and
all was well. When I try to build the cross compiler at home I get
an error in the build.
gcc -DCROSS_COMPILE -DIN_GCC -g -DHAVE_CONFIG_H -I. -I.. -I../config \
-DSTANDARD_STARTFILE_PREFIX=\"/usr/local/lib/\"
-DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc-lib/\" -DDEFAULT_TARGET_VERSION=\"2.8.1\"
-DDEFAULT_TARGET_MACHINE=\"i386-wrs-vxworks\" -DTOOLDIR_BASE_PREFIX=\"/usr/local/\" \
-DLANG_SPECIFIC_DRIVER \
-c g++.c
gcc: Warning: use of obsolete %[ operator in specs
gcc -c -DCROSS_COMPILE -DIN_GCC -g -DHAVE_CONFIG_H -I. -I.. -I../config
../cp/g++spec.c
gcc: Warning: use of obsolete %[ operator in specs
gcc -DCROSS_COMPILE -DIN_GCC -g -DHAVE_CONFIG_H -o g++ g++.o g++spec.o prefix.o \
version.o choose-temp.o pexecute.o obstack.o ` case "gcc" in "cc") echo "" ;;
esac `
/usr/i486-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to
08048080
g++.o: In function `translate_options':
/usr/local/src/gcc-2.8.1/vxWorks386/g++.c:878: undefined reference to `strlen'
/usr/local/src/gcc-2.8.1/vxWorks386/g++.c:879: undefined reference to `strlen'
/usr/local/src/gcc-2.8.1/vxWorks386/g++.c:886: undefined reference to `strncmp'
/usr/local/src/gcc-2.8.1/vxWorks386/g++.c:895: undefined reference to `strlen'
/usr/local/src/gcc-2.8.1/vxWorks386/g++.c:895: undefined reference to `strncmp'
....
I am sure that there is some program or library on my home system that is
too old and needs to be updated to resolve this problem. I have not
figured out what it is yet. I have installed the latest flex and bison.
I made sure I don't have "encaps" as mentioned in the egcs FAQ.
The problem persists.
I know I could just tar up the files I made at work and bring them home
but I would like to fix my system.
Thanks.
--
===================================================================
| o Tom Daley |
| ___ </v Woodland Park, CO |
| ___ -\ [EMAIL PROTECTED] |
| ___ / (719) 534-0449 x27 |
| (*) Linux! |
===================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: glibc-2.1 and incompatible apps
Date: 7 May 1999 09:37:00 GMT
Hello,
i'm having the same problem with Debian and MuPAD, which is a
glibc 2.0 linked program. Any elegant solution?
Cheers,
Nuno Sucena
--
http://student.dee.uc.pt/~slug
CT1FOX CQG9304 @ 80m, 40m, 20m, 17m, 12m, 11m , 10m
------------------------------
From: "Regis" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: sleep_on / wake_up problem, full-duplex, SoundBlaster 16
Date: Fri, 7 May 1999 11:06:37 +0200
I would be happy to have a solution about a little sleep_on/wake_up problem
I have.
First,let me explain what lead to the problem:
I recently change a SoundBlaster PRO for a SoundBlaster 16 and i have decide
to build my own driver as a loadable module (Voxware sound driver work !).
In my driver ,I have implemented a full-duplex capability as it is possible
with a SB 16, by using of the two DMA channels (8bits and 16bits) at the
same
time. I use 16bits DMA for recording and 8 bits DMA for playing, both DMAs
share the same IRQ but a soundcard status port give the info on which
DMA (or sample size) it's occuring. Status gives 0x81 for 8bits, 0x82 for
16bits (and 0x83 for both but this should be avoid, maybe).
Basicaly, the driver work like this. At init, two DMA buffers are allocated,
one for each DMA channel, interrupt is registered without SA_INTERRUPT.
When writting, the write function try to fill as much as it can the DMA
buffer ,if the buffer is full the proccess go to sleep through a call
to 'interruptible_sleep_on' and is wake up by the interrupt routine when
there is available space.
When reading, the read function try to read as much as it can from the DMA
buffer ,if the buffer is empty the proccess go to sleep through a call
to 'interruptible_sleep_on' and is wake up by the interrupt routine when
there is data available.
To demonstrate myself the full-duplex, I have built a little program which
does this :
1) set read to 16bits 44100 Hz stereo
2) set write to 8bits 44100 Hz stereo
3) in a loop send data read from soundcard to the soundcard (after signed
word to unsigned char convertion)
This produce an echo effect, and it works.
Here is the problem, it happen that the program never wake up.
That arise when apparently interrupt for 8bits and 16bits are merge.
When buffers are synchronise, it has never happens.
By synchronise, I mean that the 8bits buffer length represent the same
sampling time as the 16bits buffer length, as long as the two DMA doesn't
start at the same time all work fine even with 8bits buffer length of 128
bytes, which is an interrupt rate generation of 689 Hz (8bits stereo 44100
Hz).
If both buffers represent different timings, after a while the program stop
'echoing' but don't hang the system.
The Question:
Does anybody knowns about how to fix me, or can give me a guideline to
follow
for a full-duplex operations ?
Note:
I used linux 2.0.0 (Slackware 3.1) on an IBM PS/VP 486DX2 66 Mhz with 20
Mb.
The driver is for my personnal use.
" As of version 2.0.0, linux still don't recognize my 2 harddisks (Maxtor)
without specifying the geometries, even with brand new E-ide driver.
OpenBSD does recognize them without help !
And I don't tell you about Mitsumi CD driver "mcdx" which, when doing
a simple 'find /cdrom -name *.lsm -print > lsm.all ' command, slowdown
the
system in a way that I must wait a bunch of seconds between each char I
type
or when I switch to another virtual console ..."
------------------------------
From: Dove <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Any program can generate Gif or Jpg
Date: Fri, 07 May 1999 18:39:49 +0800
Hi,
In Linux, is there any program or script can generate a Gif or Jpg chart
according to some ASCII data?
Regards.
------------------------------
From: Pasi Korhonen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
Date: 3 May 1999 11:35:49 GMT
In comp.os.linux.powerpc Chris Johnson <[EMAIL PROTECTED]> wrote:
> I'm still puzzling over some xmodmap details- Jamie Zawinski worked out
> the ultimate Mac keyboard keymap for the MkLinux setup, but I haven't
Now there's a piece of interesting information for us old-NuBuS-
MkLinux-users. =) Where can I read more about this ?
Pasi
8100/80, DR3
--
Pasi Korhonen|[EMAIL PROTECTED]|[EMAIL PROTECTED]|040 5055 270|08 3210 800
------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Subject: Re: Glibc rant
Date: Fri, 7 May 1999 08:57:27 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> [EMAIL PROTECTED] (Lou Grinzo) writes:
>
> >My point is that when you're talking about a system library,
> >a change should NEVER be the proximal cause of apps breaking.
> >It's not a matter of whose fault it is, or who did what with
> >the library that they weren't supposed to, etc.
> >
> >Does this cause cruft build up? Absolutely, and I'm as
> >militantly anti-cruft as programmers get. But it's still
> >better than breaking apps, because cruft costs less in
> >the short and long run than alienating users and programmers
> >with this sort of compatibility problem.
>
> This is really not a serious consideration in an open
> source system. Everything can be recompiled. A distribution
> upgrade was all that I required to be fully functional
> again. If I didn't want newer versions of everything, I
> could keep what I had. Anything that didn't work, I could
> recompile.
As long as the Linux community takes this view--problems can
be solved by recompiling, that's the benefit of getting the
source, etc., the mainstream user community will forever be
a mirage on the horizon.
>
> >The Linux community should be VERY relieved that this happened now,
> >and not a year from now, when there would be many more mainstream
> >Linux users screaming from the rooftops about how upgrading to RH 8.0
> >or SuSE 8.0 broke their apps.
> >
> >I sincerely hope that everyone involved learned a lesson and won't
> >let this happen again. This is exactly the kind of nonsense that
> >drives Windows users crazy (they call it "DLL Hell"), and is one of
> >the reasons Linux is so appealing to them--it's more stable and far
> >less prone to going haywire when you upgrade the system or apps.
>
> No, dll hell is different. If you get a third party app for
> Unix, the third party will substitute libraries for the
> system's libraries by throwing them somewhere on the disk,
> and having a shell script set LD_PRELOAD or LD_LIBRARY_PATH
> before calling the real binary executable. StarOffice does this,
> as does Matlab. It is the 'right' way to issue a third party
> closed source binary. Matlab will never break with a system upgrade,
> since it uses ONLY its own libraries.
Yes, this is not exactly like dll hell; you're right. I know all
about dll hell, having bitched about it endlessly in my book, Zen
of Windows 95 Programming. But the problems are very similar
from a user's standpoint--you have a working system, you upgrade
one part, and then something else unexpectedly breaks.
>
> dll hell occurs because in the infinite wisdom of M$, link libraries
> are only found in one place. A third party will regularly, as part
> of their install, write over your existing dlls with their own, which
> may or may not be compatible. Then you are hosed.
No, it is definitely not true that dlls are "only found in one place".
There is a search sequence that Windows uses when finding a DLL that
an application is trying to load, and this includes the main Windows
directory, the Windows System directory, the current directory, and
the applciation's home directory. Many programs, including those I
write, put all their non-shared dlls in the same directory as the
main program, and everything works just fine, with no extra effort
at all on the part of the programmer.
But it is true that MANY appl developers go wild with DLLs and stuff
them in places where they shouldn't be, overlay newer versions, etc.
And I agree that MS is to blame for creating this creaky architecture
in the first place. This is, IMO, a perfect example of MS's obsession
with "getting something to work" and then stopping there, without
paying sufficient (or any) attention to the second-order concerns,
like how you safely uninstall something.
MS is paying a lot more attention to such details now, which is a
good thing, but it's so late in the game that it's arguable whether
it will really help the situation. (And MS apps are some of the
worst offenders when it comes to DLL hell and not letting the
user maintain control over his/her own computer.)
>
> > In my personal usage, Linux has been a rock compared to Windows
> >98's house of cards. But I'm sticking with RH 5.2 for my real work
> >until this problem is ironed out to the point that all I have to do
> >is install a glib 2.2 (2.1A, or whatever) to make all the parts of my
> >system peacefully coexist.
>
> You will be waiting a long long time. Because there is not even
> a hint from the glibc people that they will ever make a version
> that is totally backwards compatible.
>
>
> --
> Dave Blake
> [EMAIL PROTECTED]
>
------------------------------
From: Peter Mutsaers <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: 06 May 1999 22:39:42 +0200
>> "LG" == Lou Grinzo <[EMAIL PROTECTED]> writes:
LG> My point is that when you're talking about a system library, a
LG> change should NEVER be the proximal cause of apps breaking.
LG> It's not a matter of whose fault it is, or who did what with
LG> the library that they weren't supposed to, etc.
In some very occasional circumstances it may have to happen (such as
moving to a new type of object code format, like a.out->elf as Linux
did some years ago) but it happens way too much and too ungracefully
in Linux.
FreeBSD for example moved from a.out->elf about a year ago, it was a
very smooth transition. Still all current FreeBSD systems contain
backwards compatability libraries until 4 years ago. Real old binaries
still run without problems or tricks.
LG> The Linux community should be VERY relieved that this happened
LG> now, and not a year from now, when there would be many more
LG> mainstream Linux users screaming from the rooftops about how
LG> upgrading to RH 8.0 or SuSE 8.0 broke their apps.
LG> I sincerely hope that everyone involved learned a lesson and
LG> won't let this happen again. This is exactly the kind of
Don't count on it.
It happened once when Linux was still using a.out (in 0.99/1.0 times)
when the type of shared library changed from non-pic to pic (position
independent code). I used Linux in that time and used to build
everything myself; still enjoyed it then but no more. Then some more
incompatible changed of libc.
Then Linux switched from a.out to elf (libc4 -> libc5) in a very
painful way. Even though it took one year many people were puzzled and
lost.
Then libc5 went to remerge with glibc, to get (g)libc6. Alas alas,
many Linux distributions (the only good exception is Slackware) went
to libc6 right away, to the 2.0.x series. Even though the GNU people
told that the 2.0.x series was not yet intended for production use and
was subject to (external) change.
Now we arrived at 2.1.x which is another painful (and unnecessary)
transition. This shouldn't have been so since it is both the same main
revision number (6) so there should be no compatability problems, yet
still the hack of libNoversion (ugh) is necessary to fix a bit of the
mess.
Why the hurry to use glibc 2.0? Because libc5 had gotten way behind of
current kernel features (SMP) which libc6 (glibc2) supports, but using
GNU libc makes you dependent on GNU, not always known for fast
delivery and out of the span of control of many Linux developers and
distributors.
FreeBSD never had such problems since FreeBSD-core controls everything
in the base system, inclusive the C library etc.
--
Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know
[EMAIL PROTECTED] | the Netherlands | what I'm doing.
===============+=====================+==================
Powered by FreeBSD (-current). See http://www.freebsd.org
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 and incompatible apps
Date: 03 May 1999 10:20:09 -0400
>>>>> "Juergen" == Juergen Heinzl <[EMAIL PROTECTED]> writes:
> Compile'em yourself or get the 2.1.x version; the only application yet
> that causes trouble is Applixware and for that one I've got a workaround,
> more or less.
I did compile Amanda myself. Recompilation is of course a workaround
but the problem is that those apps are shared via NFS and some machines
use glibc-2.0 while others use 2.1 so if I recompile with 2.1 it will just
shift the problem. Of course I can then keep two versions around and try to
make sure the right version is run on the right machines. But this is all a
big hassle. Upgrading from libc-5 to libc-6 did not suffer so badly.
> Alternatively use libc5 versions, the memory overhead is not that much.
I don't have any machine around where I can recompile with libc-5
so this solution is out of the question.
>> PS: I currently only have such problems with rstatd and amandad (both
>> of which using UDP, funnily enough).
> See above.
So we have rstatd, Amanda, Applixware, what else ?
Stefan
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: glibc-2.1 and incompatible apps
Date: 07 May 1999 07:37:48 -0700
[EMAIL PROTECTED] writes:
>Hello,
> i'm having the same problem with Debian and MuPAD, which is a
>glibc 2.0 linked program. Any elegant solution?
The elegant solutions are
1) recompile MuPAD
2) use glibc2.0
3) export LD_PRELOAD=/usr/lib/libstdc++.so (this won't work for
every app - just most of them).
4) Install all glibc2.0 apps into /glibc20/bin
Keep the glibc2.0 libraries in /glibc20/lib
Put Shell scripts in place of the binaries. For the
binary /usr/bin/foo, the shell script would read
#!/bin/sh
LD_LIBRARY_PATH=/glibc20/lib:${$LD_LIBRARY_PATH}
/glibc20/bin/foo
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Glibc rant
Date: 07 May 1999 07:44:20 -0700
[EMAIL PROTECTED] (Lou Grinzo) writes:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>> This is really not a serious consideration in an open
>> source system. Everything can be recompiled. A distribution
>> upgrade was all that I required to be fully functional
>> again. If I didn't want newer versions of everything, I
>> could keep what I had. Anything that didn't work, I could
>> recompile.
>
>As long as the Linux community takes this view--problems can
>be solved by recompiling, that's the benefit of getting the
>source, etc., the mainstream user community will forever be
>a mirage on the horizon.
That is life on the bleeding edge. If you want to be comfortable
using closed source programs, you need to wait about as long
as it takes the authors to keep up with the recompilation
cycle.
In Windows, you get upgrades months and months after problems
are found. With linux you get them in hours if you are willing to
recompile, or days if you are not willing to recompile.
When you tie your hands by causing a significant dependency
on a third party to recompile their apps for you, you have
lost one of the biggest benefits of open source operating
systems. A system that is part open, part closed, will always
have significant problems compared to an all open system.
You can whine about it till the cows come home, but the appropriate
solution is to use only distributions that have been out for
a year or so, and to live without the improvements that have been
made in the meantime. It is just like dealing with any other OS
vendor, except that you can see the improvements that have been
made without being able to utilize them.
--
Dave Blake
[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
******************************
