I've pushed a change that may solve this problem. The change was to the way that `--runtime` determines a shared path prefix among runtime files, so that it can copy them to a new place but keep relative paths intact. On Windows, the paths being compared were sometimes normalized with `normal-case-path` and sometimes not, so the shared prefix could end up being empty (which means that the files put in deeply nested directories).
There's still a long-standing problem that computing a shared prefix doesn't make sense when files are drawn from different effective roots (e.g., a package in installation scope versus a package in user scope, or a package versus the current directory). Fortunately, the package system now gives me to tools that I need to solve this problem; I plan to try further refinements in the next few days. So, if the immediate repair doesn't solve the problem for you, a follow-up change might. At Thu, 05 Nov 2015 12:39:24 +0300, Dmitry Pavlov wrote: > Matthew, > > I am reviving this 6-week-old discussion about > raco and runtime paths. > > That time, I did not go through with it on Windows. > In my Windows build, I used raco ctool without the --runtime > option, leaving the library tied to absolute paths in the system. > > Now I am willing to accomplish the self-contained build. > > Here is what stops me: > > raco ctool --c-mods src/base.c ++lib racket/base ++lib mylib/my-lib > --runtime ./runtime > > copy-and-patch-binaries: not enough room in executable for revised > #rx#"rUnTiMe-paths[)]" table > context...: > C:\Program Files\Racket\collects\compiler\distribute.rkt:383:4: loop > C:\Program Files\Racket\collects\compiler\distribute.rkt:18:2: > assemble-distribution11 > C:\Program > Files\Racket\share\pkgs\cext-lib\compiler\commands\ctool.rkt: [running body] > C:\Program Files\Racket\collects\raco\raco.rkt: [running body] > C:\Program Files\Racket\collects\raco\main.rkt: [running body] > > I use the latest nightly build from Utah. > Without the --runtime option, it works. > On Linux, it works with --runtime or without. > All the other issues raised in this old thread (linking etc.) were > resolved by you 6 weeks ago. > > > I recall that I had that "not enough room in executable" problem > more than a year ago with raco distribute, and you advised to put > some extra dots to the #"................." string in > "collects/compiler/embed.rkt" to remedy it. > However, later you reworked that module so that there > is no such string there anymore, so I do not know what to do. > > Regards, > > Dmitry > > > > On 09/21/2015 08:13 AM, Dmitry Pavlov wrote: > > > > > >>>> I just tried the 32-bit Utah snapshot and 32-bit C app -- build OK, > >>>> but the app crashed right on scheme_main_setup with zero pointer > >>>> access. It did not even enter my "run" function. > >>> > >>> My initial guess is that it's related to thread-local storage and > >>> missing instructions in "Inside". I'll look into it. > >> > >> I see that the instructions to use scheme_register_tls_space() for > >> 32-bit Windows are there after all (but easy to overlook). Are you > >> doing that already? > > > > Oh, I overlooked that setting indeed! Now it works at least > > with the Utah 32-bit build, thanks Matthew. > > > > > > > > Regards, > > > > Dmitry > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
