Hello List The em84xx plugin is using the libEM84xx.so library. This beast is only available binary and seems to be incompatible with glibc > 2.3.5 What can I do to get this combination working in a glibc >=2.4 environment ? Is it possible to create a static .la library bundled with these dependend libraries:
ldd /usr/lib/libEM84xx.so linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e03000) libm.so.6 => /lib/libm.so.6 (0xb7dde000) libc.so.6 => /lib/libc.so.6 (0xb7cbf000) /lib/ld-linux.so.2 (0x80000000)
or are there any other possibilities
vdr@helmutauer.de schrieb:
Hello List The em84xx plugin is using the libEM84xx.so library. This beast is only available binary and seems to be incompatible with glibc > 2.3.5 What can I do to get this combination working in a glibc >=2.4 environment ? Is it possible to create a static .la library bundled with these dependend libraries:
ldd /usr/lib/libEM84xx.so linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e03000) libm.so.6 => /lib/libm.so.6 (0xb7dde000) libc.so.6 => /lib/libc.so.6 (0xb7cbf000) /lib/ld-linux.so.2 (0x80000000)
or are there any other possibilities
Are there no linking guru's on that list with an idea ?
Helmut Auer wrote:
vdr@helmutauer.de schrieb:
Hello List The em84xx plugin is using the libEM84xx.so library. This beast is only available binary and seems to be incompatible with glibc > 2.3.5 What can I do to get this combination working in a glibc >=2.4 environment ? Is it possible to create a static .la library bundled with these dependend libraries:
ldd /usr/lib/libEM84xx.so linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e03000) libm.so.6 => /lib/libm.so.6 (0xb7dde000) libc.so.6 => /lib/libc.so.6 (0xb7cbf000) /lib/ld-linux.so.2 (0x80000000)
or are there any other possibilities
Are there no linking guru's on that list with an idea ?
I remember fixing realplayer plugin for netscape years ago, by linking it against a static version of the old libc...
Anyway, as you are already building em84xx plugin, you might try linking against a static version of the correct libc by simply adding the full path to the lib as an object to the plugin linking call, e.g. change the Makefile here:
libvdr-$(PLUGIN).so: $(OBJS) $(CXX) $(CXXFLAGS) -shared $(OBJS) -o $@ -lEM84xx -losd @cp $@ $(LIBDIR)/$@.$(APIVERSION)
to
libvdr-$(PLUGIN).so: $(OBJS) $(CXX) $(CXXFLAGS) -shared $(OBJS) -o $@ \ /path/to/correct/libc.a -lEM84xx -losd @cp $@ $(LIBDIR)/$@.$(APIVERSION)
But I do not give any guarantees that this works or crashes earlier of later. Maybe vdr runs for some time but crashes later because some code initiates a call which gets routed to the old libc code.
So long,
I remember fixing realplayer plugin for netscape years ago, by linking it against a static version of the old libc...
Anyway, as you are already building em84xx plugin, you might try linking against a static version of the correct libc by simply adding the full path to the lib as an object to the plugin linking call, e.g. change the Makefile here:
libvdr-$(PLUGIN).so: $(OBJS) $(CXX) $(CXXFLAGS) -shared $(OBJS) -o $@ -lEM84xx -losd @cp $@ $(LIBDIR)/$@.$(APIVERSION)
to
libvdr-$(PLUGIN).so: $(OBJS) $(CXX) $(CXXFLAGS) -shared $(OBJS) -o $@ \ /path/to/correct/libc.a -lEM84xx -losd @cp $@ $(LIBDIR)/$@.$(APIVERSION)
But I do not give any guarantees that this works or crashes earlier of later. Maybe vdr runs for some time but crashes later because some code initiates a call which gets routed to the old libc code.
Thanks for the hints :)
I just tried another way. The original behaviour is that:
libEM84xx is using libm.so.6, libc.so.6 and libpthread.so.0 libm.so.6 is a link to libm-2.3.4.so and uses /lib/ld-linux.so.2 and libc.so.6 libc.so.6 is a link to libc-2.3.4.so and uses /lib/ld-linux.so.2 /lib/ld-linux.so.2 is a link to ld-2.3.4.so libpthread.so.0 is a link to /lib/libpthread-0.10.so and uses libc.so.6 and /lib/ld-linux.so.2
Now I did the following:
Patched libEM84xx to use libn.so.6, libd.so.6 and libxthread.so.0 created libn.so.6 as a link to libn-2.3.4.so copied libm-2.3.4.so to libn-2.3.4.so and patched this one to use use /lib/lx-linux.so.2 and libd.so.6 copied libc-2.3.4.so to libd-2.3.4.so and patched this one to use use /lib/lx-linux.so.2 created /lib/lx-linux.so.2 as a link to lx-2.3.4.so copied ld-2.3.4.so to lx-2.3.4.so created libxthread.so.0 as a link to /lib/libxthread-0.10.so copied /lib/libpthread-0.10.so to /lib/libpthread-0.10.so and patched this one to use use /lib/lx-linux.so.2 and libd.so.6
So now a ldd libEM84xx shows:
libEM84xx is using libn.so.6, libd.so.6 and libxthread.so.0 libn.so.6 is a link to libn-2.3.4.so and uses /lib/lx-linux.so.2 and libx.so.6 libd.so.6 is a link to libd-2.3.4.so and uses /lib/lx-linux.so.2 /lib/lx-linux.so.2 is a link to lx-2.3.4.so libxthread.so.0 is a link to /lib/libxthread-0.10.so and uses libd.so.6 and /lib/lx-linux.so.2
so far so good, but when i now execute ldconfig the system gets killed, because it does the following:
linking libm.so.6 to libn.so.6 instead of libm-2.3.4.so linking libc.so.6 to libd.so.6 instead of libc-2.3.4.so linking libpthread.so.0 to libxthread.so.0 instead of /lib/libpthread-0.10.so
Why does this happen and what can I do to avoid this ?