On Tue, 20 Mar 2007 08:56:45 +0100 Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 19, 2007 at 10:21:16PM +0100, Rafael J. Wysocki wrote: > > > I can't see how people can `depend' on it. Especially since this is > > > only in CVS since a few days. Also libx86 isn't in CVS anymore so they > > > will have to get it anyway. The only difference is that instead of > > > typing two times cd XXX and make && make install, they only do that once. > > > > Hm, I think I misunderstood the issue. > > > > Can anyone please explain to me what the current situation is and why it may > > be a good idea to change it (or not)? > > One problem people might hit is that, depending on the distro packaging, they > might pick up libx86 with x86emu enabled, even though they run on x86 hardware > (which should, in theory, work just fine, but well, you never know). This would then be a bug in the packaging of the distro then. > Another possible problem might be dynamic linking vs static linking. Up to > now we always linked x86emu objects directly into s2ram. Dynamically linking > against system wide installed libx86 might turn up new bugs. The "embedded" > libx86 stuff in the Makefile does static linking. I don't think this would matter much, but heh, I lack the the knowledge too ;) > These are the main points why i did it as it is, to avoid any regressions. > I personally, probably simply from lack of knowledge ;-) don't have a strong > opinion on how to do it "right". I'm not claiming that I've did it right, but I've made a patch that changes the Makefile a bit to make it more 'clean'. Could you take a look if you approve it. It is in the reply to Rafael. grts Tim ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
