Problems with shared library version numbers

Problems with shared library version numbers

[Marc Espie]

I had not noticed this before, as I've been building OpenBSD with a local
brew of libstdc++.

Our basic setup only supports libthingy.so.major.minor,
without any further subdivision.

When gcc 2.8.1 was imported, we became committed to libstdc++.so.28.0.
This was before I came aboard OpenBSD, and we can't change that now without
annoying many users.  

Standard policy is that we up major numbers when an incompatible change
occurs, and minor number the rest of the time.
Based on that assumption, I surmise the transition from libstdc++ 2.8.0
to libstdc++ 2.9.0 should have been a major version number change from 
the OpenBSD point of view.

Well, it gets slightly uglier. 

Assume we have to change the size of a critical data structure, such as 
struct stat (such things occurred in the past already, getting uid_t from 16 
to 32 bits, or pid_t and friends).
In theory, already installed systems won't notice a thing, as the development
team will up all version numbers, including libstdc++.

I have written the following openbsd.ml snippet to try and solve the
problem (code not tested yet, there might be a minor syntax problem in it.
More of a concept than actual code)

MAJOR_OFFSET=0
EGCS_MAJOR   = `echo $(VERSION)` | sed 's/([0-9]*)\.([0-9]*).*/\1\2/'`
EGCS_MINOR    = `echo $(VERSION)` | sed 's/.*\.([0-9]+)/\1/'`
MSHLINK = libstdc++.so.`expr $(EGCS_MAJOR)+MAJOR_OFFSET`.$(EGCS_MINOR)


The EGCS_MAJOR/EGCS_MINOR variables get the libstdc++ version number in a
format that conforms to what OpenBSD uses for version numbers.

MAJOR_OFFSET is the define that is, more or less, under OpenBSD control.
Everything should work fine as long as I crank it whenever it is needed
(which shouldn't be too often, probably once every six months on average).

Comments welcome... I'm not very satisfied with the way I've done things,
but this is a real-life problem, and it needs to be solved, unless I want
to go the way H.J.Lu and linux goes, and `prepare' OpenBSD specific egcs
distributions.
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

Re: Problems with shared library version numbers

[Jeffrey A Law]

  In message < 19990228234115.48659@liafa1.liafa.jussieu.fr >you write:
  > I had not noticed this before, as I've been building OpenBSD with a local
  > brew of libstdc++.
[ ... ]
Isn't this the kind of problem the "libstdc++ version patch" is supposed
to solve (which is in the mainline tree, but not egcs-1.1.x)?

jeff

Re: Problems with shared library version numbers

[Jeffrey A Law]

  In message < 19990228234115.48659@liafa1.liafa.jussieu.fr >you write:
  > I had not noticed this before, as I've been building OpenBSD with a local
  > brew of libstdc++.
[ ... ]
Isn't this the kind of problem the "libstdc++ version patch" is supposed
to solve (which is in the mainline tree, but not egcs-1.1.x)?

jeff

Problems with shared library version numbers

[Marc Espie]

I had not noticed this before, as I've been building OpenBSD with a local
brew of libstdc++.

Our basic setup only supports libthingy.so.major.minor,
without any further subdivision.

When gcc 2.8.1 was imported, we became committed to libstdc++.so.28.0.
This was before I came aboard OpenBSD, and we can't change that now without
annoying many users.  

Standard policy is that we up major numbers when an incompatible change
occurs, and minor number the rest of the time.
Based on that assumption, I surmise the transition from libstdc++ 2.8.0
to libstdc++ 2.9.0 should have been a major version number change from 
the OpenBSD point of view.

Well, it gets slightly uglier. 

Assume we have to change the size of a critical data structure, such as 
struct stat (such things occurred in the past already, getting uid_t from 16 
to 32 bits, or pid_t and friends).
In theory, already installed systems won't notice a thing, as the development
team will up all version numbers, including libstdc++.

I have written the following openbsd.ml snippet to try and solve the
problem (code not tested yet, there might be a minor syntax problem in it.
More of a concept than actual code)

MAJOR_OFFSET=0
EGCS_MAJOR   = `echo $(VERSION)` | sed 's/([0-9]*)\.([0-9]*).*/\1\2/'`
EGCS_MINOR    = `echo $(VERSION)` | sed 's/.*\.([0-9]+)/\1/'`
MSHLINK = libstdc++.so.`expr $(EGCS_MAJOR)+MAJOR_OFFSET`.$(EGCS_MINOR)


The EGCS_MAJOR/EGCS_MINOR variables get the libstdc++ version number in a
format that conforms to what OpenBSD uses for version numbers.

MAJOR_OFFSET is the define that is, more or less, under OpenBSD control.
Everything should work fine as long as I crank it whenever it is needed
(which shouldn't be too often, probably once every six months on average).

Comments welcome... I'm not very satisfied with the way I've done things,
but this is a real-life problem, and it needs to be solved, unless I want
to go the way H.J.Lu and linux goes, and `prepare' OpenBSD specific egcs
distributions.
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'