Re: [racket-dev] Places -- on by default in v5.1.1.2. (git master)
Two days ago, Kevin Tew wrote: This means that parallel zo and doc builds will use places instead of processes. Report bugs as usual :) Here's a major bug: the memory consumption is *horrible*. Winooski, the main build machine, has 4 cores and 4gb ram. Things used to be pretty bad with 4 build processes, each taking around 500mb or a little more -- but this change turned it from bad to nightmarish. (The machine gets overwhelmed by the load while memory consumption goes up mercilessly, gets to the point of thrashing badly and leading the kernell to go off on a random killing spree.) Please disable it. The first build died in a way that was probably similar to that. The second one happened while I was working, so I got to see the horror from a closer range, and killed it myself. (A project that took about 10 minutes to accomplish.) Before it died, the rough numbers were: about 3.8gb of virtual memory, and a resident size of around 2.1gb. My guess is that, like you said, the memory footprint is essentially the same, but with 4 processes the kernel can sort things out and starve one process while the others make progress, and with one there's not much that it can do. (But that's just a guess.) As for the reason I ask to disable it: IMO, a 4gb memory is not something that should be considered common, and = 4 cores too. So this makes a good recipe for a bad first-experience with the langauge. (If I see some random language that kills my machine when I try to compile it, I'd probably not only dump it, but complain loudly whenever I see it mentioned.) Alternatively, if there's a way to check the machine's physical memory, then make it use something like 1 core per 2gb ram. This applies for the multiple-processes variant too, though the number might be a little lower. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Places -- on by default in v5.1.1.2. (git master)
At Thu, 21 Apr 2011 05:33:47 -0400, Eli Barzilay wrote: Two days ago, Kevin Tew wrote: This means that parallel zo and doc builds will use places instead of processes. Report bugs as usual :) Here's a major bug: the memory consumption is *horrible*. Ok, we'll disable for now and check on the change in memory use. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #22500: master branch updated
An hour and a half ago, Kevin Tew wrote: An alternative patch that keeps places enabled but uses processes for build. Yes -- this is what I meant by disabling it. (Assuming that this disables the parallel build with either places or processes.) diff --git a/collects/setup/parallel-do.rkt b/collects/setup/parallel-do.rkt index 00823fe..2716c2a 100644 --- a/collects/setup/parallel-do.rkt +++ b/collects/setup/parallel-do.rkt @@ -168,7 +168,8 @@ (find-system-path 'orig-dir)) (define (parallel-do-event-loop module-path funcname initialmsg jobqueue nprocs [stopat #f]) - (define use-places (place-enabled?)) +; (define use-places (place-enabled?)) + (define use-places #f) (define (spawn id) (define wrkr (if use-places (new PlaceWorker%) (new Worker%))) (wrkr/spawn wrkr id module-path funcname initialmsg) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] my '312' this semester, how we compare to others
[ In case you don't know: since the late 90s, I have been teaching a course dubbed software dev every so often. Students choose their favorite language, I choose the project, they program, I program in Racket and in DrRacket (and strictly). Over the semester the students code-walk their projects in class and the 'finals' are two-hour code walks with 'stress tests' of their servers working with my clients and vice versa. This gives me some idea of what languages contribute to the standard of programming and what's out there. ] * OBSERVATIONS from this year's '312', starting with some background: (1) this is the first year the course was open to MS students and limited enrollment only. So I ended up with 10 MS students and 6 undergraduates. (2) I saw much less variety than usual. (3) two undergraduates started with Racket but due to team rotations they ended up with Java partners. (4) all MS students fell back into their Java/Eclipse monoculture after having seen Racket/DrRacket in the Bootcamp course for MS students. (5) one pair chose Python (6) one pair chose C++, and lo and behold, this is the first time in 14 years that the C++ pair survived the course. On local basis (ten lines here, ten lines there), the C++ and Python code looks as good as Racket code. Java looks worst. Period. I stuck to Racket's OO world, and I will say that I mostly enjoyed this. Racket didn't provide me with much of an advantage anymore. I did benefit from mixins (twice), custodians (once), proper contracts (huge win) and my first large-scale use of rackunit (another large win). If I had remembered logging in Racket, I would have saved myself 40 lines of code and 2 hours of debugging. Higher-order functions and macros played very minor roles. This is possibly due to my choice of project. (Look for Ingenious board game; distributed; variations on the rules) Bottom line here: My code implements more features, is easier to read, has many fewer bugs, I am more productive than anybody in there. But it's my personal skill set (with Racket) not the language features that give me most of the advantage. ;; --- Let's get to what I learned about how others live and where we fail: * PROBLEMS WITH DRRACKET: compared to the Eclipse-Java monoculture, DrRacket suffers from three major problems as far as I am concerned as a program designer: -1- Eclipse performs 'check syntax' in an on-line fashion. If you are reading a piece of code, and you wish to jump to the definition of some method you're calling, click and you jump. -2- Eclipse autocompletes all the time and in a highly convenient manner. -3- Eclipse displays tooltips on ids with relevant docs. It makes it trivial to learn the APIs and to recall what your own methods do (assuming your types and your purpose statements contain the proper information). DrRacket/Racket is superior to Eclipse in two regards: +1+ Contracts are properly integrated into our tool chain. They are comments and or strings in the rest of the world. +2+ My discipline of using define/provide-test-suite enabled me to keep interfaces narrow and tests accurate and called properly. * PROBLEMS WITH RACKET: our performance suffers from two problems. -A- I demanded that students deliver their functionality via Unix shell scripts, and so I did so too. My tcsh scripts check the argument number and pass the arguments on to Racket. Firing up one of my clients or servers takes several seconds. All other language implementations appear to bring up their servers or clients instantaneously. -B- When it comes to raw computational performance (ignore loading Racket, start from REPL and run a single game -- 10 seconds), my implementation is faster than Python (but barely) and one of the Java implementations. But one Java implementation is 10x faster. My hunch is that our OO system is significantly slower than Java's because we lack types to reduce dispatch overhead. Then again I might be wrong. -- Another possibility is that my extremely heavy use of our wonderful (!) contracts may impose a large overhead. I use mostly -i and -m. ;; --- So this is the view from the frontline. I am equally delighted and frustrated this year -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1
* Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine - Test that the binary installers for both work, try each one in both normal and unix-style installation modes. (just ubuntu) [Note: get the release candidates from the URL in this email. Use the 'static table' link to see a list of all tar files available] The binary installers had problems with libffi.so.5. Source distributions are still compiling. I used plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh My notes: textual - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/textual-unix/racket-textual-tmp-install... done. racket-textual-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory racket - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/racket-unix/racket-tmp-install... done. racket-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory Error: installation failed (Removing installation files in /tmp/work/x/binary/racket-unix/racket-tmp-install) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] my '312' this semester, how we compare to others
Matthias Felleisen wrote at 04/21/2011 01:07 PM: -A- I demanded that students deliver their functionality via Unix shell scripts, and so I did so too. My tcsh scripts check the argument number and pass the arguments on to Racket. Firing up one of my clients or servers takes several seconds. All other language implementations appear to bring up their servers or clients instantaneously. I only see slow performance like that from non-GUI Racket when the Racket code is not yet compiled, and perhaps when the files that need to be read (or ELF loaded) by the OS are not in OS caches. The racket REPL executable startup *did* seem to get a lot slower a while ago -- a few seconds -- compared to the old mzscheme REPL. But 5.1 was less than 1 second to REPL prompt when I tried it just now. Three shell script tips that shouldn't matter much, but might speed you up a little: (1) Consider using /bin/sh or /bin/bash instead of tcsh, since the old rule is Bourne for scripting, C-shell for interactive; (2) In the #! line, use command line options to disable shell features that load various system and user rc files, since these are slow to read and interpret, and can be huge like completion tables, plus in a production app other people's shell rc files can introduce instability; (3) After your script does the minimal stuff it has to do in shell rather than Racket, use an exec to fire off racket, so that everyone can forget sooner that shell ever happened. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1
Source distributions compiled ok. The racket distribution no longer produces a 'drscheme' executable even though it does produce 'mzscheme'. Is that a mistake? On 04/21/2011 11:50 AM, Jon Rafkind wrote: * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine - Test that the binary installers for both work, try each one in both normal and unix-style installation modes. (just ubuntu) [Note: get the release candidates from the URL in this email. Use the 'static table' link to see a list of all tar files available] The binary installers had problems with libffi.so.5. Source distributions are still compiling. I used plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh My notes: textual - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/textual-unix/racket-textual-tmp-install... done. racket-textual-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory racket - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/racket-unix/racket-tmp-install... done. racket-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory Error: installation failed (Removing installation files in /tmp/work/x/binary/racket-unix/racket-tmp-install) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1
Not a mistake. 'mzscheme' is kept for script-compatibility but 'drscheme' is dropped as part of the name change transition. Jay 2011/4/21 Jon Rafkind rafk...@cs.utah.edu: Source distributions compiled ok. The racket distribution no longer produces a 'drscheme' executable even though it does produce 'mzscheme'. Is that a mistake? On 04/21/2011 11:50 AM, Jon Rafkind wrote: * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine - Test that the binary installers for both work, try each one in both normal and unix-style installation modes. (just ubuntu) [Note: get the release candidates from the URL in this email. Use the 'static table' link to see a list of all tar files available] The binary installers had problems with libffi.so.5. Source distributions are still compiling. I used plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh My notes: textual - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/textual-unix/racket-textual-tmp-install... done. racket-textual-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory racket - failed in normal mode after install $ ./racket ./racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory failed in unix mode during install Unpacking into /tmp/work/x/binary/racket-unix/racket-tmp-install... done. racket-tmp-install/bin/racket: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory Error: installation failed (Removing installation files in /tmp/work/x/binary/racket-unix/racket-tmp-install) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] my '312' this semester, how we compare to others
I had a request for line counts: -- my own project used ~5,000loc, which includes comments and blank lines -- of these, ~3,200 lines are 'real' code and some ~1,800 lines of rackunit code -- the Java projects run at about 2x to 3x the line count (the best project comes in at close to 12Kloc) -- the C++ project is close to 4Kloc, w/o any tests -- the Python project came out to 2,8000 lines, including tests Some caveats apply of course: ++ Java is extremely verbose and cumbersome, even with parametric polymorphism. ++ Only one project had a larger test ratio than my own. But the project was in Java and see preceding bullet. ++ Only the C++ project has a GUI that is comparable to my own. ++ Not one server lived up to the same quality level as mine. (I sent them a free-formatted string of 1,000,000 lines and that broke everyone's code). ++ Two of seven clients faulted all the time. One faulted on an intermittent basis. And there are other caveats. I am sure I could write more compact Java code than any of the students, though I doubt I'd get close to what I have. I will reflect some more and report on the language comparison a bit more. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] my '312' this semester, how we compare to others
Two points worth noting: 1. Robby pointed out that I forgot to compile my code when I ran the script. That was a critical omission on my side and it eliminates point -A- from my list of negative observations. 2. I forgot to mention the most amazing aspect of my final test run with the students. For their final, we ran their server and my clients. In addition to regular clients, I had nasty ones and bad ones. I wrote one nasty one especially for the C++ project. This client would send the following kind of XML to the server to initiate the dialog: register name= ... 1,000,000 newlines ... some regular chars ... 1,000,000 more newlines ... / As you can see, it's regular XML but a lot of work. The amazing point: -- the C++ project is the ONLY one (other than my own server) that 'survives' this message. (It fails to truncate the name and thus generates too much network traffic in the end. On occasion it may fail for this reason. To be precise, it times out.) -- ALL other projects (Java, Python) failed on this one. The Java and Python libraries are so clumsy that the programmers naturally make mistakes (five different mistakes in six temas). For full disclosure, the C++ hacker is a systems PhD student (uncommon for this course) and is a Google Chrome part-time developer. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1
All of the plot tests and plot extensions in the science collection work as expected. On Wed, Apr 20, 2011 at 9:41 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: Checklist items for the v5.1.1 release (using the v5.1.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test v5.1.1.1 by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc Tests - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite. - Create an executable from a BSL program. Updates: - Racket Updates: update HISTORY - GRacket Updates: update README, HISTORY (updates should show v5.1.1 as the most current version) - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1 Email me to pick the changes when they're done, or tell me if there are no such changes. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests Updates: - DrRacket Updates: update HISTORY (updates should show v5.1.1 as the most current version) - Ensure that previous version of DrRacket's preference files still starts up with new DrRacket - Update man pages in racket/man/man1: drracket.1 Email me to pick the changes when they're done, or tell me if there are no such changes. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.1.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.1.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Casey Klein clkl...@eecs.northwestern.edu - Redex Tests Updates: - Redex Updates: update HISTORY (updates should show v5.1.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper ry...@ccs.neu.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Paul Steckler st...@stecksoft.com - MysterX Tests - MzCOM Tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Sam Tobin-Hochstadt sa...@ccs.neu.edu - Match Tests - Typed Racket Tests * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests * Eli Barzilay e...@barzilay.org - Swindle Tests - Plot Tests - Verify that the unix installer works in both modes - Racket Tree: compare new distribution tree to previous one Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Doug Williams m.douglas.willi...@gmail.com - Plot Tests * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine - Test that the binary installers for both work, try each one in both normal and unix-style installation modes. (just ubuntu) [Note: get the release candidates from the URL in this email. Use the 'static table'
Re: [racket-dev] Pre-Release Checklist for v5.1.1
On Wed, Apr 20, 2011 at 10:41 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests all passed except tests/drracket/test-engine-test.rkt and I'll be looking into that one. - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests done Updates: - DrRacket Updates: update HISTORY (updates should show v5.1.1 as the most current version) done, commit: 8655c4a - Ensure that previous version of DrRacket's preference files still starts up with new DrRacket done - Update man pages in racket/man/man1: drracket.1 no changes to drracket, but I removed the drscheme.1 man page. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] racket 5.1 build failure on debian/kfreebsd
Hi All; I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with src/racket/src/port.c The main problems stem from MZ_FLUSH_* not being defined. This in turn seems to be because MZ_FDS is not defined at line 259. At that point I got stuck, I couldn't see what controlled this definition. The full build log is https://buildd.debian.org/status/fetch.php?pkg=racketarch=kfreebsd-amd64ver=5.1%2Bdfsg1-1stamp=1303128559 The relevant seeming part is as follows: gcc -I./.. -I/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/../include -g -Wall -c /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c -o port.o /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c: In function 'scheme_file_buffer': /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12: error: 'MZ_FLUSH_NEVER' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12: note: each undeclared identifier is reported only once for each function it appears in /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4651:12: error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4653:12: error: 'MZ_FLUSH_ALWAYS' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c: In function 'file_buffer_mode': /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4902:15: error: 'MZ_FLUSH_NEVER' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4904:20: error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Build failure on OS X
I tried to build the git HEAD today and ran into problems. During the make process, it fails to create the framework with the following error message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status Does anyone know what might cause this? Thanks, Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Build failure on OS X
It looke like you have `-L/opt/local/lib' in your LDFLAGS configuration. Do you also have `-I/opt/local/include' in CPPFLAGS? You machine is probably like mine, where you have two installations of libiconv, and this error happens when the C headers of one installation get mixed with the lib of the other. At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote: I tried to build the git HEAD today and ran into problems. During the make process, it fails to create the framework with the following error message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status Does anyone know what might cause this? Thanks, Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Build failure on OS X
I don't have any *FLAGS variables set in my environment when I run configure or make. But I do have libiconv installed through macports. It was out of date, and I upgraded it, but now I am getting a different message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status (Note the warning about a different architecture.) I assume that If I tell it to use the system version of iconv, things will work out. But how do I tell it to ignore the bad version? -Eric On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote: It looke like you have `-L/opt/local/lib' in your LDFLAGS configuration. Do you also have `-I/opt/local/include' in CPPFLAGS? You machine is probably like mine, where you have two installations of libiconv, and this error happens when the C headers of one installation get mixed with the lib of the other. At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote: I tried to build the git HEAD today and ran into problems. During the make process, it fails to create the framework with the following error message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status Does anyone know what might cause this? Thanks, Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Build failure on OS X
The recent change to `configure' makes it use `pkg-config' to add -L and -I flags for libffi. But those should flags be added consistently; that is, you should end up with a build that uses `libiconv' from macports. Did you run `configure' in a fresh build directory? If not, maybe you have files leftover from a previous build that had different flags from `configure'? If not, can you show the compile line for string.c? At Thu, 21 Apr 2011 22:01:31 -0400, Eric Dobson wrote: I don't have any *FLAGS variables set in my environment when I run configure or make. But I do have libiconv installed through macports. It was out of date, and I upgraded it, but now I am getting a different message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status (Note the warning about a different architecture.) I assume that If I tell it to use the system version of iconv, things will work out. But how do I tell it to ignore the bad version? -Eric On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote: It looke like you have `-L/opt/local/lib' in your LDFLAGS configuration. Do you also have `-I/opt/local/include' in CPPFLAGS? You machine is probably like mine, where you have two installations of libiconv, and this error happens when the C headers of one installation get mixed with the lib of the other. At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote: I tried to build the git HEAD today and ran into problems. During the make process, it fails to create the framework with the following error message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status Does anyone know what might cause this? Thanks, Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Build failure on OS X
It looks like it was a problem with libffi, which was also out of date in my macports. I upgraded it before your email, and the build got past that point where it was failing. Hopefully it won't have any more problems. Thanks for the help. -Eric On Apr 21, 2011, at 10:17 PM, Matthew Flatt wrote: The recent change to `configure' makes it use `pkg-config' to add -L and -I flags for libffi. But those should flags be added consistently; that is, you should end up with a build that uses `libiconv' from macports. Did you run `configure' in a fresh build directory? If not, maybe you have files leftover from a previous build that had different flags from `configure'? If not, can you show the compile line for string.c? At Thu, 21 Apr 2011 22:01:31 -0400, Eric Dobson wrote: I don't have any *FLAGS variables set in my environment when I run configure or make. But I do have libiconv installed through macports. It was out of date, and I upgraded it, but now I am getting a different message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status (Note the warning about a different architecture.) I assume that If I tell it to use the system version of iconv, things will work out. But how do I tell it to ignore the bad version? -Eric On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote: It looke like you have `-L/opt/local/lib' in your LDFLAGS configuration. Do you also have `-I/opt/local/include' in CPPFLAGS? You machine is probably like mine, where you have two installations of libiconv, and this error happens when the C headers of one installation get mixed with the lib of the other. At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote: I tried to build the git HEAD today and ran into problems. During the make process, it fails to create the framework with the following error message: gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm -liconv -L/opt/local/lib -lffi Undefined symbols: _iconv_close, referenced from: _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _close_converter in libracket.a(string.o) _iconv_open, referenced from: _do_convert in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _string_to_from_locale in libracket.a(string.o) _scheme_open_converter in libracket.a(string.o) _iconv, referenced from: _do_convert in libracket.a(string.o) ld: symbol(s) not found collect2: ld returned 1 exit status Does anyone know what might cause this? Thanks, Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
