[Bug 932621] Re: String corruption
doko at ubuntu.com
Wed Feb 15 15:25:44 UTC 2012
- don't mix releases. rebuild ifupdown in oneiric, if needed.
- please report the issue where you did download this software.
** Package changed: eglibc (Ubuntu) => ubuntu
** Changed in: ubuntu
Status: Confirmed => Invalid
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
Status in Ubuntu:
I'm installing a 64 bit ubuntu server system with oneiric. However,
due to https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/905660
I am trying to pull in ifupdown from precise. This pulls in the
following additional packages from precise due to dependencies:
The oneiric version of the libc packages is 2.13-20ubuntu5.
The precise version of the libc packages is 2.15-0ubuntu2.
After this, a i386 application that I have installed on the machine
breaks. The application is multi V4.2.4 from Green Hills. It is their
proprietary compiler suite and IDE. When I use this compiler suite to
compiler our embedded application, it fails to find a particular
library. Upon further investigation I found that the front-end
compiler driver (gbuild) passed the wrong library search path down to
the compiler. The output of ldd gbuild is:
la:~/trunk $ ldd /usr/ghs/multi424/gbuild
linux-gate.so.1 => (0xf774d000)
libm.so.6 => /lib32/libm.so.6 (0xf7710000)
libnsl.so.1 => /lib32/libnsl.so.1 (0xf76f7000)
libdl.so.2 => /lib32/libdl.so.2 (0xf76f2000)
libc.so.6 => /lib32/libc.so.6 (0xf7578000)
With the oneiric version of the above packages, gbuild passing the
(correct) option -L../output/ppc to the compiler. With the precise
version of these libraries gbuild passes -L../outuut/ppc to the
compiler. gbuild gets the path from a config file, which actually
contains the option -L../../output/ppc, but is located one directory
below the current working directory of the compiler invocation and is
defined to be local to that file.
So I suspect that gbuild recognizes the -L option and the fact that
it's argument is a relative path (another -L in the same file with an
absolute path is passed through correctly) and tries to strip off the
initial ../ but something goes wrong. I also suspect that the bug only
shows up in the 32bit version of libc on 64 bit systems, since all my
64 bit apps seem to behave normally.
I can modify the option in the config file to check what, if any,
corruption occurs to different strings. Here are some results:
-L../../output/ppc => -L../outuut/ppc (corrupted, that's the one that I found this with)
-L../../../output/ppc => -L../../output/ppc (correct, no corruption)
-L./../../output/ppc => -Lshared-libs/.../output/ppppc (corrupted, shared-libs is the directory that the config file resides in)
-L./../output/ppc => -Loutput/ppc (correct, no corruption)
-L.././../output/ppc => -L../output/ppc (correct, no corruption)
-L../.././output/ppc => -L../output/ppc (correct, no corruption)
To manage notifications about this bug go to:
More information about the foundations-bugs