Re: [racket-users] embedded Racket + runtime paths = ?
I found another place where case-normalization of paths was not handled correctly. Your example now works for me with a snapshot build. Can you try the latest? At Sun, 15 Nov 2015 17:57:43 +0300, Dmitry Pavlov wrote: > Matthew, > > >>> [...] So, if the immediate > >>> repair doesn't solve the problem for you, a follow-up change might. > >> > >> [...] > >> Is it e3d78e4, or it is to be done yet? > > > > Yes, it's e3d78e4. > > > I hate to tell you this, but the error still remains in the > latest nightly build, Windows i386: > > > >racket > Welcome to Racket v6.3.0.3. > > (require setup/dirs) > > (get-build-stamp) > "20151115-e3d78e4" > > (exit) > > >raco ctool --c-mods src/base.c ++lib my-lib/my-lib-module --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:385: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] > > > Please let me know if I can help by sending more information. > > > 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew On 11/17/2015 03:50 PM, Matthew Flatt wrote: I found another place where case-normalization of paths was not handled correctly. Your example now works for me with a snapshot build. Can you try the latest? Yes the latest build works! Thank you very much. The case can be finally closed, I think. Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew, [...] So, if the immediate repair doesn't solve the problem for you, a follow-up change might. [...] Is it e3d78e4, or it is to be done yet? Yes, it's e3d78e4. I hate to tell you this, but the error still remains in the latest nightly build, Windows i386: >racket Welcome to Racket v6.3.0.3. > (require setup/dirs) > (get-build-stamp) "20151115-e3d78e4" > (exit) >raco ctool --c-mods src/base.c ++lib my-lib/my-lib-module --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:385: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] Please let me know if I can help by sending more information. 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.
Re: [racket-users] embedded Racket + runtime paths = ?
At Sun, 15 Nov 2015 13:24:07 +0300, Dmitry Pavlov wrote: > On 11/13/2015 06:33 PM, Matthew Flatt wrote: > > [...] So, if the immediate > > repair doesn't solve the problem for you, a follow-up change might. > > [...] > Is it e3d78e4, or it is to be done yet? Yes, it's e3d78e4. -- 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew, On 11/13/2015 06:33 PM, Matthew Flatt wrote: 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. I just tried the nightly build 20151113-6343ca0, Win32. Unfortunately, the error remains. copy-and-patch-binaries: not enough room in executable for revised #rx#"rUnTiMe-paths[)]" table context...: C:\Program Files\Racket\collects\compiler\distribute.rkt:385: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 will check again after the follow-up change that you tell about. Is it e3d78e4, or it is to be done yet? Just so you know: it is not urgent for me right now, I actually have a work-around that just uses less number of runtime paths, which ctool handles OK. But I may have more runtime paths in the future. Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
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.
Re: [racket-users] embedded Racket + runtime paths = ?
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.
Re: [racket-users] embedded Racket + runtime paths = ?
At Sun, 20 Sep 2015 16:08:48 -0600, Matthew Flatt 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? -- 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.
Re: [racket-users] embedded Racket + runtime paths = ?
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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew, I've added a `--runtime ` argument to `raco ctool --cmods`, which gathers runtime files into and makes the embedded modules refer to them in (which is expected to be relative to the executable, but see also the `--runtime-access` option). The embedding executable must call scheme_set_exec_cmd() to set the result of `(find-system-path 'exec-file)` so that runtime files can be found in relative to the executable. Great! I just tested it on Linux with nightly build 6dfc20d. On Windows, though, I ran into a problem when linking my app with pre-built libracket3m_9yy8mp.lib : error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp That is the only unresolved symbol. All the others were gone after I added libracket3m_9yy8mp.lib to the project. Do you have an idea how I can fix that one? Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
At Mon, 21 Sep 2015 01:04:15 +0300, Dmitry Pavlov wrote: > Matthew, > > On 09/21/2015 12:38 AM, Matthew Flatt wrote: > > At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote: > >> On Windows, though, I ran into a problem when linking my app > >> with pre-built libracket3m_9yy8mp.lib : > >> > >> error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp > >> > >> That is the only unresolved symbol. All the others were gone after > >> I added libracket3m_9yy8mp.lib to the project. > >> Do you have an idea how I can fix that one? > > > > I think this is a VC vs. MinGW problem. I'll have to think about this > > problem more, because we want those builds to be the same. > > You probably figured that out, but to be sure: I got the error on > the Utah snapshot, and I am building the app with Visual Studio. > The version of VS is 2013. That makes sense. I noticed that it was actually a VS 2008/2010 vs. everything else issue. It should be easy to fix. > Also, I want to add that it was a 64-bit Racket and 64-bit C app. > 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. > > Meanwhile, if you use a Windows snapshot from Northwestern, does it > > solve the problem? > > > >http://plt.eecs.northwestern.edu/snapshots/ > > Err, just installed 32-bit Northwestern snapshot and I see no > libracket3m*.lib, only .dll without .exp, so not sure how to link that. Ok, another issue to resolve. -- 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.
Re: [racket-users] embedded Racket + runtime paths = ?
At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote: > On Windows, though, I ran into a problem when linking my app > with pre-built libracket3m_9yy8mp.lib : > > error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp > > That is the only unresolved symbol. All the others were gone after > I added libracket3m_9yy8mp.lib to the project. > Do you have an idea how I can fix that one? I think this is a VC vs. MinGW problem. I'll have to think about this problem more, because we want those builds to be the same. Meanwhile, if you use a Windows snapshot from Northwestern, does it solve the problem? http://plt.eecs.northwestern.edu/snapshots/ The snapshots from Northwestern are built with MinGW. -- 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew, On 09/21/2015 12:38 AM, Matthew Flatt wrote: At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote: On Windows, though, I ran into a problem when linking my app with pre-built libracket3m_9yy8mp.lib : error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp That is the only unresolved symbol. All the others were gone after I added libracket3m_9yy8mp.lib to the project. Do you have an idea how I can fix that one? I think this is a VC vs. MinGW problem. I'll have to think about this problem more, because we want those builds to be the same. You probably figured that out, but to be sure: I got the error on the Utah snapshot, and I am building the app with Visual Studio. The version of VS is 2013. Also, I want to add that it was a 64-bit Racket and 64-bit C app. 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. Meanwhile, if you use a Windows snapshot from Northwestern, does it solve the problem? http://plt.eecs.northwestern.edu/snapshots/ Err, just installed 32-bit Northwestern snapshot and I see no libracket3m*.lib, only .dll without .exp, so not sure how to link that. Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
I've added a `--runtime ` argument to `raco ctool --cmods`, which gathers runtime files into and makes the embedded modules refer to them in (which is expected to be relative to the executable, but see also the `--runtime-access` option). The embedding executable must call scheme_set_exec_cmd() to set the result of `(find-system-path 'exec-file)` so that runtime files can be found in relative to the executable. At Wed, 16 Sep 2015 07:52:11 -0600, Matthew Flatt wrote: > After thinking about this more, it looks more promising to extend `raco > ctool --cmods` so that it can do a `raco distribute`-like step in > addition to a `raco exe`-like step. > > In other words, `raco ctool --cmods` with some extra flag could give > you both a file (as currently, to embed in the executable) and a > directory of extra files (that are referenced through relative paths by > the part to embed). > > Still, I'll have to try that out to see if it works. > > At Wed, 16 Sep 2015 16:11:21 +0300, Dmitry Pavlov wrote: > > Also, if it matters, I usually make my Windows builds on Linux > > with MinGW (i686-w64-mingw32-gcc, x86_64-w64-mingw32). But I can > > use Visual Studio too, I guess, if that will make things easier > > for raco distribute or whatever. > > > > Best regards, > > > > Dmitry > > > > > > On 09/16/2015 03:52 PM, Dmitry Pavlov wrote: > > > Matthew, > > > > > >> The most likely solution is to make the executable look enough like a > > >> "PLT executable", but I'll have to try it out to pin down additions > > >> that will work. > > >> > > >> Are you interested in this only for Unix variants or for all platforms? > > >> I think Windows will be more difficult. > > > > > > Thank you for the reply. > > > > > > Not only I need this for both Windows and Linux, but ideally > > > in the future I would like to ship also a dynamic C library that > > > uses a Racket library that has runtime paths. For the start, > > > though, Windows and Linux executables will be enough for my purposes. > > > > > > Also, if it matters, my Racket library uses some low-level C > > > libraries itself. > > > > > > I can not estimate the difficulty of either approach to this problem, > > > but I am entirely open to solutions that require some special > > > handling from the C level --- hijacking runtime paths from C maybe? > > > I do not know. > > > > > > Best regards, > > > > > > Dmitry > > > > > >> > > >> At Wed, 16 Sep 2015 14:26:41 +0300, Dmitry Pavlov wrote: > > >>> Hello, > > >>> > > >>> I just created a C program that uses my Racket library via > > >>> Racket's embedding mechanism, and it works fantastic. > > >>> > > >>> Now I am wondering---how to ship my C program's > > >>> executable if the underlying Racket library has runtime > > >>> paths in it? The executable seems to have been set up for > > >>> absolute paths of the runtime paths that Racket library uses. > > >>> > > >>> I know that for pure Racket programs, raco distribute > > >>> does the job of handling the paths and shipping the program > > >>> with all the needed files. I tried (maybe too naively) > > >>> to apply raco distribute to my executable, and got the following: > > >>> > > >>> assemble-distribution: file is not a PLT executable > > >>> > > >>> OK, maybe it is not. But what other options do I have? > > >>> FWIW, I used the following commands to create the executable: > > >>> > > >>> raco ctool --c-mods base.c ++lib my-library > > >>> > > >>> gcc -c -g -DMZ_PRECISE_GC -I/opt/racket/include -o main.o main.c > > >>> > > >>> gcc -o myprog main.o -lpthread -lm -ldl /opt/racket/lib/libracket3m.a > > >>> -rdynamic > > >>> > > >>> the contents of main.c for the most part copies the example > > >>> at http://docs.racket-lang.org/inside/embedding.html > > >>> > > >>> > > >>> Best 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. > > -- > 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] embedded Racket + runtime paths = ?
Hello, I just created a C program that uses my Racket library via Racket's embedding mechanism, and it works fantastic. Now I am wondering---how to ship my C program's executable if the underlying Racket library has runtime paths in it? The executable seems to have been set up for absolute paths of the runtime paths that Racket library uses. I know that for pure Racket programs, raco distribute does the job of handling the paths and shipping the program with all the needed files. I tried (maybe too naively) to apply raco distribute to my executable, and got the following: assemble-distribution: file is not a PLT executable OK, maybe it is not. But what other options do I have? FWIW, I used the following commands to create the executable: raco ctool --c-mods base.c ++lib my-library gcc -c -g -DMZ_PRECISE_GC -I/opt/racket/include -o main.o main.c gcc -o myprog main.o -lpthread -lm -ldl /opt/racket/lib/libracket3m.a -rdynamic the contents of main.c for the most part copies the example at http://docs.racket-lang.org/inside/embedding.html Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
The most likely solution is to make the executable look enough like a "PLT executable", but I'll have to try it out to pin down additions that will work. Are you interested in this only for Unix variants or for all platforms? I think Windows will be more difficult. At Wed, 16 Sep 2015 14:26:41 +0300, Dmitry Pavlov wrote: > Hello, > > I just created a C program that uses my Racket library via > Racket's embedding mechanism, and it works fantastic. > > Now I am wondering---how to ship my C program's > executable if the underlying Racket library has runtime > paths in it? The executable seems to have been set up for > absolute paths of the runtime paths that Racket library uses. > > I know that for pure Racket programs, raco distribute > does the job of handling the paths and shipping the program > with all the needed files. I tried (maybe too naively) > to apply raco distribute to my executable, and got the following: > > assemble-distribution: file is not a PLT executable > > OK, maybe it is not. But what other options do I have? > FWIW, I used the following commands to create the executable: > > raco ctool --c-mods base.c ++lib my-library > > gcc -c -g -DMZ_PRECISE_GC -I/opt/racket/include -o main.o main.c > > gcc -o myprog main.o -lpthread -lm -ldl /opt/racket/lib/libracket3m.a > -rdynamic > > the contents of main.c for the most part copies the example > at http://docs.racket-lang.org/inside/embedding.html > > > Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Matthew, The most likely solution is to make the executable look enough like a "PLT executable", but I'll have to try it out to pin down additions that will work. Are you interested in this only for Unix variants or for all platforms? I think Windows will be more difficult. Thank you for the reply. Not only I need this for both Windows and Linux, but ideally in the future I would like to ship also a dynamic C library that uses a Racket library that has runtime paths. For the start, though, Windows and Linux executables will be enough for my purposes. Also, if it matters, my Racket library uses some low-level C libraries itself. I can not estimate the difficulty of either approach to this problem, but I am entirely open to solutions that require some special handling from the C level --- hijacking runtime paths from C maybe? I do not know. Best regards, Dmitry At Wed, 16 Sep 2015 14:26:41 +0300, Dmitry Pavlov wrote: Hello, I just created a C program that uses my Racket library via Racket's embedding mechanism, and it works fantastic. Now I am wondering---how to ship my C program's executable if the underlying Racket library has runtime paths in it? The executable seems to have been set up for absolute paths of the runtime paths that Racket library uses. I know that for pure Racket programs, raco distribute does the job of handling the paths and shipping the program with all the needed files. I tried (maybe too naively) to apply raco distribute to my executable, and got the following: assemble-distribution: file is not a PLT executable OK, maybe it is not. But what other options do I have? FWIW, I used the following commands to create the executable: raco ctool --c-mods base.c ++lib my-library gcc -c -g -DMZ_PRECISE_GC -I/opt/racket/include -o main.o main.c gcc -o myprog main.o -lpthread -lm -ldl /opt/racket/lib/libracket3m.a -rdynamic the contents of main.c for the most part copies the example at http://docs.racket-lang.org/inside/embedding.html Best 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.
Re: [racket-users] embedded Racket + runtime paths = ?
Also, if it matters, I usually make my Windows builds on Linux with MinGW (i686-w64-mingw32-gcc, x86_64-w64-mingw32). But I can use Visual Studio too, I guess, if that will make things easier for raco distribute or whatever. Best regards, Dmitry On 09/16/2015 03:52 PM, Dmitry Pavlov wrote: Matthew, The most likely solution is to make the executable look enough like a "PLT executable", but I'll have to try it out to pin down additions that will work. Are you interested in this only for Unix variants or for all platforms? I think Windows will be more difficult. Thank you for the reply. Not only I need this for both Windows and Linux, but ideally in the future I would like to ship also a dynamic C library that uses a Racket library that has runtime paths. For the start, though, Windows and Linux executables will be enough for my purposes. Also, if it matters, my Racket library uses some low-level C libraries itself. I can not estimate the difficulty of either approach to this problem, but I am entirely open to solutions that require some special handling from the C level --- hijacking runtime paths from C maybe? I do not know. Best regards, Dmitry At Wed, 16 Sep 2015 14:26:41 +0300, Dmitry Pavlov wrote: Hello, I just created a C program that uses my Racket library via Racket's embedding mechanism, and it works fantastic. Now I am wondering---how to ship my C program's executable if the underlying Racket library has runtime paths in it? The executable seems to have been set up for absolute paths of the runtime paths that Racket library uses. I know that for pure Racket programs, raco distribute does the job of handling the paths and shipping the program with all the needed files. I tried (maybe too naively) to apply raco distribute to my executable, and got the following: assemble-distribution: file is not a PLT executable OK, maybe it is not. But what other options do I have? FWIW, I used the following commands to create the executable: raco ctool --c-mods base.c ++lib my-library gcc -c -g -DMZ_PRECISE_GC -I/opt/racket/include -o main.o main.c gcc -o myprog main.o -lpthread -lm -ldl /opt/racket/lib/libracket3m.a -rdynamic the contents of main.c for the most part copies the example at http://docs.racket-lang.org/inside/embedding.html Best 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.
