Re: Specifying private repository path for compiled executables
On Thu, Dec 04, 2025 at 07:08:01AM +0100, Kristian Lein-Mathisen wrote: > Hi Peter, > > Are we talking about the csc -static option? Doesn't this only link all > eggs statically, and not their foreign dependencies (libc, libsqlite3 etc)? Good point. I was implicitly assuming we were talking fully static builds (ie, with -static -L -static). > From what I gather, even if you do csc -static, you'll get system updates > for foreign dependencies. Just not any automatic egg updates. I think you're right there. @Alexey: Maybe this an acceptable solution for you after all? Cheers, Peter
Re: Specifying private repository path for compiled executables
Hi Peter, Are we talking about the csc -static option? Doesn't this only link all eggs statically, and not their foreign dependencies (libc, libsqlite3 etc)? >From what I gather, even if you do csc -static, you'll get system updates for foreign dependencies. Just not any automatic egg updates. K. On Thu, Dec 4, 2025, 04:14 Peter Bex via Chicken-users < [email protected]> wrote: > On Thu, Dec 04, 2025 at 12:31:42AM +0300, Alexey Egorov via Chicken-users > wrote: > > > What is it that you don't like in the static linking solution? > > > > Uh, that was not ideal choice of words. I don't dislike static > > linking, in fact I > > prefer it for simplicity, stability and general ease of use. > > > > The full story is, I want to package my software, some distros (e.g. > Gentoo) > > discourage the use of static linking for security reasons, and while > it's not > > forbidden to do so, I'd like to follow the guidelines as closely as > possible. > > I always thought those same distro guidelines also preferred to use > centralized installation of dependencies. For example, in Debian if > you install something like, say, Django it'll install python3-pytz, > python3-python3-yaml etc in the system-wide package location. > This also basically means you can only have one copy of each Python > package installed. > > Accepted best practices for Python software usually involves setting up > a virtualenv and installing it locally in the directory of a project so > you can control the exact python packages and don't run into dependency > hell due to clashes with the system-wide package, but distros completely > disregard these best practices for ease of packaging and (like you say) > security - upgrading one library fixes the security of all Python > programs relying on that library. > > I don't know Arch that well, but from a quick look at > https://archlinux.org/packages/extra/any/python-django/ it seems to > behave identically to Debian in this regard. > > So if you do decide to deviate from this practice with your CHICKEN > programs, I would suggest static linking of eggs is not meaningfully > different. The only benefit you'd get from dynamic linking in a > custom location is that you'd be able to get security updates for the > system C libraries the eggs in your program depend on. But if the eggs > themselves get a security update, your program would not automatically > benefit from that. > > Cheers, > Peter > >
Re: Specifying private repository path for compiled executables
On Thu, Dec 04, 2025 at 12:31:42AM +0300, Alexey Egorov via Chicken-users wrote: > > What is it that you don't like in the static linking solution? > > Uh, that was not ideal choice of words. I don't dislike static > linking, in fact I > prefer it for simplicity, stability and general ease of use. > > The full story is, I want to package my software, some distros (e.g. Gentoo) > discourage the use of static linking for security reasons, and while it's not > forbidden to do so, I'd like to follow the guidelines as closely as possible. I always thought those same distro guidelines also preferred to use centralized installation of dependencies. For example, in Debian if you install something like, say, Django it'll install python3-pytz, python3-python3-yaml etc in the system-wide package location. This also basically means you can only have one copy of each Python package installed. Accepted best practices for Python software usually involves setting up a virtualenv and installing it locally in the directory of a project so you can control the exact python packages and don't run into dependency hell due to clashes with the system-wide package, but distros completely disregard these best practices for ease of packaging and (like you say) security - upgrading one library fixes the security of all Python programs relying on that library. I don't know Arch that well, but from a quick look at https://archlinux.org/packages/extra/any/python-django/ it seems to behave identically to Debian in this regard. So if you do decide to deviate from this practice with your CHICKEN programs, I would suggest static linking of eggs is not meaningfully different. The only benefit you'd get from dynamic linking in a custom location is that you'd be able to get security updates for the system C libraries the eggs in your program depend on. But if the eggs themselves get a security update, your program would not automatically benefit from that. Cheers, Peter
Re: Specifying private repository path for compiled executables
> On 2 Dec 2025, at 18:02, Alexey Egorov via Chicken-users > wrote: > > Hello Chicken users! > > I have a program suite written in Chicken, which uses a number of > eggs, and I want to be able to distribute it without relying on user > to install all eggs by hand. ... > I understand that my options in this case is either link the binary > statically, or provide -private-repository flag and put all the eggs' > dynamic libs beside my binaries. The first solution I just don't like > very much. What is it that you don't like in the static linking solution? -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos. smime.p7s Description: S/MIME cryptographic signature
Re: Specifying private repository path for compiled executables
On Tue Dec 2, 2025 at 6:00 PM CET, Alexey Egorov via Chicken-users wrote: > > One possible solution occurred to me: what if we could have a way to > set -private-repository not only to the location of the compiled > binary, but to an arbitrary location? I tried to implement this in > form of new flag -private-repository-path, and it seems to work for my > case. > This is interesting, give me some time to evaluate this. > All that said, I still have some questions: > 1. Isn't there some more obvious already existing way to do what I > want, which I overlooked? No, your analysis is quite correct. > 2. Doesn't the solution I devised break anything? At the first glance > it doesn't but I still can be missing something obvious Since this is enabled with a simple C macro, it doesn't look particularly disruptive to me, so it may be a viable feature to add. cheers, felix
Re: Specifying private repository path for compiled executables
Hi! IMO it's an interesting movement in the way of isolation of chicken hosts. Not for deployment, at least for me, I strongly prefer static builds for sw distribution. P.S. Every time I build a new Py and insert it in to PATH, all my venv.s turns into potato. вт, 2 дек. 2025 г. в 20:02, Alexey Egorov via Chicken-users < [email protected]>: > Hello Chicken users! > > I have a program suite written in Chicken, which uses a number of > eggs, and I want to be able to distribute it without relying on user > to install all eggs by hand. Or to install them at all, since user's > Chicken environment is mainly aimed for development and should not be > affected by third party software that only uses Chicken, without > providing any Chicken functionality itself. > > I understand that my options in this case is either link the binary > statically, or provide -private-repository flag and put all the eggs' > dynamic libs beside my binaries. The first solution I just don't like > very much. > The -private-repository flag, which enables compiled binaries to load > extensions from the directory where the binary is located, which is > not ideal, since in case of manual installation I'd like to have my > binaries in /bin and libs in /var/lib or /usr/lib or something like > that. > > One possible solution occurred to me: what if we could have a way to > set -private-repository not only to the location of the compiled > binary, but to an arbitrary location? I tried to implement this in > form of new flag -private-repository-path, and it seems to work for my > case. > > I also think that a general solution for creating Chicken environments > (analogous to e.g. Python's venv) can be based on this. > > All that said, I still have some questions: > 1. Isn't there some more obvious already existing way to do what I > want, which I overlooked? > 2. Doesn't the solution I devised break anything? At the first glance > it doesn't but I still can be missing something obvious > > The patch with -private-repository-path for Chicken 5.4.0: > diff --git a/chicken.h b/chicken.h > index d0d6be20..3ad33235 100644 > --- a/chicken.h > +++ b/chicken.h > @@ -1566,10 +1566,14 @@ typedef void (C_ccall *C_proc)(C_word, C_word > *) C_noret; > #define C_ub_i_pointer_f32_set(p, n)(*((float *)(p)) = (n)) > #define C_ub_i_pointer_f64_set(p, n)(*((double *)(p)) = (n)) > > -#ifdef C_PRIVATE_REPOSITORY > -# define C_private_repository() > C_use_private_repository(C_executable_dirname()) > +#ifdef C_PRIVATE_REPOSITORY_PATH > +# define C_private_repository() > C_use_private_repository(C_text(C_PRIVATE_REPOSITORY_PATH)) > #else > -# define C_private_repository() > +# ifdef C_PRIVATE_REPOSITORY > +# define C_private_repository() > C_use_private_repository(C_executable_dirname()) > +# else > +# define C_private_repository() > +# endif > #endif > > #ifdef C_GUI > diff --git a/csc.scm b/csc.scm > index 1fe896b7..ee3bdfeb 100644 > --- a/csc.scm > +++ b/csc.scm > @@ -507,7 +507,8 @@ Usage: #{csc} [OPTION ...] [FILENAME ...] > -host compile for host when configured for > cross-compiling > -private-repositoryload extensions from executable path > --deployed link support file to be used from a > deployed > +-private-repository-path PATH load extensions from PATH > +-deployed link support file to be used from a > deployed > executable (sets `rpath' > accordingly, if supported > on this platform) > -no-elevation embed manifest on Windows to > supress elevation > @@ -553,6 +554,9 @@ EOF >(define (use-private-repository) > (set! compile-options (cons "-DC_PRIVATE_REPOSITORY" > compile-options))) > > + (define (use-private-repository-path path) > +(set! compile-options (cons (sprintf > "-DC_PRIVATE_REPOSITORY_PATH=\"~A\"" path) compile-options))) > + >(define (generate-target-filename source-filename) > (pathname-replace-extension > source-filename > @@ -687,6 +691,10 @@ EOF > (set! rest (cdr rest)) ] > ((-private-repository) > (use-private-repository)) > + ((-private-repository-path) > +(check s rest) > +(use-private-repository-path (car rest)) > +(set! rest (cdr rest))) > ((-ignore-repository) > (set! ignore-repository #t) > (t-options arg)) > -- > >
