Bug#204706: Win4lin + Same binary breakage with compupic and citrix
At 11 Aug 2003 19:48:55 +1200,
Adam Warner wrote:
>
> On Mon, 2003-08-11 at 16:46, GOTO Masanori wrote:
> > At Sun, 10 Aug 2003 16:47:31 +0200,
> > Christoph Hellwig wrote:
> > > On Sun, Aug 10, 2003 at 02:44:59PM +0200, Rainer Ellinger wrote:
> > > > Same with compupic [1] (a static app and probably good choice to try
> > > > with) and apparently citrix iac clients [2]. Going back to 2.3.1-17
> > > > solved it for compupic.
> > >
> > > glibc does not claim binary compatiblity for statically linked binaries,
> > > and in fact the compatiblity tends to break from time to time when
> > > using nss. I think you'll have to educate the vendors of your non-free
> > > software..
> >
> > Ah, they are all static linked binaries? If so, it's right. I second
> > Christoph's thought. I would like to close this bug.
>
> Why is there such a rush to close this bug report?
Because a lot of users did report, but not close and leave them alone.
Especially this kind of vague report which only complaints us for
commercial software, I everytime rush to close until user loses his
interest. Bug tracking system is not dump of complaints. We can't
support commercial non-opensource software on development distribution
sid because sid is unstable and it's difficult to chase the problem
without source.
> 1. Do you know if win4lin has been compiled with NSS support?
>
> 2. Are you sure this is not a bug in glibc's compatibility layer?
Huh? So? We didn't know anything of internal Win4Lin. From your
report, how to guess to fix? If it's NSS issue or glibc compatibility
layer problem, then Christoph's guess is right, and we can't fix this
bug. Period.
> Looking at the glibc release notes there appears to be only a couple of
> mentions where binary compatibility has been broken with 2.3.2 compared
> to 2.1: http://www.gnu.org/software/libc/NEWS
>
> * the sockaddr_in6 structure changed. The IPv6 working group added a new
> field sin6_scope_id. This means that all programs using IPv6 should be
> recompiled. Don't expect binary compatibility with previous glibc
> versions.
>
> * The resolver code has been updated from bind 8.2.3-T5B which supports
> threads. The integration was done by Andreas Jaeger, Adam D. Bradley,
> and Mark Kettenis.
>
> This change could in some situations effect backward compatibility. Since
> now `_res' is a thread-local instead of a global variable, modifying it
> in one thread does not have any effect in other threads.
>
> The resolver library was also extended to allow IPv6 as the transport
> protocol for the requests. This work was done by Stig Venaas.
Debian glibc 2.3.2-2 is not plain glibc 2.3.2. Libnss issue is
introduced recent libnss modification. You have to read debian-glibc
lists, before you guess wrong assumption.
> 3. As someone unskilled in this area Robert's stack trace doesn't look
> static compiled to me:
>
> open("/lib/libdl.so.2", O_RDONLY) = 3
> ...
> open("/lib/libc.so.6", O_RDONLY) = 3
I replied this problem in another thread. It's known issue and can't fix.
> > BTW, I wonder why you firstly contact to vendors and claim this issue.
> > If you find this software is not supported, then why don't you appeal
> > to the vendor "please support debian/woody" (be careful, it's not
> > "sid") ?
>
> Letting the vendor know is appropriate and I will do so.
So you will do.
> Repeatedly
> attempting to close this bug report before even determining its cause
> doesn't appear to be the appropriate response.
Because we can't reproduce this bug.
> > To fix this bug is "extract 2.3.1-17 and use LD_LIBRARY_PATH
> > environment variables, or use chroot for these kinds of software".
> > Actually I work this for my colleague machine which uses Wnn6
> > commercial Kanji-conversion system (* see notes). It's driven by old
> > libc6.
>
> Again as a novice in this area I understood incompatible Unix libraries
> were given a distinctive so name. I also understood this to be the
> reason that we can avoid the "DLL hell" that has plagued Windows
> platforms. If a library claims to be compatible and is not then this
> could be something for you or upstream to fix.
>
> By the way I have been fascinated to learn in this thread that static
> compiled programs can have a lower expectation of being binary
> compatible with operating system upgrades.
Yes, this kind of problem harasses us.
-- gotom
Reply to: