Public bug reported: 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) ** Affects: eglibc (Ubuntu) Importance: Undecided Status: New -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs