Hi Adam, unfortunately I no longer work at that company and so can't retest this issue. I have included Keith in the address list who is still working there and may be able to retest this.
Cheers, Seb On Sun, Feb 10, 2013 at 12:43 PM, Adam Conrad <[email protected]> wrote: > Is this issue still reproducible? Can I get a testcase for it, or some > sort of hint as to how to reproduce it? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/932621 > > Title: > String corruption > > Status in “eglibc” package in Ubuntu: > New > > Bug description: > Hi there, > > 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: > > libc-bin > libc-dev-bin > libc6 > libc6-dev > libc6-dev-i386 > libc6-i386 > libnih-dbus1 > libnih1 > > 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) > /lib/ld-linux.so.2 (0xf774e000) > > 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: > https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/932621/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/932621 Title: String corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/932621/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
