gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.


From: Sebastian Reitenbach
Subject: Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m
Date: Tue, 06 Mar 2012 08:23:47 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

On 03/05/2012 10:10 AM, Riccardo Mottola wrote:
Hi,

On 03/01/12 10:09, Richard Frith-Macdonald wrote:
On 1 Mar 2012, at 08:08, Gregory Casamento wrote:


The NSData archiving change is backward compatible and don't need a new version. The archive format is not backward compatible, but we already bumped the archive version format to handle that.

Riccardo's problem seems to be a Gorm file with a corrupt/incorrect archive version number somehow (it seems to have a version of 40000, when the archive version in base has only just been bummed up to 12402).
I don't know what's going on there.
I can shed some light here:

the "4.0" version is a file version after an edit by Sebastian. So there is soemthing strange on his gnustep version (architecture? endianness? compiler? architecture?).

I retrieved the version before, created by me. It contains 1.25 which was I think a temporary version of base, still equivalent to 1.23. I edited it manually to 1.23 and it works. I will thus for now revert to the older gorm file and patch the file manually to work around the problem. But the bogus version of Sebastian needs to be investigated I think.

After an off-list discussion with Fred, I think I know know where the version 4.0 comes from. In the OpenBSD gnustep-base Ports Makefile, we have the following statement:

pre-configure:
    @perl -pi -e
's,^MAJOR_VERSION=.*,MAJOR_VERSION=${LIBgnustep-base_VERSION:R},g;' \ -e 's,^MINOR_VERSION=.*,MINOR_VERSION=${LIBgnustep-base_VERSION:E},g' \
                ${WRKSRC}/Version

Actually intended to set the INTERFACE_VERSION of the installed libgnustep-base.so to libgnustep-base.so.4.0. This also seems to have the bad side effect of changing the NSCoder version. This is done for years now, and is already there from before I took over the maintainership of the GNUstep ports on OpenBSD. Since it worked well for the intended use, I didn't cared much about it. with other ports, I usually set the version using <LIBNAME>_INTERFACE_VERSION as a make flag when compiling. I'll try that too with gnustep-base, just need to find some time to do so.

There don't seem to be anyone using Gorm on OpenBSD from the packages. I'd guess, otherwise, the problem would have shown up much earlier. Therefore I'm not sure, whether there is a real need to fix that in -base. But I definitely
should fix it in the Ports/Packages.

cheers,
Sebastian





Riccardo

_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]