4.8-R libc stdio backward binary compatibility

4.8-R libc stdio backward binary compatibility

Post by Carl Mascot » Tue, 08 Apr 2003 05:34:46



I don't quite understand the following from the 4.8-R release notes:

Quote:> The definitions of the standard file streams (stdin, stdout, and stderr)
> have changed so that they are no longer compile-time constants.
> Some older binaries may require updated 3.X compatability libraries
> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

If I have a dynamically linked binary from 4.7-R or an earlier 4.x and the code
references stdin, will that binary work with the native libc on 4.8-R?  Or do
I need the compat4x libraries?

I have something that I can't recompile (no source).

--
Carl Mascott

If replying by e-mail please correct my address.

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Kris Kennawa » Tue, 08 Apr 2003 09:00:02



> I don't quite understand the following from the 4.8-R release notes:

>> The definitions of the standard file streams (stdin, stdout, and stderr)
>> have changed so that they are no longer compile-time constants.
>> Some older binaries may require updated 3.X compatability libraries
>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

> If I have a dynamically linked binary from 4.7-R or an earlier 4.x and the code
> references stdin, will that binary work with the native libc on 4.8-R?  Or do
> I need the compat4x libraries?

You just need to install the compat4x libraries.

Kris

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Carl Mascot » Wed, 09 Apr 2003 06:57:39


Your answer seemed logical until I looked at 4.8-R compat4x.  There's no libc
in there.  There's just libcrypto, libfetch and libssl.

Also, the release notes are incorrect: std{in,out,err} were not compile-time
constants.  They were address expression rvals whose values were determined at
run-time link fix-up.  Now they are pointer variable lvals.

Has anybody verified that a 4.7-R (or earlier 4.x) dynamically linked binary
that references std{in,out,err} actually works on 4.8-R?  (I don't have 4.8-R
yet.)




>> I don't quite understand the following from the 4.8-R release notes:

>>> The definitions of the standard file streams (stdin, stdout, and stderr)
>>> have changed so that they are no longer compile-time constants.
>>> Some older binaries may require updated 3.X compatability libraries
>>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

>> If I have a dynamically linked binary from 4.7-R or an earlier 4.x and the code
>> references stdin, will that binary work with the native libc on 4.8-R?  Or do
>> I need the compat4x libraries?

>You just need to install the compat4x libraries.

>Kris

--
Carl Mascott

If replying by e-mail please correct my address.
 
 
 

4.8-R libc stdio backward binary compatibility

Post by Erik Nygre » Wed, 09 Apr 2003 16:02:31


[top posting fixed]



>>> I don't quite understand the following from the 4.8-R release notes:

>>>> The definitions of the standard file streams (stdin, stdout, and stderr)
>>>> have changed so that they are no longer compile-time constants.
>>>> Some older binaries may require updated 3.X compatability libraries
>>>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

>>> If I have a dynamically linked binary from 4.7-R or an earlier 4.x and the code
>>> references stdin, will that binary work with the native libc on 4.8-R?  Or do
>>> I need the compat4x libraries?

>>You just need to install the compat4x libraries.

>>Kris

> Your answer seemed logical until I looked at 4.8-R compat4x.  There's no libc
> in there.  There's just libcrypto, libfetch and libssl.

> Also, the release notes are incorrect: std{in,out,err} were not compile-time
> constants.  They were address expression rvals whose values were determined at
> run-time link fix-up.  Now they are pointer variable lvals.

> Has anybody verified that a 4.7-R (or earlier 4.x) dynamically linked binary
> that references std{in,out,err} actually works on 4.8-R?  (I don't have 4.8-R
> yet.)

Anything else would be a very grave infliction on POLA, but just to make
really sure...
I have made a very simple test - i found one of my ports that was easy
enough to use (zip and unzip), and they also was dynamically linked:
bash-2.05a$ ldd /usr/local/bin/zip /usr/local/bin/unzip
/usr/local/bin/zip:
        libc.so.4 => /usr/lib/libc.so.4 (0x28075000)
/usr/local/bin/unzip:
        libc.so.4 => /usr/lib/libc.so.4 (0x2807d000)
bash-2.05a$ uname -a

bash-2.05a$

Reading from stdin worked just the way I would excpect it to, and so did
writing to stdout.

--
Erik Nygren
e r i k { a t } s w i p { d o t } n e t
Linux - If you hate Microsoft, FreeBSD - If you love Unix

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Richard Tob » Wed, 09 Apr 2003 23:14:12




Quote:>> The definitions of the standard file streams (stdin, stdout, and stderr)
>> have changed so that they are no longer compile-time constants.
>> Some older binaries may require updated 3.X compatability libraries
>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).
>If I have a dynamically linked binary from 4.7-R or an earlier 4.x
>and the code references stdin, will that binary work with the native
>libc on 4.8-R?  Or do I need the compat4x libraries?

If I understand correctly - which I'm not sure I do - then you don't
need any compatibility libraries to solve this for 4.x binaries.  You
*do* need new versions of the compat3x libraries if you have old 3.x
binaries (and make sure that you don't have an old "real" libc.so.3 in
/usr/lib which will mask the compatibility one in /usr/lib/compat).

I think -current users needed new compat4x libraries, but that doesn't
apply to you.

-- Richard

--
Spam filter: to mail me from a .com/.net site, put my surname in the headers.

FreeBSD rules!

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Carl Mascot » Thu, 10 Apr 2003 02:03:10





>[top posting fixed]



>>>> I don't quite understand the following from the 4.8-R release notes:

>>>>> The definitions of the standard file streams (stdin, stdout, and stderr)
>>>>> have changed so that they are no longer compile-time constants.
>>>>> Some older binaries may require updated 3.X compatability libraries
>>>>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

>>>> If I have a dynamically linked binary from 4.7-R or an earlier 4.x and the code
>>>> references stdin, will that binary work with the native libc on 4.8-R?  Or do
>>>> I need the compat4x libraries?

>>>You just need to install the compat4x libraries.

>>>Kris

>> Your answer seemed logical until I looked at 4.8-R compat4x.  There's no libc
>> in there.  There's just libcrypto, libfetch and libssl.

>> Also, the release notes are incorrect: std{in,out,err} were not compile-time
>> constants.  They were address expression rvals whose values were determined at
>> run-time link fix-up.  Now they are pointer variable lvals.

>> Has anybody verified that a 4.7-R (or earlier 4.x) dynamically linked binary
>> that references std{in,out,err} actually works on 4.8-R?  (I don't have 4.8-R
>> yet.)
>Anything else would be a very grave infliction on POLA, but just to make
>really sure...
>I have made a very simple test - i found one of my ports that was easy
>enough to use (zip and unzip), and they also was dynamically linked:
>bash-2.05a$ ldd /usr/local/bin/zip /usr/local/bin/unzip
>/usr/local/bin/zip:
>        libc.so.4 => /usr/lib/libc.so.4 (0x28075000)
>/usr/local/bin/unzip:
>        libc.so.4 => /usr/lib/libc.so.4 (0x2807d000)
>bash-2.05a$ uname -a

>bash-2.05a$

>Reading from stdin worked just the way I would excpect it to, and so did
>writing to stdout.

Thanks for trying that.  You didn't say so, but I assume that the unzip and zip
binaries you used were actually built under 4.7-R or earlier.  If they were,
that proves there is no compatibility problem.

I don't understand why there isn't a problem (e.g., reference to undefined
symbol __sF) but I'll wait until I get 4.8-R and examine the source.

--
Carl Mascott

If replying by e-mail please correct my address.

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Carl Mascot » Thu, 10 Apr 2003 02:03:11





>>> The definitions of the standard file streams (stdin, stdout, and stderr)
>>> have changed so that they are no longer compile-time constants.
>>> Some older binaries may require updated 3.X compatability libraries
>>> (for example, by setting COMPAT3X=yes for a buildworld/installworld).

>>If I have a dynamically linked binary from 4.7-R or an earlier 4.x
>>and the code references stdin, will that binary work with the native
>>libc on 4.8-R?  Or do I need the compat4x libraries?

>If I understand correctly - which I'm not sure I do - then you don't
>need any compatibility libraries to solve this for 4.x binaries.  You
>*do* need new versions of the compat3x libraries if you have old 3.x
>binaries (and make sure that you don't have an old "real" libc.so.3 in
>/usr/lib which will mask the compatibility one in /usr/lib/compat).

>I think -current users needed new compat4x libraries, but that doesn't
>apply to you.

>-- Richard

I understand what you said, but I don't understand how the new stdio can be
link-compatible with old application code.  Apparently it is, though.  I'll have
a look at it when I actually get 4.8-R.  Thanks.

--
Carl Mascott

If replying by e-mail please correct my address.

 
 
 

4.8-R libc stdio backward binary compatibility

Post by Erik Nygre » Thu, 10 Apr 2003 19:05:25


...

Quote:> Thanks for trying that.  You didn't say so, but I assume that the unzip and zip
> binaries you used were actually built under 4.7-R or earlier.  If they were,
> that proves there is no compatibility problem.

They where build using some version 4.x of FreeBSD where x is less than or
equal to 7... The date of the file seem to indicate FreeBSD 4.6.2:
bash-2.05a$ ls -l /usr/local/bin/zip
-r-xr-xr-x  1 root  wheel  65496 23 Okt 15:07 /usr/local/bin/zip
bash-2.05a$

Quote:

> I don't understand why there isn't a problem (e.g., reference to undefined
> symbol __sF) but I'll wait until I get 4.8-R and examine the source.

Well, I wouldn't understand this, but I'm sure it works...

--
Erik Nygren
e r i k { a t } s w i p { d o t } n e t
Linux - If you hate Microsoft, FreeBSD - If you love Unix

 
 
 

1. libc.so.4/libc.so.5 binary compatibility

Lowell Gilbert  :

OK, sorry. I am moving to freebsd.misc, and quoting the whole for the
readers of that group.

How does it work actually? I am no elf expert, but I guess terrible things
can happen when two libcs are linked in at the same time, or when a lib
compiled for libc5 is linked with libc4. Or are there no binary
incompatibilities between both libs? Why does the soname change, then?

2. filetype-question

3. Diamond Stealth 2001 problems. HELP!!

4. LUM/libc.a/Binary Compatibility

5. RedHat vs. Slackware

6. backward compatibility between 2.5 and 2.4

7. RedHat inst. stops at fstab step...

8. GLIBC and Backward Compatibility

9. Help: backward compatibility problems with SunOS 5.1

10. C compiler backward compatibility

11. Backward compatibility of linux libraries?

12. Solaris7 backward compatibility question