Bug#204706: Win4lin + Same binary breakage with compupic and citrix
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?
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?
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.
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
> 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. Repeatedly
attempting to close this bug report before even determining its cause
doesn't appear to be the appropriate response.
> 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.
Regards,
Adam
Reply to: