Date: Wed, 12 Feb 1997 10:48:02 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, swallace@ece.uci.edu, current@freebsd.org Subject: Re: linux ELF codine no go on 2.2 Gamma Message-ID: <199702120018.KAA08924@genesis.atrad.adelaide.edu.au> In-Reply-To: <199702112354.QAA29345@phaeton.artisoft.com> from Terry Lambert at "Feb 11, 97 04:54:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > better next time. (Do you actually have to deal with commercial outfits > > doing code for Linux? I wot not.) > > You're right, I don't. That's because there are comparatively few > of them, despite what Linux advocates would have you think. I'm aware of this. However, there are a number that are actually quite useful, and of these, several are statically linked. One of these is the FlexLM license manager. > Besides which, you are ignoring the fact that the tools Linux uses > will automatically brand any newly created binaries. Not in any of the releases currently in use by commercial developers. > > As for "updated tools", you read the glibc 2.0 announcement posted here > > a while back, no? You read the part where they're moving _closer_ to > > the SVr4 ABI and using the same linker path, ie. making it > > _harder_ to tell the two apart? > > The linker path is not the correct way to tell them apart. That was > a seriously bogus differentiator. If they move fully to the SVR4 ABI, > then there's no *need* to tell them apart. The point being that they aren't moving 'fully' to the SVR4 ABI, they're just eliminating the linker path as a means of actually usefully differentiating between SVR4 and Linux ELF binaries. > > Na und? "Install all your Linux stuff in /compat/linux" is a much > > easier instruction to follow than "Find all the ELF binaries in every > > Linux package you install and execute this command on each of them". > > How do I edit my path? Part of it I inherit from system files, > and part of it from my own resource files (.cshrc/.login). Will > you hack the system path files when you install an ABI compatability > package? Will you hack the default user resource files that are > used as templates by the adduser? What about the users already on > the system? I will say to people "Install your Linux applications in /compat/linux, put /compat/linux/usr/local/bin on your path". > This is an untenable soloution. Really? It looks like a useful, short-term workaround to a large and ugly problem that isn't about to go away, regardless of the amount of wishfulness I may apply to the situation. > The people installing will already have to hack the install to get > the code onto the system anyway (RedHat pacakage management for > FreeBSD, anyone?). /usr/ports/misc/rpm, or aren't you watching again? 8) > I will, if you will hack the default paths to add the wart to recognize > the wart you are suggesting; otherwise, you're only doing half the > necessary hack. I will _not_ trample that far 8) All I am suggesting is an extra 'hint' for ABI recognition, based on 'common practice', just like the 'hint' that uses the linker path. Once branded ELF binaries are the norm, both will go the way of the dodo. > A better soloution is to create a "package" for commercial Linux > product distributions, since you have to do a damn hand-install anyway > to get them installed, and then have them do the brand. You solve > the binary recognition and the hand-install problems at the same time, > and you do it without hacks. This is, of course, a good short-term solution. It doesn't address everything of course (like, who does the work?) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702120018.KAA08924>