Re: Is compatibility for old aout binaries broken?
On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... Does anyone have any old a.out binaries other than SimCity that they have problems with? I've installed the SimCity package, compat20 and compat21 dists, but cannot get it to run: Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes Adding a player on dragon:0.0 ... Display Visual = truecolor Display Depth = 24 SimCity can't find an 8 bit color or 1 bit monochrome display on "dragon:0.0". SimCity: error in TCL code: bad window path name ".head0" -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Looks like you got a lot farther than I did with it... Are you sure you don't have an old aout ld.so on that machine? Here's what I get: dmaddox SimCity Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 dmaddox BTW - That 'commerce' directory has more old aout binaries in it I bet... Also, it looks to me like SimCity would probably run just fine for you if you started X on an 8-bit display... On Wed, Dec 20, 2000 at 12:51:06AM -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... Does anyone have any old a.out binaries other than SimCity that they have problems with? I've installed the SimCity package, compat20 and compat21 dists, but cannot get it to run: Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes Adding a player on dragon:0.0 ... Display Visual = truecolor Display Depth = 24 SimCity can't find an 8 bit color or 1 bit monochrome display on "dragon:0.0". SimCity: error in TCL code: bad window path name ".head0" -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: This has been broken for new users for some time. :-( Those of us upgrading from source have been immune to this problem, because we retain the old a.out ld.so binary. /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 When errno became a function that returns a pointer (previously it was a simple integer variable), recompiled libraries became incompatable with old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. Well, Nate called it a horrible hack, so maybe I should say "the hack was in 3.0". src/lib/libc/sys/__error.c suggests this was the case for 2.2.7+. What is out of sync is the X11 a.out libs. They are probably built on a 2.2.7 or 2.2.8 box, thus they refer to `___error' vs. `errno'. These libs are wrong for the SimCity binary. They are a.out yes, but not proper for compat20 use. Since SimCity needs `libgcc.so.261', I'll assume it was built that long ago. The problem isn't as much ld.so, as it should match the libc.so, et.al. you are using from the compat2[01] dist (needed to satisfy ``ldd lib/SimCity/res/sim''). And `ld.so' and the shared libs would be consistent on the system the a.out program was built on. What I would feel most comfortable with, is doing a MFC to RELENG_2_2 of the rtld-aout changes since then, building a new `ld.so' and putting that in the compat2? dists. Problem is I don't have access to a 2.2-STABLE box. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at rev 1.1. So there has been no change to them over the lifetime of their existence. All three are identical -- having the same MD5 checksum. Well, looking at the release tags compat22/ld.so was in 3.2. compat2[01]/ld.so was added for 3.3. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Not quite. I seem to remember that JKH was makeing a tarball of a.out libs from what ever was on his box at the time (thus probably the last a.out ld.so just before E-day on 3-CURRENT). When I committed the compat2? bits, I took ld.so from a 2.2.x release as this is the compat2? dist, not compat3.aout dist. Which is what you're suggesting should have been done. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Actually, the aout libs I am using when I get the ___error undefined are the ones from the XFree86-3.3.6 distribution, compiled for FreeBSD 3.x. Originally I was using the aout X libs I built myself when building the XFree86-3.3.6 port. Using those, I still got an undefined symbol, but it wasn't ___error, and I don't remember exactly what it was, just that it started with 3 underscores too. On Wed, Dec 20, 2000 at 01:42:59AM -0800, David O'Brien wrote: src/lib/libc/sys/__error.c suggests this was the case for 2.2.7+. What is out of sync is the X11 a.out libs. They are probably built on a 2.2.7 or 2.2.8 box, thus they refer to `___error' vs. `errno'. These libs are wrong for the SimCity binary. They are a.out yes, but not proper for compat20 use. Since SimCity needs `libgcc.so.261', I'll assume it was built that long ago. The problem isn't as much ld.so, as it should match the libc.so, et.al. you are using from the compat2[01] dist (needed to satisfy ``ldd lib/SimCity/res/sim''). And `ld.so' and the shared libs would be consistent on the system the a.out program was built on. What I would feel most comfortable with, is doing a MFC to RELENG_2_2 of the rtld-aout changes since then, building a new `ld.so' and putting that in the compat2? dists. Problem is I don't have access to a 2.2-STABLE box. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at rev 1.1. So there has been no change to them over the lifetime of their existence. All three are identical -- having the same MD5 checksum. Well, looking at the release tags compat22/ld.so was in 3.2. compat2[01]/ld.so was added for 3.3. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Not quite. I seem to remember that JKH was makeing a tarball of a.out libs from what ever was on his box at the time (thus probably the last a.out ld.so just before E-day on 3-CURRENT). When I committed the compat2? bits, I took ld.so from a 2.2.x release as this is the compat2? dist, not compat3.aout dist. Which is what you're suggesting should have been done. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 03:57:07AM -0500, Donald J . Maddox wrote: Looks like you got a lot farther than I did with it... Are you sure you don't have an old aout ld.so on that machine? Nope. This is a box that was a virgin install of 5-CURRENT a month ago. I had to install the compat20 and compat21 dists, along with doing a ``pkg_add -r XFree86-aoutlibs''. The Tk is 8.0.5. Here's what I get: dmaddox SimCity Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 Actually you're probably getting farther than I am. I believe I'm bombing so early in starting Tk, I'm not really getting to the point you are. What does `ldd /usr/local/lib/SimCity/res/sim'' report? Also, it looks to me like SimCity would probably run just fine for you if you started X on an 8-bit display... Maybe, but I'm not going to dink with my X server config. ;-) Mabye I'll try to find another box to try this on. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Hi, On Wed, Dec 20, 2000 at 01:52:23AM -0800, David O'Brien wrote: Nope. This is a box that was a virgin install of 5-CURRENT a month ago. I had to install the compat20 and compat21 dists, along with doing a ``pkg_add -r XFree86-aoutlibs''. The Tk is 8.0.5. The XFree86-aoutlibs are especially from XFree86-3.3.3. This was because of unstable behaviour from Netscape with later aout libs. They are obtained from: ftp://ftp.xfree86.org/pub/XFree86/3.3.3/binaries/FreeBSD-2.2.x/Xbin.tgz Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 01:52:23AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 03:57:07AM -0500, Donald J . Maddox wrote: Looks like you got a lot farther than I did with it... Are you sure you don't have an old aout ld.so on that machine? Nope. This is a box that was a virgin install of 5-CURRENT a month ago. I had to install the compat20 and compat21 dists, along with doing a ``pkg_add -r XFree86-aoutlibs''. The Tk is 8.0.5. Here's what I get: dmaddox SimCity Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 Actually you're probably getting farther than I am. I believe I'm bombing so early in starting Tk, I'm not really getting to the point you are. What does `ldd /usr/local/lib/SimCity/res/sim'' report? res ldd sim sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) res Also, it looks to me like SimCity would probably run just fine for you if you started X on an 8-bit display... Maybe, but I'm not going to dink with my X server config. ;-) Mabye I'll try to find another box to try this on. Heh :) You don't have to dink around with your config... Just do 'startx -- -bpp 8'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 05:09:45AM -0500, Donald J . Maddox wrote: res ldd sim sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) res Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. Heh :) You don't have to dink around with your config... Just do 'startx -- -bpp 8'. You assume I'm using an XFree86 server ;-) -- I am not. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 02:24:26AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 05:09:45AM -0500, Donald J . Maddox wrote: res ldd sim sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) res Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. Ok, I'll try that now... Heh :) You don't have to dink around with your config... Just do 'startx -- -bpp 8'. You assume I'm using an XFree86 server ;-) -- I am not. How can you be using the same X libs as me, and not be using XFree86? And if you're not, doesn't that put a crimp in your testing? ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Interesting. After I installed the XFree86-aoutlibs port, SimCity works fine for me (on an 8-bit display)... It didn't work with the X libs built by the port when aout libs are requested, and it didn't work with the X libs from 3.3.6, but it works with these. Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wednesday, 20th December 2000, "David O'Brien" wrote: On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: This has been broken for new users for some time. :-( Those of us upgrading from source have been immune to this problem, because we retain the old a.out ld.so binary. /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 When errno became a function that returns a pointer (previously it was a simple integer variable), recompiled libraries became incompatable with old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. Well, Nate called it a horrible hack, so maybe I should say "the hack was in 3.0". src/lib/libc/sys/__error.c suggests this was the case for 2.2.7+. No, you want rev 1.10 of sys/sys/errno.h. That was when it affected all a.out binaries. Until then it was just threaded binaries, a vanishingly small proportion. Rev 1.10 was in 3.0. Rev 1.5 was in the 2.2.x releases. What is out of sync is the X11 a.out libs. They are probably built on a 2.2.7 or 2.2.8 box, thus they refer to `___error' vs. `errno'. These libs are wrong for the SimCity binary. They are a.out yes, but not proper for compat20 use. Since SimCity needs `libgcc.so.261', I'll assume it was built that long ago. Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. The problem isn't as much ld.so, as it should match the libc.so, et.al. you are using from the compat2[01] dist (needed to satisfy ``ldd lib/SimCity/res/sim''). And `ld.so' and the shared libs would be consistent on the system the a.out program was built on. There was an enormous thread in -current (I think) at the time (mid 1998). The end result was that the ld.so hack was the only solution other than mandating a major bump to every library in existence. Nobody liked either of those solutions :-) but I put the ld.so hack in and the problem disappeared. Emphasis again: the workaround ld.so was only found in 3.0 and onward, so just using a 2.2.x ld.so isn't enough. What I would feel most comfortable with, is doing a MFC to RELENG_2_2 of the rtld-aout changes since then, building a new `ld.so' and putting that in the compat2? dists. Problem is I don't have access to a 2.2-STABLE box. I have built a binary on 4.2-RELEASE. I think I prefer that because any security fixes in libc (or whatever) will be reflected in the resulting ld.so. In fact, I think we should build ld.so from source until such time as a.out building capability is removed (5.0 perhaps). On the other hand, merging back to 2.2.x and rebuilding should provide a working (and hack enabled) ld.so that has no more problems than the old binaries it is supporting. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at rev 1.1. So there has been no change to them over the lifetime of their existence. All three are identical -- having the same MD5 checksum. Well, looking at the release tags compat22/ld.so was in 3.2. compat2[01]/ld.so was added for 3.3. This very fact is bothering me a lot. Get out your 3.2 disks and verify that they do not match these uuencoded binaries. Check the 3.0 and 3.1 disk 2 (live file system) and see that they don't match them either. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Not quite. I seem to remember that JKH was makeing a tarball of a.out libs from what ever was on his box at the time (thus probably the last a.out ld.so just before E-day on 3-CURRENT). Something like this must have happened up to and including the 3.2 release. When I committed the compat2? bits, I took ld.so from a 2.2.x release as this is the compat2? dist, not compat3.aout dist. Which is what you're suggesting should have been done. You missed the fact that fixes were added to ld.so after those releases even though the purpose of ld.so is to run binaries that date from those releases. The existence of later, recompiled libraries requires this. Stephen. PS In just a few hours, I'll be out of the picture for 4 or 5 days. I hope I've given you a complete understanding of the situation in the event that I don't get to commit anything. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the
Re: Is compatibility for old aout binaries broken?
On Wednesday, 20th December 2000, "Donald J . Maddox" wrote: Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. Interesting. After I installed the XFree86-aoutlibs port, SimCity works fine for me (on an 8-bit display)... It didn't work with the X libs built by the port when aout libs are requested, and it didn't work with the X libs from 3.3.6, but it works with these. If the XFree896-aoutlib libraries are old enough, they will not call ___error. That is sufficient to solve your particular problem, but not to solve the general case. I'm now wondering if the reason that people don't like the XFree86 3.3.6 a.out libraries is the problem with ___error and the older ld.so supplied with recent FreeBSD releases. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote: Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. Why is not changing the XFree86-aoutlibs port to offer libs built on 2.2.x not the right fix? Emphasis again: the workaround ld.so was only found in 3.0 and onward, so just using a 2.2.x ld.so isn't enough. I am very uncomfortable putting in a ld.so built on 3.0 into the compat2? dists. I'm painfully aware of all the un-thought of issues that can come up when changing dynamic linking methods, etc.. just look at the two opposing threads in the past month about how to handle libcc and dynamic [and threaded] libs and binaries. In fact, I think we should build ld.so from source until such time as a.out building capability is removed (5.0 perhaps). Fine BUT IT ISN'T compat2?. PLEASE think about the issues for a moment. You are mixing bits that are not consistent. Maybe it fixes this one case, but what about all the other cases. What we need to do is offer a.out bits so users can duplicate the system the binary was built on. 4.2 a.out bits != 2.2.x a.out bits. There are two issues here -- binary format (a.out vs. ELF), _and_ library versions. On the other hand, merging back to 2.2.x and rebuilding should provide a working (and hack enabled) ld.so that has no more problems than the old binaries it is supporting. And is consistent with the binaries and libs of that release. Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at rev 1.1. So there has been no change to them over the lifetime of their existence. All three are identical -- having the same MD5 checksum. Well, looking at the release tags compat22/ld.so was in 3.2. compat2[01]/ld.so was added for 3.3. This very fact is bothering me a lot. Get out your 3.2 disks and verify that they do not match these uuencoded binaries. Check the 3.0 and 3.1 disk 2 (live file system) and see that they don't match them either. I'm sure they don't -- I just wrote above I didn't add ld.so to the compat2? dists until 3.2 and 3.3. So of course the 3.0 and 3.1 a.out bits are different. You missed the fact that fixes were added to ld.so after those releases even though the purpose of ld.so is to run binaries that date from those releases. The existence of later, recompiled libraries requires this. No, you're missing the fact that these are comat2? bits, not a.out bits. If you want 3.x a.out bits then a compat3x.aout dist should be created. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 10:14:09AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote: Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. Why is not changing the XFree86-aoutlibs port to offer libs built on 2.2.x not the right fix? I was under the impression that this was already the case... The libs in the XFree86-aoutlibs port ARE from 2.2.x. My problem was that I was using libs built on 3.x. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 05:28:45AM -0500, Donald J . Maddox wrote:
Heh :) You don't have to dink around with your config... Just do
'startx -- -bpp 8'.
You assume I'm using an XFree86 server ;-) -- I am not.
How can you be using the same X libs as me, and not be using
XFree86?
XFree86 has many components to it -- binaries (such as Xterm), libs (such
as libX11.{so,a}, and X servers. I use all the XFree86 bits except for
the X server. I use a mix of Metrolink's and Xi Graphics servers.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 10:43:39AM -0800, David O'Brien wrote:
On Wed, Dec 20, 2000 at 05:28:45AM -0500, Donald J . Maddox wrote:
How can you be using the same X libs as me, and not be using
XFree86?
XFree86 has many components to it -- binaries (such as Xterm), libs (such
as libX11.{so,a}, and X servers. I use all the XFree86 bits except for
the X server. I use a mix of Metrolink's and Xi Graphics servers.
I see. I was thinking that the Xserver would need to use the installed
X libs, but I see that is not the case, even with XF86:
dmaddox ldd /usr/X11R6/bin/XF86_SVGA
/usr/X11R6/bin/XF86_SVGA:
libxpg4.so.3 = /usr/lib/libxpg4.so.3 (0x2830b000)
libz.so.2 = /usr/lib/libz.so.2 (0x2830d000)
libm.so.2 = /usr/lib/libm.so.2 (0x2831a000)
libc.so.5 = /usr/lib/libc.so.5 (0x28336000)
dmaddox
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wednesday, 20th December 2000, "Donald J . Maddox" wrote: On Wed, Dec 20, 2000 at 10:14:09AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote: Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. Why is not changing the XFree86-aoutlibs port to offer libs built on 2.2.x not the right fix? I was under the impression that this was already the case... The libs in the XFree86-aoutlibs port ARE from 2.2.x. My problem was that I was using libs built on 3.x. (I think I can save a lot of typing by replying to this message. I'm just about to leave town.) My whole point is that generating a.out binaries and libraries didn't stop the instant that 3.0 hit the streets. To support the mixture of old binary plus new library you need a hacked ld.so. We have to supply it somehow, or simply say we don't care about certain binaries dying with obscure error messages. This XFree86-aoutlibs vs libs built on 3.x example supports my theme. I can't reconcile your naming convention (ie compat22 bits originated on a 2.2.x box) with my version (compat22 is used to support 2.2.x binaries). I'm also not afraid that a binary generated on 4.2 would have hidden defects. I'm more worried that one generated on 2.2.x would have defects we've forgotten about. If you don't mind pausing the whole argument for about 4 days, I can rejoin. :-) Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 02:05:20AM -0800, Jeremy Lea wrote: Hi, On Wed, Dec 20, 2000 at 01:52:23AM -0800, David O'Brien wrote: Nope. This is a box that was a virgin install of 5-CURRENT a month ago. I had to install the compat20 and compat21 dists, along with doing a ``pkg_add -r XFree86-aoutlibs''. The Tk is 8.0.5. The XFree86-aoutlibs are especially from XFree86-3.3.3. This was because of unstable behaviour from Netscape with later aout libs. They are obtained from: ftp://ftp.xfree86.org/pub/XFree86/3.3.3/binaries/FreeBSD-2.2.x/Xbin.tgz Argh. I'm going to have to mark that port FORBIDDEN, then, because old versions of the X libraries have remote vulnerabilities. Kris PGP signature
Re: Is compatibility for old aout binaries broken?
Hi, On Wed, Dec 20, 2000 at 07:13:05PM -0800, Kris Kennaway wrote: Argh. I'm going to have to mark that port FORBIDDEN, then, because old versions of the X libraries have remote vulnerabilities. Hmmm... Are there patches available to just fix the security problems? We can't move much beyond 3.3.3 because Netscape's released aout binaries have workarounds for bugs from before then, which cause them to be unstable when those bugs are fixed. Else, I guess we are stuck with netscape-linux or mozilla... And people keep breaking mozilla... Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 07:13:05PM -0800, Kris Kennaway wrote: Argh. I'm going to have to mark that port FORBIDDEN, then, because old versions of the X libraries have remote vulnerabilities. Hmmm... Are there patches available to just fix the security problems? We can't move much beyond 3.3.3 because Netscape's released aout binaries have workarounds for bugs from before then, which cause them to be unstable when those bugs are fixed. Maybe we should find out who the good guy is that is building the FreeBSD versions of Netscape and help him upgrade his version of FreeBSD or get him a new machine with FreeBSD 4.2 on it? Else, I guess we are stuck with netscape-linux or mozilla... And people keep breaking mozilla... Well there is the bsdi version too... John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Monday, 18th December 2000, "Donald J . Maddox" wrote: On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote: I expected some build tool expert to say "Just compile with these options". But they haven't. So I'll see if the bits have rotted, or whether we can keep building ld.so instead of just including an age old binary. Well, if you do manage to uncover the lost magic, please let me know :) It's getting a little more magic every day to generate a.out stuff, but not all that bad. Basically I built lib/csu/i386, gnu/lib/libgcc, lib/libc and libexec/rtld-aout, in order, with these settings: NOMAN=yup DESTDIR="" OBJFORMAT=aout MAKEOBJDIRPREFIX=/usr/obj/aout In each directory, I used make obj, make, make install. (By the way, there are a lot of twisty little passages in /usr/share/mk. One of them required me to add DESTDIR="", which should be a NOP.) The generated ld.so has bloated a bit :-) but works fine. So we could in principle build ld.so for every release. It's just a question of whether we should. I think we should. But it might be just as easy to copy it off the 3.3 CD every time. It's dead end stuff after all. Does the release engineer have an opinion? Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tuesday, 19th December 2000, Stephen McKay wrote: But it might be just as easy to copy it off the 3.3 CD every time. Oops! As I wrote earlier, 3.3 and onward have the broken ld.so. Good copies are found on 3.0 though to 3.2. Sorry for veering off the road there. :-) Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote: So we could in principle build ld.so for every release. I would say "no". The building of a.out bits is getting harder as more and more framework pieces are removed. I don't quite fully understand the problem yet. Do you have a binary that shows the problem other than SimCity from a 3.x release CDROM? I don't have any 3.x CDROMs any more, so I'd have to wait a while until I can find one at the office. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
You don't need a CDROM... You can get it from: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/commerce/games/SimCity/SimCity-3.6b.tgz On Mon, Dec 18, 2000 at 10:03:15AM -0800, David O'Brien wrote: On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote: So we could in principle build ld.so for every release. I would say "no". The building of a.out bits is getting harder as more and more framework pieces are removed. I don't quite fully understand the problem yet. Do you have a binary that shows the problem other than SimCity from a 3.x release CDROM? I don't have any 3.x CDROMs any more, so I'd have to wait a while until I can find one at the office. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
The generated ld.so has bloated a bit :-) but works fine. So we could in principle build ld.so for every release. It's just a question of whether we should. I think we should. But it might be just as easy to copy it off the 3.3 CD every time. It's dead end stuff after all. Does the release engineer have an opinion? If it's just for the compat3x distribution, I say check it into that part of lib/compat and be done with it. Uudecoding it each time is a lot easier than building it. Or are we talking about ld.so in some different context? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Monday, 18th December 2000, Jordan Hubbard wrote: The generated ld.so has bloated a bit :-) but works fine. So we could in principle build ld.so for every release. It's just a question of whether we should. I think we should. But it might be just as easy to copy it off the 3.3 CD every time. It's dead end stuff after all. Does the release engineer have an opinion? If it's just for the compat3x distribution, I say check it into that part of lib/compat and be done with it. Uudecoding it each time is a lot easier than building it. Or are we talking about ld.so in some different context? I hadn't noticed all the uuencoded things in lib/compat before. This is obviously the way to fix it. By the way, it's the compat22 distribution that needs fixing, and, as previously noted, it's the 3.2 CD that has the last fully working ld.so. I'll get onto committing a fix. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tue, Dec 19, 2000 at 03:08:25PM +1000, Stephen McKay wrote: Our current problem is that an older ld.so has somehow been made part of compat22. I'm now attempting to determine whether the ld.so on the 3.2 CD contains the fix in rev 1.57 of rtld-aout/rtld.c, and if so I'll just commit it in the compat22 directory. Please delay committing -- since it is UUENCODED, it is a bit repo bloat if we don't get it right. It doesn't seem right to put 3.x bits into the compat22 dist. By definition they are the wrong bits. My internet connection is down for the past day, and I only have limited connectivity right now. But I would like to look into this before anything is committed. - -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Saturday, 16th December 2000, "Donald J . Maddox" wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... You and I may be the only people in the world that run old binaries. This has been broken for new users for some time. :-( Those of us upgrading from source have been immune to this problem, because we retain the old a.out ld.so binary. /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 When errno became a function that returns a pointer (previously it was a simple integer variable), recompiled libraries became incompatable with old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. Well, Nate called it a horrible hack, so maybe I should say "the hack was in 3.0". Am I overlooking something obvious here, or is something actually broken with respect to running old aout binaries? I found that rtld-aout won't compile. That's kinda broken. (It's probably something simple. Looks like the a.out version of a pic library just isn't around any more). I'll try harder later. What's certain is that it isn't compiled by default. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Ideally, rtld-aout would be compiled fresh for every release. Until then, you can repair your system by retrieving ld.so from a 3.3 CD (in the compat22 section), or from a 3.2 live filesystem CD. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Ok, thanks for a very enlightening explanation :) Under the circumstances, it seems silly to have aout conpat bits installed at all, seeing as how they cannot work. Like you, I normally upgrade from source -- This box has been -current ever since 2.0.5 or so was -current, but I had to reinstall from scratch a while back by installing 4.2-RELEASE and then cvsupping back to -current, so I guess I lost my working aout ld.so in the process. Bummer :( On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: On Saturday, 16th December 2000, "Donald J . Maddox" wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... You and I may be the only people in the world that run old binaries. This has been broken for new users for some time. :-( Those of us upgrading from source have been immune to this problem, because we retain the old a.out ld.so binary. /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 When errno became a function that returns a pointer (previously it was a simple integer variable), recompiled libraries became incompatable with old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. Well, Nate called it a horrible hack, so maybe I should say "the hack was in 3.0". Am I overlooking something obvious here, or is something actually broken with respect to running old aout binaries? I found that rtld-aout won't compile. That's kinda broken. (It's probably something simple. Looks like the a.out version of a pic library just isn't around any more). I'll try harder later. What's certain is that it isn't compiled by default. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Ideally, rtld-aout would be compiled fresh for every release. Until then, you can repair your system by retrieving ld.so from a 3.3 CD (in the compat22 section), or from a 3.2 live filesystem CD. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Sunday, 17th December 2000, "Donald J . Maddox" wrote: Under the circumstances, it seems silly to have aout conpat bits installed at all, seeing as how they cannot work. Old programs that don't depend on recompiled libraries are fine. I can't guess at the percentages though. Also, nearly everybody has recompiled for elf, where this problem never occurred. Like you, I normally upgrade from source -- This box has been -current ever since 2.0.5 or so was -current, but I had to reinstall from scratch a while back by installing 4.2-RELEASE and then cvsupping back to -current, so I guess I lost my working aout ld.so in the process. Bummer :( I expected some build tool expert to say "Just compile with these options". But they haven't. So I'll see if the bits have rotted, or whether we can keep building ld.so instead of just including an age old binary. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Well, if you do manage to uncover the lost magic, please let me know :) On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote: I expected some build tool expert to say "Just compile with these options". But they haven't. So I'll see if the bits have rotted, or whether we can keep building ld.so instead of just including an age old binary. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Is compatibility for old aout binaries broken?
The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 # ldd sim ./sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) So, all the necessary compatibility libraries are there, but it fails anyway. I tried 'nm | grep error' on the sim binary and libX11.so.6.1 and didn't find any symbol, undefined or otherwise, by that name... Am I overlooking something obvious here, or is something actually broken with respect to running old aout binaries? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
