On 2013/04/22 06:48, Sébastien Marie wrote:
> According to the ports guide, porters should rewrites the library
> version to correctly keep track of ABI changes.
>
> My problem is chicken expects BINARYVERSION to be an integer, and use it
> as integer for:
> - found the library when deploying application (copy the file in a
> target directory)
> - use it in extensions-directory-name (lib/chicken/6/...) when managing
> extensions (install an extension as unprivilegied user).
So BINARYVERSION is used for 2 different things; I think this will
probably need to be split so the .so version can be something different
from the integer used for extension directory name etc.
> *But*, patching chicken is patching scheme source. And need
> first bootstrapping chicken... The upstream tarball contains scheme
> source + compiled-c-files, and offer the possibility to bootstrap the
> compiler first.
>
> But if I patch scheme files before building chicken-boot (the
> bootstrapping compiler), the makefile wants to regenerate C file
> (whereas the bootstrapping compiler is not yet here).
>
> So how to achieve this ?
> - have another port lang/chicken-boot (only used in BUILD_DEPENDS of
> lang/chiken) ? (or hierarchy like lang/chicken/boot for bootstrap and
> lang/chiken/stable for stable release ?)
Not sure if this is the best way but it's technically possible.
Other compilers (ghc, jdk, gnats) use bootstrap tarballs generated
outside the main ports build (normally we set things up so this
bootstrap can be built by a maintainer target in the port Makefile).
> - does exist a possibility in ports to first build something before
> patching ?
>
> - does it possible to keep BINARYVERSION as integer ? According to the
In OpenBSD shared libraries have major+minor, unless they are only used
with dlopen(), in which case they can be unversioned. So this will
need patching.
> chicken wiki, they take care to do the right thing with version
> number: "Changes that break C-level compatibility (for example by
> modifying the signature of an exported C routine) will require
> bumping up the "binary compatibility version" (BINARYVERSION in
> defaults.make).")
They can only do this for things under their control, but ABI changes
can also be caused by a change to the OS itself. If (for example)
some very common typedef was changed in the OS, we might need to bump
major versions of *every* shared library in the system.
> And a other question: the chicken Makefile contains a check for OpenBSD
> to remove a gcc option: "OpenBSD base still uses GCC 3.3.5 which does
> not support -fwrapv". Does OpenBSD still have somes archs with GCC
> 3.3.5 (or that don't support -fwrapv option) ?
Ys, from /usr/ports/infrastructure/arch-defines.mk:
GCC4_ARCHS = alpha amd64 arm armish beagle i386 hppa hppa64 \
landisk loongson macppc mips64 mips64el mvmeppc octeon \
powerpc sgi sh socppc sparc sparc64 zaurus
GCC3_ARCHS = aviion hp300 luna88k m68k m88k mvme68k mvme88k
GCC2_ARCHS = vax
