Sébastien Marie <semarie-open...@latrappe.fr> writes: > Hi, > > I start to look at lang/chicken in ports. Currently it is near 6 years > old. > > But I encourter the following problem: chicken generate and use a shared > lib with only a major number for the version (lib/libchicken.so.6 from > upstream). It is the "BINARYVERSION=6" in defaults.make file. It is > also used in directory name for extensions (some are provided by > default): lib/chicken/6 . > > 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). > > But 2.0 casted to integer is 2... so I couldn't satisfy OpenBSD > requirement (major+minor) without patching chicken to do the program use > a string instead of an integer. Am I right, here ? > > *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 ?) > > - does exist a possibility in ports to first build something before > patching ? > > - does it possible to keep BINARYVERSION as integer ? According to the > 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).") > > But SHARED_LIBS doesn't seems support major only version > (make update-plist isn't agreed) . > > - another solution ? > > > I join my current diff of the ports. > > 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) ? > > Thanks.
Hi, I've had WIP port of chicken in the openbsd-wip tree for a while: https://github.com/jasperla/openbsd-wip/tree/master/lang/chicken I haven't yet found a way to properly address the shared library version. The installed version number is correct in the port but the deployment doesn't work. It still uses the old binary version. If I modify csc.scm copy-libraries function to use ".6.0" then the build fails. I didn't notice anything else wrong in my port. Timo
