Re: [gentoo-user] Re: Changing glibc
No other diff program comes even close to BC in terms of diff output quality and merge capability. I am willing to go through much more hoops than this just to be able to use this under linux. And also, to avoid any misrepresentation, their support in determining the cause of the issue was very good. The problem seems to be that their linux build is using an older gcc version. This was causing an ABI related crash in the strstr function, which was using SSE instructions. So at some point, they will probably switch to a newer compiler and the problem will go away. But if I mail their support, it would take many messages until we come to the same page (the previous developer getting copied on it, he remembers the issue etc etc). It is much faster to just try it :) -- Timur
Re: [gentoo-user] Re: Changing glibc
2014-08-18 19:03 GMT-03:00 Alan McKinnon : > On 18/08/2014 23:17, Grant Edwards wrote: > > On 2014-08-18, Rich Freeman wrote: > >> On Mon, Aug 18, 2014 at 2:21 PM, J. Roeleveld > wrote: > >>> > >>> In cases like that I would do either of the following: > >>> > >>> 1) Run it inside a VM > >>> 2) run it inside a chroot > >>> > >>> That way you can easily keep everything updated except for that > >>> application. > >> > >> Or better still run it inside a container. > > > > Or better still, demand either a less broken app or one that's > > statically linked. > > > > That was my thought too. The app is a visual differ. It's not rocket > science, so what business does it have needing a custom glibc? > > My spidey-sense is tingling, I'm wondering what other weirdnesses such > an app might have under the covers > > > -- > Alan McKinnon > alan.mckin...@gmail.com > > > Just m 2 cents: Have you tried kdiff3 ? Good luck and best regards, Francisco
Re: [gentoo-user] Re: Changing glibc
On 18/08/2014 23:17, Grant Edwards wrote: > On 2014-08-18, Rich Freeman wrote: >> On Mon, Aug 18, 2014 at 2:21 PM, J. Roeleveld wrote: >>> >>> In cases like that I would do either of the following: >>> >>> 1) Run it inside a VM >>> 2) run it inside a chroot >>> >>> That way you can easily keep everything updated except for that >>> application. >> >> Or better still run it inside a container. > > Or better still, demand either a less broken app or one that's > statically linked. > That was my thought too. The app is a visual differ. It's not rocket science, so what business does it have needing a custom glibc? My spidey-sense is tingling, I'm wondering what other weirdnesses such an app might have under the covers -- Alan McKinnon alan.mckin...@gmail.com
