Re: Fwd: Re: unable to execute
Anand Kumria wrote:
>
> On Mon, 27 Mar 2000, Tristan Savatier wrote:
>
> > Yes, but I have not received it.
> >
> > We have received several email of people reporting that mtv/mtvp
> > does not work at all on some recent distributions of Corel linux.
> > Is Corel Linux based on Debian ?
>
> yes it is.
>
> > In all cases, 'mtvp -h' seg faults immediately.
> > normally 'mtvp -h' should just print a help message
> > and exit.
>
> I just checked on my Corel box. You have two version of mtv
> available: one for glibc2.0 and the for glibc2.1
>
> It works (well runs, I have no VCDs to test with at work) and display
> help (mtvp -h). Even the graphical intreface works too. That .deb was
> mtv_1.1.0.20-2_i386.deb
>
> When I install the glibc2.1 version (mtv_1.1.0.20-3_i386.deb) it
> promptly fails. You don't seem to have any dependancy information in
> your .deb's which is probably a bad thing.
Our deb package files are derived from our RPM's using the
'alien' script. Looks like alien is not perfect.
> Debian 2.1 ships with libc6-2.0.7.19981211-6; Corel has the same
> version. Debian 2.2 has libc6-2.1.3-7 (currently). Perhaps depending
> on the right version of the libc6 would be good.
yes, but that would force us to make debian-specific packages.
we don't want that. we want RPM to be our master packages,
and we convert to other formats (DEB, SLP) using alien.
BTW, have you tried to run our glibc2.1 version on your
Debian 2.2 ? does it work ?
> Also for the glibc2.0
> version you provide an SDL deb, yet it isn't depended upon.
yes it is: but only the fullscreen extension plugin
(mtv-fullscreen-extension) depends on SDL.
> > usually when this type of thing happens, it is something
> > broken with the libraries. mtvp is one of the few multithreaded
> > applications, and anything broken in the thread support would be fatal
> > for mtvp.
>
> They've installed the wrong version; perhaps updating your ver web
> site with information for Corel would be useful too.
certainely a good idea. we'll do that. thanks for your help
understanding the situation. still, I don't fully understand
why glibc2.1 and glibc2.0 are not binary (API) compatible ?
It looks like a major problem to me, and causes havoc again
(I mean, after the glibc2.0/libc5 incompatibility).
-t
Reply to: