Menu
▾
▴
clisp-devel
|
From: Vibhu M. <vi...@ho...> - 2022-09-26 22:34:18
Attachments:
floatparam.h
floatparam.h.orig
|
System: Windows 10 64-bit, 6 GB RAM Processor: Intel Xeon X5647, x64-based processor Cygwin (64-bit) targetting mingw 32-bit clisp revision: f1aa42219433f019c05e707220538b3634bc233c I've used the instructions in INSTALL.windows. ---- 1. LN_S The Makefile has a variable LN_S that is chosen to be some platform dependent value. LN_S = ln is not a suitable choice, at least for Cygwin targetting mingw 32-bit. The reason is that build-aux is a directory, and hard linking directories is not supported. LN_S = ln -s might be a valid choice, but I don't know if symlinks would cause problems in the resulting native binary, or further in the build. LN_S = cp -p as recommended in some make/config file I can't remember offhand is also not a valid choice as that won't work for directories such as build-aux. LN_S = cp -a is probably a valid choice. I don't think the build ever does: $(LN_S) x y and then changes y expecting changes to be reflected in x. Any tips on how I can reliably override LN_S in all primary and subsidiary make and config files will be most appreciated. My manual editing may not be addressing all required files and may be getting overwritten by some of the build. Does "cp -a" seem a reasonable choice? ---- 2. floatparam.h The generated floatparam.h has an error message at the bottom that looks like it's causing make to fail. So I re-ran the build afresh, but this time immediately after the configure step, I replaced floatparam.h with a copy from another build configuration I had lying around (Cygwin targetting Cygwin 32-bit). Doing that got make further along. Please see attached files: floatparam.h.orig (which is the actual one generated for the mingw32 target build) and floatparam.h (the copy that got me further, taken without good reason from a Cygwin build that targetted Cygwin 32-bit). I'd love to know what I need to do to have configure create a proper floatparam.h directly. (And also what a proper floatparam.h is to begin with, instead of my guessed copy.) Note: I do always remember to start a fresh Cygwin terminal and to set PATH afresh and ulimit -s 16384 afresh. It's not the case that one build interferes with another. ---- Background of what I'm up to: (Please feel free to ignore all this) I'm building the various supported configurations listed in INSTALL.windows. Some errors appear in many configurations. So I'll be careful to try and list/resolve them in a sensible order and always be clear which configuration I'm talking about. I presume nobody's tried most of them in a long time and that they don't work for anybody any more. We know from the other recent thread that one configuration does work now, which is cool. Of the various errors, the two above are good starts, being dependent on none of my other hacks trying to build things. They were produced by following INSTALL.windows to the letter. Here's why I've embarked on this exercise in the first place. I've written a command-line GPL'ed Lisp application for a non-technical neighbour who only uses Windows. I don't know Windows well, but have now got myself access to a Windows system. Besides pure clisp, the application needs :ffi and thus ffcall. The most I can expect of my neighbour is to double-click on an executable. So I'd like to be able to give him a (GPL'ed) application rather than have him download clisp from here, ffcall from there, then merge it all together. That would be beyond him. So I plan to produce a single zip file with the application binary and also all GPL-mandated sources, licences and build instructions. A mingw binary is valuable as it reduces how much I need to source, build and describe. I'll only need to source ffcall and clisp, then verify and write up how to rebuild them. A Cygwin binary on the other hand also requires me to source, build and document the production of cygwin1.dll (and cyggcc_s-1.dll). I'll do that work if I must, but nice to avoid. So a mingw target is valuable. Note: I don't believe I'm allowed to distribute the official clisp mingw binaries from sourceforge because its *features* have :ffi, so they have ffcall in them. But they don't say which version. Or how to rebuild the binaries (e.g. configure flags that were used). Even without ffcall, I've been unable to produce mingw binaries from that old version of clisp. So it seems against at least the spirit of the GPL for me to distribute such binaries knowing that their instructions may have been OK a decade ago on WinXP but don't work today and so their recipient won't really be able to use them to rebuild the binary. In other words, I shouldn't propagate a binary that I know the recipient can't modify from source and rebuild because their instructions are obsolete. Easily distributable clisps will make distributing GPL'ed clisp applications to non-technical people easy. That's what I'm after. -- Vibhu |
|
From: Bruno H. <br...@cl...> - 2022-09-27 00:05:38
|
Vibhu Mohindra wrote:
> System: Windows 10 64-bit, 6 GB RAM
> Processor: Intel Xeon X5647, x64-based processor
> Cygwin (64-bit) targetting mingw 32-bit
> clisp revision: f1aa42219433f019c05e707220538b3634bc233c
> I've used the instructions in INSTALL.windows.
>
>
> ----
> 1. LN_S
>
> The Makefile has a variable LN_S that is chosen to be some platform
> dependent value.
src/makemake.in says that valid values for this variable include
'ln -s', 'ln', and 'cp -p'.
> The reason is that build-aux is a directory, and hard linking
> directories is not supported.
I don't think it's good for the Makefile to copy an entire build-aux
directory. We should look into how to avoid that. Where is this
happening?
> Does "cp -a" seem a reasonable choice?
Yes, if directories need to be copied as well, then 'ln' and 'cp -p'
won't work and 'cp -a' is better.
> 2. floatparam.h
>
> The generated floatparam.h has an error message at the bottom that looks
> like it's causing make to fail.
Oh, this is something I last saw around 2000, when compilers were still
buggy in some places. Often the error goes away if floatparam.c is compiled
with less optimization options.
> So I re-ran the build afresh, but this
> time immediately after the configure step, I replaced floatparam.h with
> a copy from another build configuration I had lying around (Cygwin
> targetting Cygwin 32-bit). Doing that got make further along.
> Please see attached files: floatparam.h.orig (which is the actual one
> generated for the mingw32 target build) and floatparam.h (the copy that
> got me further, taken without good reason from a Cygwin build that
> targetted Cygwin 32-bit).
Your floatparam.h is what I get as well on Linux/x86_64 with
$ gcc -m32 -O2 floatparam.c && ./a.out && cat conftest.h
So that is definitely expected (including the
#define double_rounds_correctly 0
line).
> Background of what I'm up to:
> (Please feel free to ignore all this)
>
> I'm building the various supported configurations listed in
> INSTALL.windows. Some errors appear in many configurations. So I'll be
> careful to try and list/resolve them in a sensible order and always be
> clear which configuration I'm talking about. I presume nobody's tried
> most of them in a long time and that they don't work for anybody any
> more.
Thank you; yes, I haven't tried it on Cygwin since 2018 or so, and
Cygwin as well as Windows evolves over time.
> Here's why I've embarked on this exercise in the first place. I've
> written a command-line GPL'ed Lisp application for a non-technical
> neighbour who only uses Windows. I don't know Windows well, but have now
> got myself access to a Windows system. Besides pure clisp, the
> application needs :ffi and thus ffcall. The most I can expect of my
> neighbour is to double-click on an executable. So I'd like to be able to
> give him a (GPL'ed) application rather than have him download clisp from
> here, ffcall from there, then merge it all together. That would be
> beyond him. So I plan to produce a single zip file with the application
> binary and also all GPL-mandated sources, licences and build instructions.
Bravo! You have understood what the GPL is about. Even if your neighbour
cannot rebuild things by himself, he could ask a friend or a contractor
to do that for him.
> Note: I don't believe I'm allowed to distribute the official clisp mingw
> binaries from sourceforge because its *features* have :ffi, so they have
> ffcall in them. But they don't say which version. Or how to rebuild the
> binaries (e.g. configure flags that were used). Even without ffcall,
> I've been unable to produce mingw binaries from that old version of
> clisp. So it seems against at least the spirit of the GPL for me to
> distribute such binaries knowing that their instructions may have been
> OK a decade ago on WinXP but don't work today and so their recipient
> won't really be able to use them to rebuild the binary. In other words,
> I shouldn't propagate a binary that I know the recipient can't modify
> from source and rebuild because their instructions are obsolete.
Wow, you are giving more thought to the GPL than many other people!
Regarding the ffcall version: Yes, you are right, when distributing
a binary that includes ffcall, the actual version should be specified.
The excuse that we have for omitting this detail is:
- we have only used released versions, no snapshots, for building
public binaries,
- given that these releases maintained compatibility from 1.x to 1.y,
it does not really matter which release was used. The user will
get a working binary when rebuilding, regardless of which ffcall
version they choose.
Regarding the configure flags: If they matter, they should be specified
in the surrounding texts. If they don't matter, they can be omitted.
The idea of the GPL is not to be able to reproduce exactly byte-for-byte the
same binaries — that is a different goal, pursued by reproducible-builds.org —
but merely to allow a user to apply their own modifications and get working
binaries with these modifications.
Regarding the "instructions may have been OK a decade ago on WinXP but don't
work today" argument: The GPL does not mandate source code that will
compile fine 10 years in the future. Even the GCC 3.1, 3.3.6, 4.0.4 source
does not compile out-of-the-box any more on current glibc systems. Thus,
attempting a rebuild on Windows 10 of something that last worked on Windows XP
is quite an adventure, yes. But the license cannot do anything about it.
Bruno
|
|
From: Vibhu M. <vi...@ho...> - 2022-09-27 04:29:01
|
On 27/09/2022 01:59, Bruno Haible wrote: > Vibhu Mohindra wrote: >> System: Windows 10 64-bit, 6 GB RAM >> Processor: Intel Xeon X5647, x64-based processor >> Cygwin (64-bit) targetting mingw 32-bit >> clisp revision: f1aa42219433f019c05e707220538b3634bc233c >> I've used the instructions in INSTALL.windows. >> >> >> ---- >> 1. LN_S >> >> The Makefile has a variable LN_S that is chosen to be some platform >> dependent value. > > src/makemake.in says that valid values for this variable include > 'ln -s', 'ln', and 'cp -p'. > >> The reason is that build-aux is a directory, and hard linking >> directories is not supported. > > I don't think it's good for the Makefile to copy an entire build-aux > directory. We should look into how to avoid that. Where is this > happening? Oh right. If LN_S is never meant to be applied to directories, then that's OK, and it's simply a matter of identifying where all it's used for directories. The top level Makefile in the build directory (from one of my configurations) has this for the build-aux target. build-aux : ../src/build-aux -$(RM) build-aux -$(LN_S) ../src/build-aux build-aux A quick check with grep doesn't reveal any other places where LN_S is used for directories. Anyway, now that I know the intention, if I come across it being used anywhere else for directories, I'll fix that specific instance and write in, rather than trying to change the definition of LN_S itself. If build-aux gets fixed in GitLab, I'll immediately pull that down. >> Does "cp -a" seem a reasonable choice? > > Yes, if directories need to be copied as well, then 'ln' and 'cp -p' > won't work and 'cp -a' is better. > >> 2. floatparam.h >> >> The generated floatparam.h has an error message at the bottom that looks >> like it's causing make to fail. > > Oh, this is something I last saw around 2000, when compilers were still > buggy in some places. Often the error goes away if floatparam.c is compiled > with less optimization options. > >> So I re-ran the build afresh, but this >> time immediately after the configure step, I replaced floatparam.h with >> a copy from another build configuration I had lying around (Cygwin >> targetting Cygwin 32-bit). Doing that got make further along. >> Please see attached files: floatparam.h.orig (which is the actual one >> generated for the mingw32 target build) and floatparam.h (the copy that >> got me further, taken without good reason from a Cygwin build that >> targetted Cygwin 32-bit). > > Your floatparam.h is what I get as well on Linux/x86_64 with > $ gcc -m32 -O2 floatparam.c && ./a.out && cat conftest.h > So that is definitely expected (including the > #define double_rounds_correctly 0 > line). Super to know, thanks a lot. >> Background of what I'm up to: >> (Please feel free to ignore all this) >> >> I'm building the various supported configurations listed in >> INSTALL.windows. Some errors appear in many configurations. So I'll be >> careful to try and list/resolve them in a sensible order and always be >> clear which configuration I'm talking about. I presume nobody's tried >> most of them in a long time and that they don't work for anybody any >> more. > > Thank you; yes, I haven't tried it on Cygwin since 2018 or so, and > Cygwin as well as Windows evolves over time. Oh, that's useful to know. It tells me my experiments needn't go farther back than 2018 GitLab. (Though it's now looking like going forward may work out, with all these useful notes you've given me.) One thing to check. You've said elsewhere that 32-bit Cygwin binaries on 64-bit Cygwin are problematic. Does that also apply to 32-bit mingw binaries on 64-bit Cygwin? If not, then I'll keep that configuration on my list instead of removing it. (That is, this thread's title stays in progress.) My initial goal is not to get unsupported or known-problematic configurations working. At first it's just to get all the known or thought-to-be-good configurations working for myself, in the spirit of walking before I can run. >> Here's why I've embarked on this exercise in the first place. I've >> written a command-line GPL'ed Lisp application for a non-technical >> neighbour who only uses Windows. I don't know Windows well, but have now >> got myself access to a Windows system. Besides pure clisp, the >> application needs :ffi and thus ffcall. The most I can expect of my >> neighbour is to double-click on an executable. So I'd like to be able to >> give him a (GPL'ed) application rather than have him download clisp from >> here, ffcall from there, then merge it all together. That would be >> beyond him. So I plan to produce a single zip file with the application >> binary and also all GPL-mandated sources, licences and build instructions. > > Bravo! You have understood what the GPL is about. Even if your neighbour > cannot rebuild things by himself, he could ask a friend or a contractor > to do that for him. > >> Note: I don't believe I'm allowed to distribute the official clisp mingw >> binaries from sourceforge because its *features* have :ffi, so they have >> ffcall in them. But they don't say which version. Or how to rebuild the >> binaries (e.g. configure flags that were used). Even without ffcall, >> I've been unable to produce mingw binaries from that old version of >> clisp. So it seems against at least the spirit of the GPL for me to >> distribute such binaries knowing that their instructions may have been >> OK a decade ago on WinXP but don't work today and so their recipient >> won't really be able to use them to rebuild the binary. In other words, >> I shouldn't propagate a binary that I know the recipient can't modify >> from source and rebuild because their instructions are obsolete. > > Wow, you are giving more thought to the GPL than many other people! Ha. The tiny application took 2%; writing a licence compliant build script and studying licences (18 Lisp libs, Quicklisp, clisp, mingw, Cygwin) 40%; building clisp on Windows 58% and counting :-) It'll be fun to get it all perfect eventually. It's going to happen. I'm not in a hurry. > Regarding the ffcall version: Yes, you are right, when distributing > a binary that includes ffcall, the actual version should be specified. > The excuse that we have for omitting this detail is: > - we have only used released versions, no snapshots, for building > public binaries, > - given that these releases maintained compatibility from 1.x to 1.y, > it does not really matter which release was used. The user will > get a working binary when rebuilding, regardless of which ffcall > version they choose. Very helpful information, thanks. I believe therefore that if I bundle everything from sourceforge for clisp 2.49, removing the bz2 file (redundant) and mingw-big.zip file (so I don't need to think about the other libs in it), and then add the info in your note above about versions, that will be a bundling that respects all the various library authors' wishes. Not that that's going to stop me from continuing to try producing my own build from the latest source. That still seems worthwhile. And is fun regardless. > Regarding the configure flags: If they matter, they should be specified > in the surrounding texts. If they don't matter, they can be omitted. > The idea of the GPL is not to be able to reproduce exactly byte-for-byte the > same binaries — that is a different goal, pursued by reproducible-builds.org — > but merely to allow a user to apply their own modifications and get working > binaries with these modifications. Right, I meant configure flags only in the sense that that particular incantation was known to work and is worth getting working before trying others. > Regarding the "instructions may have been OK a decade ago on WinXP but don't > work today" argument: The GPL does not mandate source code that will > compile fine 10 years in the future. Even the GCC 3.1, 3.3.6, 4.0.4 source > does not compile out-of-the-box any more on current glibc systems. Thus, > attempting a rebuild on Windows 10 of something that last worked on Windows XP > is quite an adventure, yes. But the license cannot do anything about it. Right, I understand that perfectly. It also means I don't need to provide instructions that will work perpetually. Even if they work for the moment on some computer, that's good enough. It's just that _I_ shouldn't propagate something that I can't build today (and therefore most hired programmers won't be able to build today either). Thanks a lot for all your insight. I'm thrilled to hear from you and get this view into clisp. Vibhu |
|
From: Vibhu M. <vi...@ho...> - 2024-04-05 20:49:25
|
Below, I'm going to round out an email exchange from a year ago based on something I've just found. On 27/09/2022 06:28, Vibhu Mohindra wrote: > On 27/09/2022 01:59, Bruno Haible wrote: >> Vibhu Mohindra wrote: >>> System: Windows 10 64-bit, 6 GB RAM >>> Processor: Intel Xeon X5647, x64-based processor >>> Cygwin (64-bit) targetting mingw 32-bit >>> clisp revision: f1aa42219433f019c05e707220538b3634bc233c >>> I've used the instructions in INSTALL.windows. >>> >>> ---- >>> 1. LN_S >>> >>> The Makefile has a variable LN_S that is chosen to be some platform >>> dependent value. >> >> src/makemake.in says that valid values for this variable include >> 'ln -s', 'ln', and 'cp -p'. >> >>> The reason is that build-aux is a directory, and hard linking >>> directories is not supported. >> >> I don't think it's good for the Makefile to copy an entire build-aux >> directory. We should look into how to avoid that. Where is this >> happening? > > Oh right. If LN_S is never meant to be applied to directories, then that's > OK, and it's simply a matter of identifying where all it's used for > directories. > > The top level Makefile in the build directory (from one of my > configurations) has this for the build-aux target. > > build-aux : ../src/build-aux > -$(RM) build-aux > -$(LN_S) ../src/build-aux build-aux > > A quick check with grep doesn't reveal any other places where LN_S is used > for directories. Anyway, now that I know the intention, if I come across it > being used anywhere else for directories, I'll fix that specific instance > and write in, rather than trying to change the definition of LN_S itself. > > If build-aux gets fixed in GitLab, I'll immediately pull that down. > >>> Does "cp -a" seem a reasonable choice? >> >> Yes, if directories need to be copied as well, then 'ln' and 'cp -p' >> won't work and 'cp -a' is better. I'm sorry, my ln -s woes seem to have been because I had the clisp tree on a network drive mapped to Z:, which doesn't support hard links and whose soft links are impenetrable to ld. With the tree on a local drive (C:), I don't seem to need to change anything related to LN_S from its defaults in Git. Terribly sorry about the LN_S report. (Other notes I've written are all still valid.) Vibhu |
|
From: Vibhu M. <vi...@ho...> - 2022-10-01 07:41:01
Attachments:
config.log
i18n_configure.diff
|
This is a fix to some configure files to deal with Windows line endings. Processor: Intel Xeon X5647, x64-based processor System: Windows 10 64-bit, 6 GB RAM (I haven't yet gotten access to Windows 32-bit, but plan to) Cygwin (both 64-bit and 32-bit) targetting mingw 32-bit I've got lisp.exe and lispinit.mem and am seeing what it'll take to get to having a base/ directory. I'll discuss the failing make targets i18n, syscalls. Notice the extraneous carriage returns in lines 9, 11 of the attached extract of build/syscalls/config.log . They come from modules/syscalls/configure near "cl_cv_clisp_version=...". Sed's second expression does nothing because sed's stdin has a carriage return between the double quote and line feed. Changing the expression to allow an optional carriage return like this: 's/"\r\?$//' solves the problem. There are some other similar places in that same configure script, which I also changed in exactly the same way. See attached diff. Moreover, I believe all the scripts named modules/*/configure will need the same lines fixed. If these scripts are generated, then perhaps the generator can change instead. Note: This problem doesn't occur when building a Cygwin binary, only a mingw binary. That makes sense. The Cygwin binary presumably prints Unix line-endings, for which the original sed expression works just fine. |
|
From: Vibhu M. <vi...@ho...> - 2022-10-02 02:42:36
|
To link the object files into an executable, -lbcrypt is needed but missing. Processor: Intel Xeon X5647, x64-based processor System: Windows 10 64-bit, 6 GB RAM Cygwin (32-bit (and also likely 64-bit)) targetting mingw 32-bit "make base" complains with: i686-w64-mingw32-gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -Wno-shift-negative-value -O2 -fexpensive-optimizations -fwrapv -D_WIN32 -fno-strict-aliasing -DNO_ASM -DNO_ARI_ASM -DNO_SP_ASM -DNO_FAST_DISPATCH -DNO_FAST_FLOAT -DNO_FAST_DOUBLE -DNO_ALLOCA -DNO_ADDRESS_SPACE_ASSUMPTIONS -DNO_GENERATIONAL_GC -DNO_SYMBOLFLAGS -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DNO_GETTEXT -L/usr/local/mingw32/lib modules.o regexi.o calls.o -luser32 -lole32 -loleaut32 -luuid -lversion gettext.o lisp.a libgnu.a -luser32 -lole32 -loleaut32 -luuid -lws2_32 -o lisp.exe /usr/lib/gcc/i686-w64-mingw32/11/../../../../i686-w64-mingw32/bin/ld: libgnu.a(getrandom.o): in function `getrandom': /cygdrive/c/Users/vibhu/clisp_202209b/buildc32m6432a/gllib/../../src/gllib/getrandom.c:129: undefined reference to `BCryptGenRandom@16' collect2: error: ld returned 1 exit status ./clisp-link: failed in /cygdrive/c/Users/vibhu/clisp_202209b/buildc32m6432a/base make: *** [Makefile:2360: base] Error 1 I don't see -lbcrypt in there, which is the problem. The libs listed above with -l are all found as .a archives in mingw's sys-root area. As is libbcrypt.a . So adding -lbcrypt to the gcc command above fixes the problem so that "make base" succeeds. I manually appended -lbcrypt to LIBS in my build directory's Makefile. But the true fix is presumably upstream of that. I see that, src/makemake.in has a line adding -luser32 to LIBS. This should also add -lbcrypt. Maybe it should also go into build/syscalls/link.sh's NEW_LIBS var. -- Vibhu |
|
From: Vibhu M. <vi...@ho...> - 2022-10-02 02:56:51
Attachments:
Makefile.diff
|
The Makefile's check-script target needs the following fix to run to completion. System: Windows 10 64-bit Cygwin (32-bit (and also likely 64-bit)) targetting mingw 32-bit This is the complaint at the end of "make check-script" rm -f script.lisp; echo '(eval-when (:compile-toplevel) (princ *args*))' > script.lisp output=`./lisp.exe -B . -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc -q -q -M lispinit.mem -c script.lisp foo bar`; test "$output" = '(foo bar)' || exit 1 make: *** [Makefile:2172: check-script] Error 1 The problem is that lisp.exe prints a DOS line ending (leaving $output with 11 bytes in total not 9). The attached diff shows how to trim the carriage return when present. It does exactly what the Makefile already does over the next few lines for similar cases. -- Vibhu |
|
From: Vibhu M. <vi...@ho...> - 2022-10-02 03:03:42
|
On 02/10/2022 04:42, Vibhu Mohindra wrote: > To link the object files into an executable, -lbcrypt is needed but > missing. To put that better, the string "-lbcrypt" is needed in the gcc command invocation but is missing from the invocation. The actual library libbcrypt.a is _not_ missing. It's present in mingw's sys-root area, just as it should be, and is found automatically when the argument "-lbcrypt" is added to the gcc call. |
|
From: Vibhu M. <vi...@ho...> - 2022-10-02 03:59:40
|
On 27/09/2022 00:18, Vibhu Mohindra wrote:
> 1. LN_S
I've got past all "ln -s" related problems locally and will describe my
understanding of things.
System: Windows 10 64-bit
Cygwin (32-bit) targetting mingw 32-bit
----
I changed my toplevel Makefile's build-aux target to use "cp -a" instead
of $(LN_S), because LN_S is automatically set to "ln" in this Makefile
and "ln" doesn't work for directories.
----
There are two more kinds of occurrences of ln -s that need fixing.
1) In Makefiles in subdirectories like build/{gllib,i18n,...}/Makefile
2) clisp-link (and perhaps other scripts) which cause full/* to be symlinks
1)
Here's how LN_S gets its value in the Makefiles. The configure script
detects in Cygwin that "ln -s" works and sets LN_S to that. It can't
know that the Windows native clisp that will be produced via mingw won't
actually be able to handle symlinks. (Presumably no native Windows
programs can handle symlinks.) However src/makemake.in (near line 1052)
does know that fact so it replaces LN_S to be "ln". In short, configure
thinks "ln -s" but makemake.in knows to override that to "ln".
But the subsidiary Makefiles take their LN_S values directly from
configure not from makemake.in. Thus they get the configure-detected bad
value "ln -s". I manually changed the LN_S values in these subsidiary
Makefiles to be "ln". I don't know how the build architecture should
change so that they don't require manual editing but are instead born
with the correct value just as the toplevel Makefile is. (Maybe passing
LN_S=ln as a command-line argument to configure will do the trick. If
so, then the solution requiring the least work will be to update
INSTALL.windows to state that. But this hack will still leave the
build's design flawed -- where there's the appearance that makemake gets
to have a say when in reality it doesn't consistently.)
2)
I've got "make full" to complete but I couldn't immediately run the
result. Again, that's because full/* were mostly symlinks. Changing
lisp.exe and lispinit.mem to instead be hard links of the underlying
files made "clisp -K full" start up successfully. I think the symlinks
were created due to clisp-link having "ln -s" in two places. These two
places (or whichever other scripts caused full/* to be symlinks) should
be changed.
--
Vibhu
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X