Re: [Chicken-users] CMake problem on Linux should be solved
John Cowan wrote: Brandon J. Van Every scripsit: I await your tests. CMake printed an error and didn't generate anything because line 127 tries to load a file named "buildnumber", but there is no such file in the current Darcs head. A change which apparently Felix committed 20 minutes after my e-mail. Not that I would have noticed even if he had done it in the past 4 days. I generally don't pull in new stuff when trying to solve my own build problems, lest I pull in new problems. It should be trivial to fix. So I built and installed the autotools version, patched around the problem on line 127, and reran cmake, getting this: $ cmake /opt/chicken/darcs -- Check for working C compiler: gcc.exe -- Check for working C compiler: gcc.exe -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: c++.exe -- Check for working CXX compiler: c++.exe -- works -- Found /usr/local/bin/chicken-static.exe CMake Error: Invalid escape sequence \_ Syntax error in cmake code at /opt/chicken/darcs/CMakeLists.txt:253: syntax error, unexpected cal_ERROR, expecting $end (111), when parsing string "___| | Those are weird. But since I've never seen anything like it on Cygwin, and I don't know how you patched, I'll wait and see what happens after I fix the buildnumber thingy. _) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| It looks like CMake suddenly doesn't like the "\_" sequence in in the big-print "Chicken" output by "chicken-static -version", and then gets terminally confused after that. Are you using CMake 2.4.3 or CMake CVS? If 2.4.3 then we're using the same CMake. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
Brandon J. Van Every scripsit: > I await your tests. CMake printed an error and didn't generate anything because line 127 tries to load a file named "buildnumber", but there is no such file in the current Darcs head. So I built and installed the autotools version, patched around the problem on line 127, and reran cmake, getting this: $ cmake /opt/chicken/darcs -- Check for working C compiler: gcc.exe -- Check for working C compiler: gcc.exe -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: c++.exe -- Check for working CXX compiler: c++.exe -- works -- Found /usr/local/bin/chicken-static.exe CMake Error: Invalid escape sequence \_ Syntax error in cmake code at /opt/chicken/darcs/CMakeLists.txt:253: syntax error, unexpected cal_ERROR, expecting $end (111), when parsing string "___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2.430 - windows-cygwin-x86 - [ ptables applyhook ] (c)2000-2006 Felix L. Winkelmann * 100 + ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2.430 - windows-cygwin-x86 - [ ptables applyhook ] (c)2000-2006 Felix L. Winkelmann * 100" CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:141: MATH cannot parse the expression: "___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2.430 - windows-cygwin-x86 - [ ptables applyhook ] (c)2000-2006 Felix L. Winkelmann * 100 + ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2.430 - windows-cygwin-x86 - [ ptables applyhook ] (c)2000-2006 Felix L. Winkelmann * 100": syntax error, unexpected exp_OR, expecting exp_OPENPARENT or exp_NUMBER (4) Current CMake stack: /opt/chicken/darcs/CMakeLists.txt;/usr/share/cmake-2.4.3/Modules/CMakeCInformation.cmake;/usr/share/cmake-2.4.3/Modules/CMakeCXXInformation.cmake CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:253: A command failed during the invocation of macro "CANONIZE_VERSION". CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:165: CANONIZE_VERSION unknown error. Current CMake stack: /opt/chicken/darcs/CMakeLists.txt;/usr/share/cmake-2.4.3/Modules/CMakeCInformation.cmake;/usr/share/cmake-2.4.3/Modules/CMakeCXXInformation.cmake CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:253: A command failed during the invocation of macro "GET_TOOL_VERSION". CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:253: GET_TOOL_VERSION unknown error. Current CMake stack: /opt/chicken/darcs/CMakeLists.txt;/usr/share/cmake-2.4.3/Modules/CMakeCInformation.cmake;/usr/share/cmake-2.4.3/Modules/CMakeCXXInformation.cmake Chicken 2000300 required to generate bootstrap .c files. Available Chicken is only . You have no valid Chicken available. If you have all the boot/cfiles/*.c files that a bootstrap needs, then I can still build Chicken for you. CMake Error: Error in cmake code at /opt/chicken/darcs/CMakeLists.txt:365: MESSAGE /opt/chicken/darcs/boot/cfiles/batch-driver.c is missing. Giving up, terminating build. Current CMake stack: /opt/chicken/darcs/CMakeLists.txt;/usr/share/cmake-2.4.3/Modules/CMakeCInformation.cmake;/usr/share/cmake-2.4.3/Modules/CMakeCXXInformation.cmake -- Configuring done It looks like CMake suddenly doesn't like the "\_" sequence in in the big-print "Chicken" output by "chicken-static -version", and then gets terminally confused after that. -- The Unicode Standard does not encodeJohn Cowan idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan use characters, nor does it encode logos or graphics.[EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [CMake] setting a default build type
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is "Debug" and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Just a side note, in case my misunderstanding of the build-type triggered an unneeded feature request: I'm fine with "Debug" being the default for Project builds (like MSVC/Project). It's in the "would be nice to have" level of importance. I would rather a user do nothing and get the best optimized build. I'm sure that's true for many other projects also. I asked Brandon to make MinSizeRel the default because I didn't get that this is only supported for mentioned builds. That is to say, only MSVC has Debug, Release, MinSizeRel, and RelWithDbgInfo builds at present. I believe there's an extant feature request about making these universal. Just overriding the CFLAGS via ccmake is fine for me. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [CMake] setting a default build type
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is "Debug" and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Just a side note, in case my misunderstanding of the build-type triggered an unneeded feature request: I'm fine with "Debug" being the default for Project builds (like MSVC/Project). I asked Brandon to make MinSizeRel the default because I didn't get that this is only supported for mentioned builds. Just overriding the CFLAGS via ccmake is fine for me. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] FWIW - real numbers for -Os vs. -O3 on a Mac G4
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: They should know what? Your benchmarks indicate that -O3 is a hair faster than -Os. As you said above, the -Os binaries are a hair smaller. What do people value, things being a hair faster or a hair smaller? I do know that 10% size reductions don't sell anything, whereas little improvements in performance can edge out competitors in Shootout benchmarks. The chicken libraries and binaries are a good deal smaller with -Os (the size improvements of micro-benchmarks are not so important here). Anyway, this will my last post about this issue. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] feature freeze on CMake build
I've found that getting the essentials ready for a release, has consumed a lot more time than I wished it would. Therefore, I'm declaring "no new features" in the CMake build before the next release. I want this out the door and for it to start getting tested in the field. I don't want any additional complications as to what is tested, nor to do any more work that I can avoid doing. I'm way behind on jobhunting and again, the threat of losing the roof over my head is real. Got about 4 weeks to solve that puzzle, gotta see some $$$ from somewhere. If you know anyone who needs a good build engineer Anyways, this means: - I will not worry about optimization flags on VS 7.1 for now. The various Debug, Release, MinSizeRel, and RelWithDebInfo targets already have some. It's not important to reach the uber-pinnacle of great flags right now. I notice that makefile.vc doesn't have any special flags in it anyways, so it's not like anything is backsliding. - I won't take any patches for rudimentary cross-compilation support, such as templating a sample Makefile, or building a totally stripped down Chicken (which I think should be canonically called a "chick". :-) I think these are great ideas that I'd like to support in the future. But for now, just use the abundant /boot/cfiles/*.c that are given to you. If you develop proof-of-concept on your own, we can incorporate it later, when I have more time. - I don't want Felix taking these things either. I want a build with fewer variables kicked out the door as a beta release. It's *my* reputation on the line about whether the 1st cut of the public CMake build is as good as I've been telling everybody it is. I don't need the VS 7.1 equivalent of -fomit-frame-pointer crashing someone's chicken-boot, as it did on MinGW. I'm taking a chance that it'll work ok on Cygwin as it is. Sure it has historically worked in the Autoconf build, but Autoconf uses libtool, CMake doesn't, and who knows what difference that makes. I believe I have only 2 CMake-related things left to clean up: - make Darcs and the ChangeLog less of a hassle (minor issue, can blow off) - make sure that Windows eggs work (major issue, must get done) Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] CMake problem on Linux should be solved
CMake 2.4.3 has a bug where static and dynamic libraries clobber each other during the build if they have the same rootname. The bug affects all OSes. Previously I thought it only affected Windows, and I implemented hacks during the INSTALL to get around it. Felix reported a problem on Linux and Bill of Kitware confirmed that it's the same bug. I decided it is too complicated to do more INSTALL hacks, as I don't really know what suffixes are apropos on Linux or arbitrary OSes in general, nor do I have the ability to test them. So, static libraries are now built in a /static subdirectory. This took some refactoring of CMakeLists.txt. It wasn't trivial but it was doable, about a day's work. The results are now in Darcs. I have confirmed that VS 7.1, MinGW, and Cygwin all build and install just fine now. I am projecting that Linux will build and install just fine now as well, since it will go through the same code path as the MinGW build. I await your tests. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] sha1 unusable in Chicken 2.3?
Peter Busser wrote: On Tue, Sep 05, 2006 at 03:41:39PM -0700, Brandon J. Van Every wrote: Maybe people should get serious about nightly build and test suites, instead of expecting this kind of support stuff to magically appear from the few developers working on things. Really, seriously, the answers to greater Chicken robustness lie in the energy of the community, not in Felix. Someone show me that they care enough to implement industrial strength testing. I will certainly facilitate any build requirements, especially Kitware's offers regarding the Dart Dashboard, but I will not take the lead. Also have a look at http://aegis.sourceforge.net/. Indeed, anyone who actually wants to shoulder real work, is freely entitled to support the system that will make their life easiest. Bear in mind, however, that if you don't already have a firm favorite, you have "matching offers" from Kitware and myself to implement a Dart Dashboard. http://public.kitware.com/Dart/HTML/Index.shtml Here for instance is a dashboard for KDE, which moved to a CMake build system this year. http://public.kitware.com/dashboard.php?name=kde Matching contributions, especially Kitware's, need to be considered as part of your evaluation. I will offer build support no matter what anyone does, but I can do a lot more if you pick Dart, because it seamlessly integrates with CMake. I consider it a no-brainer if you don't already have expertise with a test system and your own big ideas about how everything should be done. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] sha1 unusable in Chicken 2.3?
On Tue, Sep 05, 2006 at 03:41:39PM -0700, Brandon J. Van Every wrote: > Maybe people should get serious about nightly build and test suites, > instead of expecting this kind of support stuff to magically appear from > the few developers working on things. Really, seriously, the answers to > greater Chicken robustness lie in the energy of the community, not in > Felix. Someone show me that they care enough to implement industrial > strength testing. I will certainly facilitate any build requirements, > especially Kitware's offers regarding the Dart Dashboard, but I will not > take the lead. Also have a look at http://aegis.sourceforge.net/. Groetjes, Peter. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [CMake] setting a default build type
Brad King wrote: Brandon J. Van Every wrote: Brad King wrote: This would be a nice feature but I don't know how to implement it. Try generating a project and then manually editing the project files in such a way that the IDE selects a different configuration by default. Don't forget to remove the .suo and .ncb files between attempts because they store the user IDE state. That approach is not desired. People typically want CMakeList.txt under source control, not its end products, as the latter differ for every person. We don't ship .sln files to people, we tell them to install CMake. I was not proposing this as a solution, I was asking you to figure out how to implement it. I have no idea how to write a .sln or .vcproj file that will convince the VS IDE to come up with a non-Debug configuration by default. I just tried manually reordering the configurations to put Release first and the IDE still selected Debug at startup. Even changing the Release configuration to have the name ARelease (which comes before Debug lexicographically) didn't fix it. I have no idea either, nor time to investigate it at present. I will note our lack of knowledge in the feature request. Maybe we'll run into someone else who knows better. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] FWIW - real numbers for -Os vs. -O3 on a Mac G4
Kon Lovett wrote: Hi, Attached are Chicken benchmark results for a -Os & a -O3 build of the same Chicken source. Well, YMMV seems to be the overall picture for the benchmarks. The reduction in binary size is ~10%. Apple's XCode, their buildtool, uses -Os as the default release optimization flag, & they should know :-). They should know what? Your benchmarks indicate that -O3 is a hair faster than -Os. As you said above, the -Os binaries are a hair smaller. What do people value, things being a hair faster or a hair smaller? I do know that 10% size reductions don't sell anything, whereas little improvements in performance can edge out competitors in Shootout benchmarks. There is of course the entire matrix of all versions of GCC on all OSes and all CPUs with all the various possible compiler flags. Are there any portions of that search space that show significant differences? I'm not going to get into it, it's a lot of work. I learned back at DEC that you have to spend most of your time coding, not benchmarking. All an optimization jock ever does is develop heuristics about what really improves the speed of code, and then occasionally check that his assumptions are valid. Cheers, Brandon Van Every ./csc benchmarks/cscbench.scm -o benchmarks/cscbench -compiler ./chicken cd benchmarks; ./cscbench ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2, Build 429 - macosx-unix-gnu-ppc - [ libffi dload ptables applyhook ] (c)2000-2006 Felix L. Winkelmann CC: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) CFLAGS: -DHAVE_CHICKEN_CONFIG_H -Os -mcpu=7450 -mtune=G4 -fomit-frame-pointer -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -DHAVE_ALLOCA_H -DC_ENABLE_PTABLES -no-cpp-precomp -DC_NO_PIC_NO_DLL base unsafemax boyer 0.276 0.180 0.189 browse 0.284 0.201 0.194 conform 0.554 0.250 0.239 cpstak 1.494 1.246 0.844 ctak0.932 0.787 0.755 dderiv 0.475 0.372 0.343 deriv 0.373 0.302 0.281 destructive 0.482 0.446 0.235 div-iter0.121 0.083 0.008 div-rec 0.301 0.172 0.175 dynamic 0.343 0.024 0.232 earley 0.068 0.068 0.052 fft 0.120 0.116 fib 0.814 0.065 0.104 fibc 10.052 6.067 4.166 fprint 0.005 0.005 0.005 fread 0.025 0.024 0.023 hanoi 2.148 1.997 0.405 lattice27.379 20.294 20.092 maze0.713 0.416 nqueens 0.011 0.009 0.004 puzzle 0.252 0.199 0.136 scheme 0.081 0.005 0.046 tak 1.504 1.028 0.239 takl0.849 0.181 0.181 takr2.802 1.766 1.389 traverse1.715 0.814 0.843 travinit0.247 0.192 0.067 triangl 3.215 2.258 2.046 -rwxr-xr-x 1 klovett admin 1487092 Sep 7 07:08 /usr/local/bin/chicken* -rwxr-xr-x 1 klovett admin42164 Sep 7 07:08 /usr/local/bin/chicken-profile* -rwxr-xr-x 1 klovett admin 401748 Sep 7 07:08 /usr/local/bin/chicken-setup* -rwxr-xr-x 1 klovett admin 3325776 Sep 7 07:08 /usr/local/bin/chicken-static* -rwxr-xr-x 1 klovett admin 2677716 Sep 7 07:08 /usr/local/lib/libchicken.0.0.0.dylib* lrwxr-xr-x 1 klovett admin 22 Sep 7 07:08 /usr/local/lib/libchicken.0.dylib@ -> libchicken.0.0.0.dylib -rw-r--r-- 1 klovett admin 4225368 Sep 7 07:08 /usr/local/lib/libchicken.a lrwxr-xr-x 1 klovett admin 22 Sep 7 07:08 /usr/local/lib/libchicken.dylib@ -> libchicken.0.0.0.dylib -rwxr-xr-x 1 klovett admin 879 Sep 7 07:08 /usr/local/lib/libchicken.la* -rwxr-xr-x 1 klovett admin 2373856 Sep 7 07:08 /usr/local/lib/libuchicken.0.0.0.dylib* lrwxr-xr-x 1 klovett admin 23 Sep 7 07:08 /usr/local/lib/libuchicken.0.dylib@ -> libuchicken.0.0.0.dylib -rw-r--r-- 1 klovett admin 3699712 Sep 7 07:08 /usr/local/lib/libuchicken.a lrwxr-xr-x 1 klovett admin 23 Sep 7 07:08 /usr/local/lib/libuchicken.dylib@ -> libuchicken.0.0.0.dylib -rwxr-xr-x 1 klovett admin
[Chicken-users] Re: [CMake] setting a default build type
Brad King wrote: Brandon J. Van Every wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is "Debug" and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. This would be a nice feature but I don't know how to implement it. Try generating a project and then manually editing the project files in such a way that the IDE selects a different configuration by default. Don't forget to remove the .suo and .ncb files between attempts because they store the user IDE state. That approach is not desired. People typically want CMakeList.txt under source control, not its end products, as the latter differ for every person. We don't ship .sln files to people, we tell them to install CMake. I'll make a feature request. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimization flags
John Cowan wrote: Brandon J. Van Every scripsit: I'm only providing the flags for GCC builds. I'm not willing to assume that non-GCC compilers take GCC flags. If people have non-GCC, non-MSVC compilers, they can inform us, and we can add more flags. I might also set up an area at the top of CMakeLists.txt that's meant for people to add flags we don't know about. Fair enough. I found that -fomit-frame-pointer causes chicken-boot to crash when compiled with MinGW 3.4.5. So, I've turned it off for all MinGW compilers. No idea if it affects anything other than 3.4.5. You can see that there are testing issues. Cygwin built fine without complaint. Didn't actually test the end product though, as I relish the chance to blow up John Cowan's machine. :-) Ooops! VERY BAD PROBLEM. When built under CMake (but not when built under autotools), the chicken-setup.c file produces compiler errors from gcc. I'm using the autotools build for the present. I take it you mean you're building on Cygwin? I can't duplicate this. Here's my full GCC command: [ 64%] Building C object CMakeFiles/chicken-setup.dir/chicken-setup.o /usr/bin/gcc.exe -I/cygdrive/e/devel/cygwin/chicken -I/cygdrive/e/devel/src/chi cken -DHAVE_CHICKEN_CONFIG_H -Os -fno-strict-aliasing -Wall -Wno-unused -Wno-u ninitialized -fomit-frame-pointer -DC_ENABLE_PTABLES -DPIC -DC_NO_PIC_NO_DLL -o CMakeFiles/chicken-setup.dir/chicken-setup.o -c /cygdrive/e/devel/cygwin/chick en/chicken-setup.c Linking C executable chicken-setup.exe and here's my GCC version banner. What's yours? $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Cheers, Brandon Van Every Diffing the two versions of chicken-setup.c show only two presumably trivial differences: some comments refer to /opt/chicken/darcs/chicken-setup.scm instead of just chicken-setup.scm, and the ptable declaration at line 22369 contains strings of the form "f_/opt/chicken/darcs/chicken-setup.scm" instead of "f_chicken-setup.scm". I've attached the chicken-config.h and chicken-defaults.h files from the CMake build. /* chicken-config.h Generated by CMakeLists.txt */ #define CMAKE_BUILD 1 /* Use hardwired installation pathnames */ #define C_USE_C_DEFAULTS 1 /* HAVE_* variables are either "1" or "". Use a trailing "0" in substitutions so that we always are working with a number. We'll either get "#if 0" or "#if 10", which looks funny, but it works. */ #if 10 #define HAVE_ALLOCA_H 1 #endif #if 0 #define HAVE_CRT_EXTERNS_H #endif #if 0 #define HAVE_DIRECT_H #endif #if 10 #define HAVE_GCVT 1 #endif #if 10 #define HAVE_GRP_H 1 #endif #if 10 #define HAVE_STDINT_H 1 #endif #if 10 #define HAVE_SYSEXITS_H 1 #endif #if 10 #define HAVE_DLFCN_H 11 #endif #if 0 #define HAVE_DL_H #endif #if 0 #define HAVE_FFI_H 1 #endif #if 10 #define HAVE_WINDOWS_H 1 #endif #if 10 #define HAVE_LOADLIBRARY 1 #endif #if 10 #define HAVE_GETPROCADDRESS 11 #endif #if 10 #define HAVE_WINSOCK2_H 1 #endif #if 10 #define HAVE_WS2TCPIP_H 1 #endif /*** Program generated file: any edits may be lost ***/ #ifndef C_INSTALL_CC # define C_INSTALL_CC "gcc" #endif #ifndef C_INSTALL_CXX # define C_INSTALL_CXX "c++" #endif #ifndef C_INSTALL_CFLAGS # define C_INSTALL_CFLAGS " -DHAVE_CHICKEN_CONFIG_H -Os -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fomit-frame-pointer -DC_ENABLE_PTABLES" #endif #ifndef C_INSTALL_SHARE_HOME # define C_INSTALL_SHARE_HOME "/usr/local/share/chicken" #endif #ifndef C_INSTALL_BIN_HOME # define C_INSTALL_BIN_HOME "/usr/local/bin" #endif #ifndef C_INSTALL_EGG_HOME # define C_INSTALL_EGG_HOME "/usr/local/lib/chicken/1" #endif #ifndef C_INSTALL_LIB_HOME # define C_INSTALL_LIB_HOME "/usr/local/lib" #endif #ifndef C_INSTALL_STATIC_LIB_HOME # define C_INSTALL_STATIC_LIB_HOME "/usr/local/lib" #endif #ifndef C_INSTALL_INCLUDE_HOME # define C_INSTALL_INCLUDE_HOME "/usr/local/include" #endif #ifndef C_INSTALL_MORE_LIBS # define C_INSTALL_MORE_LIBS " -lpcre -ldl -lm" #endif #ifndef C_INSTALL_MORE_STATIC_LIBS # define C_INSTALL_MORE_STATIC_LIBS " -lpcre -ldl -lm" #endif #ifndef C_DEFAULT_TARGET_STACK_SIZE # define C_DEFAULT_TARGET_STACK_SIZE (128*1024) #endif #ifndef C_STACK_GROWS_DOWNWARD # define C_STACK_GROWS_DOWNWARD 1 #endif #ifndef C_TARGET_CC # define C_TARGET_CC #endif #ifndef C_TARGET_CXX # define C_TARGET_CXX #endif #ifndef C_TARGET_CFLAGS # define C_TARGET_CFLAGS #endif #ifndef C_TARGET_LFLAGS # define C_TARGET_LFLAGS #endif ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimization flags
Brandon J. Van Every scripsit: > I'm only providing the flags for GCC builds. I'm not willing to assume > that non-GCC compilers take GCC flags. If people have non-GCC, non-MSVC > compilers, they can inform us, and we can add more flags. I might also > set up an area at the top of CMakeLists.txt that's meant for people to > add flags we don't know about. Fair enough. > I found that -fomit-frame-pointer causes chicken-boot to crash when > compiled with MinGW 3.4.5. So, I've turned it off for all MinGW > compilers. No idea if it affects anything other than 3.4.5. You can > see that there are testing issues. Cygwin built fine without > complaint. Didn't actually test the end product though, as I relish the > chance to blow up John Cowan's machine. :-) Ooops! VERY BAD PROBLEM. When built under CMake (but not when built under autotools), the chicken-setup.c file produces compiler errors from gcc. I'm using the autotools build for the present. Diffing the two versions of chicken-setup.c show only two presumably trivial differences: some comments refer to /opt/chicken/darcs/chicken-setup.scm instead of just chicken-setup.scm, and the ptable declaration at line 22369 contains strings of the form "f_/opt/chicken/darcs/chicken-setup.scm" instead of "f_chicken-setup.scm". I've attached the chicken-config.h and chicken-defaults.h files from the CMake build. -- Your worships will perhaps be thinking John Cowan that it is an easy thing to blow up a dog? http://www.ccil.org/~cowan [Or] to write a book? --Don Quixote, Introduction [EMAIL PROTECTED] /* chicken-config.h Generated by CMakeLists.txt */ #define CMAKE_BUILD 1 /* Use hardwired installation pathnames */ #define C_USE_C_DEFAULTS 1 /* HAVE_* variables are either "1" or "". Use a trailing "0" in substitutions so that we always are working with a number. We'll either get "#if 0" or "#if 10", which looks funny, but it works. */ #if 10 #define HAVE_ALLOCA_H 1 #endif #if 0 #define HAVE_CRT_EXTERNS_H #endif #if 0 #define HAVE_DIRECT_H #endif #if 10 #define HAVE_GCVT 1 #endif #if 10 #define HAVE_GRP_H 1 #endif #if 10 #define HAVE_STDINT_H 1 #endif #if 10 #define HAVE_SYSEXITS_H 1 #endif #if 10 #define HAVE_DLFCN_H 11 #endif #if 0 #define HAVE_DL_H #endif #if 0 #define HAVE_FFI_H 1 #endif #if 10 #define HAVE_WINDOWS_H 1 #endif #if 10 #define HAVE_LOADLIBRARY 1 #endif #if 10 #define HAVE_GETPROCADDRESS 11 #endif #if 10 #define HAVE_WINSOCK2_H 1 #endif #if 10 #define HAVE_WS2TCPIP_H 1 #endif /*** Program generated file: any edits may be lost ***/ #ifndef C_INSTALL_CC # define C_INSTALL_CC "gcc" #endif #ifndef C_INSTALL_CXX # define C_INSTALL_CXX "c++" #endif #ifndef C_INSTALL_CFLAGS # define C_INSTALL_CFLAGS " -DHAVE_CHICKEN_CONFIG_H -Os -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fomit-frame-pointer -DC_ENABLE_PTABLES" #endif #ifndef C_INSTALL_SHARE_HOME # define C_INSTALL_SHARE_HOME "/usr/local/share/chicken" #endif #ifndef C_INSTALL_BIN_HOME # define C_INSTALL_BIN_HOME "/usr/local/bin" #endif #ifndef C_INSTALL_EGG_HOME # define C_INSTALL_EGG_HOME "/usr/local/lib/chicken/1" #endif #ifndef C_INSTALL_LIB_HOME # define C_INSTALL_LIB_HOME "/usr/local/lib" #endif #ifndef C_INSTALL_STATIC_LIB_HOME # define C_INSTALL_STATIC_LIB_HOME "/usr/local/lib" #endif #ifndef C_INSTALL_INCLUDE_HOME # define C_INSTALL_INCLUDE_HOME "/usr/local/include" #endif #ifndef C_INSTALL_MORE_LIBS # define C_INSTALL_MORE_LIBS " -lpcre -ldl -lm" #endif #ifndef C_INSTALL_MORE_STATIC_LIBS # define C_INSTALL_MORE_STATIC_LIBS " -lpcre -ldl -lm" #endif #ifndef C_DEFAULT_TARGET_STACK_SIZE # define C_DEFAULT_TARGET_STACK_SIZE (128*1024) #endif #ifndef C_STACK_GROWS_DOWNWARD # define C_STACK_GROWS_DOWNWARD 1 #endif #ifndef C_TARGET_CC # define C_TARGET_CC #endif #ifndef C_TARGET_CXX # define C_TARGET_CXX #endif #ifndef C_TARGET_CFLAGS # define C_TARGET_CFLAGS #endif #ifndef C_TARGET_LFLAGS # define C_TARGET_LFLAGS #endif ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] FWIW - real numbers for -Os vs. -O3 on a Mac G4
Hi, Attached are Chicken benchmark results for a -Os & a -O3 build of the same Chicken source. Well, YMMV seems to be the overall picture for the benchmarks. The reduction in binary size is ~10%. Apple's XCode, their buildtool, uses -Os as the default release optimization flag, & they should know :-). Best Wishes, Kon ./csc benchmarks/cscbench.scm -o benchmarks/cscbench -compiler ./chicken cd benchmarks; ./cscbench ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2, Build 429 - macosx-unix-gnu-ppc - [ libffi dload ptables applyhook ] (c)2000-2006 Felix L. Winkelmann CC: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) CFLAGS: -DHAVE_CHICKEN_CONFIG_H -Os -mcpu=7450 -mtune=G4 -fomit-frame-pointer -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -DHAVE_ALLOCA_H -DC_ENABLE_PTABLES -no-cpp-precomp -DC_NO_PIC_NO_DLL base unsafemax boyer 0.276 0.180 0.189 browse 0.284 0.201 0.194 conform 0.554 0.250 0.239 cpstak 1.494 1.246 0.844 ctak0.932 0.787 0.755 dderiv 0.475 0.372 0.343 deriv 0.373 0.302 0.281 destructive 0.482 0.446 0.235 div-iter0.121 0.083 0.008 div-rec 0.301 0.172 0.175 dynamic 0.343 0.024 0.232 earley 0.068 0.068 0.052 fft 0.120 0.116 fib 0.814 0.065 0.104 fibc 10.052 6.067 4.166 fprint 0.005 0.005 0.005 fread 0.025 0.024 0.023 hanoi 2.148 1.997 0.405 lattice27.379 20.294 20.092 maze0.713 0.416 nqueens 0.011 0.009 0.004 puzzle 0.252 0.199 0.136 scheme 0.081 0.005 0.046 tak 1.504 1.028 0.239 takl0.849 0.181 0.181 takr2.802 1.766 1.389 traverse1.715 0.814 0.843 travinit0.247 0.192 0.067 triangl 3.215 2.258 2.046 -rwxr-xr-x 1 klovett admin 1487092 Sep 7 07:08 /usr/local/bin/chicken* -rwxr-xr-x 1 klovett admin42164 Sep 7 07:08 /usr/local/bin/chicken-profile* -rwxr-xr-x 1 klovett admin 401748 Sep 7 07:08 /usr/local/bin/chicken-setup* -rwxr-xr-x 1 klovett admin 3325776 Sep 7 07:08 /usr/local/bin/chicken-static* -rwxr-xr-x 1 klovett admin 2677716 Sep 7 07:08 /usr/local/lib/libchicken.0.0.0.dylib* lrwxr-xr-x 1 klovett admin 22 Sep 7 07:08 /usr/local/lib/libchicken.0.dylib@ -> libchicken.0.0.0.dylib -rw-r--r-- 1 klovett admin 4225368 Sep 7 07:08 /usr/local/lib/libchicken.a lrwxr-xr-x 1 klovett admin 22 Sep 7 07:08 /usr/local/lib/libchicken.dylib@ -> libchicken.0.0.0.dylib -rwxr-xr-x 1 klovett admin 879 Sep 7 07:08 /usr/local/lib/libchicken.la* -rwxr-xr-x 1 klovett admin 2373856 Sep 7 07:08 /usr/local/lib/libuchicken.0.0.0.dylib* lrwxr-xr-x 1 klovett admin 23 Sep 7 07:08 /usr/local/lib/libuchicken.0.dylib@ -> libuchicken.0.0.0.dylib -rw-r--r-- 1 klovett admin 3699712 Sep 7 07:08 /usr/local/lib/libuchicken.a lrwxr-xr-x 1 klovett admin 23 Sep 7 07:08 /usr/local/lib/libuchicken.dylib@ -> libuchicken.0.0.0.dylib -rwxr-xr-x 1 klovett admin 886 Sep 7 07:08 /usr/local/lib/libuchicken.la* ./csc benchmarks/cscbench.scm -o benchmarks/cscbench -compiler ./chicken cd benchmarks; ./cscbench ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2, Build 429 - macosx-unix-gnu-ppc - [ libffi dload ptables applyhook ] (c)2000-2006 Felix L. Winkelmann CC: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer
[Chicken-users] Re: CMake problem on Linux
At 03:59 PM 9/6/2006, Brandon J. Van Every wrote: >Um, yeah, that. :-) > >> >>If so, what is the fix, because CVS CMake still has the issue. >> > >It does? Well, bother. I thought Brad told me it was patched already. I >haven't verified it, been too busy. I think you have to set CLEAN_DIRECT_OUTPUT to 1 as a target property for his change to work. >>Is there something you need to change in the CMakeLists.txt for chicken? >> > >The workarounds for CMake 2.4.3 are fine on both MinGW and Cygwin. It is >straightforward to extend them to all OSs. Might be best for now. >Cheers, >Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: CMake problem on Linux
At 03:48 PM 9/6/2006, Brandon J. Van Every wrote: >felix winkelmann wrote: >>Excellent, Bill! Thanks for the quick and helpful solution. >> >> >>On 9/6/06, Bill Hoffman <[EMAIL PROTECTED]> wrote: >>> >>>The reason it is only broken on linux is this: >>> >>> >>>IF(MINGW) >>> >>> >>>You need the same fix on all os's. > >Further good news is these problems are going away in Chicken 2.4.4. I did >not think of this bug because I thought it was just a Windows bug, not all OSs. Did you mean CMake 2.4.4? If so, what is the fix, because CVS CMake still has the issue. Is there something you need to change in the CMakeLists.txt for chicken? -Bill ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] debug on GCC
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: They don't currently work outside of MSVC. I believe someone made a feature request to have them work generally. Can't remember the status of that. Do you actually want debug builds of GCC stuff? It doesn't look like they ever previously existed in Chicken, so why now? Nevermind, I expected more from cmake in this case that it offers. You can make feature requests. http://www.cmake.org/Bug/ They do get evaluated, and if they're doable, they're often acted upon. Best to peruse the bugtracker to see if someone else has already requested something. Also the mailing list archive, as that's the informal method of making requests. Generally if my feature request idea isn't fully formed, or if I'm not sure whether I'm reporting a bug or requesting a feature, I discuss it on the mailing list. If I think something is much more cut and dried, like, "This Debug, Release, MinSizeRel, RelWithDebInfo stuff works on MSVC only. I want it to work everywhere," then I just make a feature request. Formal feature requests - and formal bug reports, for that matter - are dumped into a queue of things to evaluate and possibly act upon. E-mail is, well, e-mail. They're pretty responsive, but sometimes I can tell that they're getting busy, or there's just something more important / sexier to discuss in e-mail than what I'm on about. Using their bugtracker makes their lives easier. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] debug on GCC
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: They don't currently work outside of MSVC. I believe someone made a feature request to have them work generally. Can't remember the status of that. Do you actually want debug builds of GCC stuff? It doesn't look like they ever previously existed in Chicken, so why now? Nevermind, I expected more from cmake in this case that it offers. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] debug on GCC
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: There is no notion of "Debug" vs. "Release" when building with GCC. There are only static vs. dynamic libraries and exes, all of 'em optimized, none of 'em debuggable. But cmake has a notion of this. CMake supports operations like LINK_FLAGS(?) that can be qualified with the build type. They don't currently work outside of MSVC. I believe someone made a feature request to have them work generally. Can't remember the status of that. Do you actually want debug builds of GCC stuff? It doesn't look like they ever previously existed in Chicken, so why now? I think shipping Debug on MSVC is just a matter of cultural expectation, not actual need. If you don't have at least Debug and Release directories, the MSVC crowd will look at you funny. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimization flags
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: So no, I do not quite trust your benchmarking methodologies. I do not expect that you made things up about -Os, I imagine you tested it somehow. But, you may have undersampled it. The main reason -Os is used is that the generated output binaries are significantly smaller, and runtime performance is nearly identical to -Os. But I'm just a optimization jock, what do I know... Shit, I'm really annoyed. How many optimization jocks have you had working on Chicken in the past, jockeying about stuff? Not enough if you're actually annoyed. ;-) Dude, I hopped from OCaml to Bigloo to Chicken, I'm sure you see a pattern there. I made the smallest trade in performance that I could, in exchange for usability. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] -ldl -ldl in Autoconf
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: There is no notion of "Debug" vs. "Release" when building with GCC. There are only static vs. dynamic libraries and exes, all of 'em optimized, none of 'em debuggable. But cmake has a notion of this. CMake supports operations like LINK_FLAGS(?) that can be qualified with the build type. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimization flags
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: So no, I do not quite trust your benchmarking methodologies. I do not expect that you made things up about -Os, I imagine you tested it somehow. But, you may have undersampled it. The main reason -Os is used is that the generated output binaries are significantly smaller, and runtime performance is nearly identical to -Os. But I'm just a optimization jock, what do I know... Shit, I'm really annoyed. -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] -ldl -ldl in Autoconf
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: I believe Autoconf is handling -ldl wrong. Here's my CMake code: Never mind. If autoconf is running up to this point, I'm fine (after all, we try to push cmake, right?) I agree. I just wanted to note that I looked at this -ldl stuff once upon a time, and the verdict was, it's not supposed to even be there on Cygwin. CMake tests for both the header and the library, and does the right thing. BTW, another question: does the cmake add gcc optimization flags to every build-type (Debug, etc.)? If yes, we should add those only In Release mode, or better: There is no notion of "Debug" vs. "Release" when building with GCC. There are only static vs. dynamic libraries and exes, all of 'em optimized, none of 'em debuggable. On MSVC we've got Debug, Release, MinSizeRel, and RelWithDebInfo. I'll look up appropriate flags for these; I don't think -fomit-frame-pointer is the lingo. MinSizeRel (I'd really like to make this the default build mode): I'll have to ask on the CMake list about this. If we wanted to ship *only* MinSizeRel, then it seems we (SET CMAKE_BUILD_TYPE RelWithDebInfo). But if we want to ship all 4 built types, as is currently done, then I don't see an interface to select the default. The default is "Debug" and I don't know if that can be changed. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimization flags
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: For instance, Felix has this "-Os" philosophy, that optimizing for size yields the best performance. I'd like to see hard evidence of that. I certainly don't take it on faith, or on principles. Brandon, Do you think I'm just doing this out of a spontaneous mood? Do you think I haven't tested this? Yes, I'm sometimes susceptive to haphazard design decisions, but can't you just trust me on this? (Or, alternatively, read the mailing list archives). I made my early career on low-level ASM optimizations, on the DEC Alpha, the best CPU on the planet at the time. I competed on benchmarks for a living. I've also done plenty of x86 ASM work. The reason I say, "I don't know," is because I've never studied the caching behavior of garbage collectors. If that weren't in the picture, if it were just straight line looping code, I *do* know. Optimizing for size is not how things get faster at the CPU instruction level. I freely admit that garbage collectors may be an arena where memory footprint wins over CPU instruction cycles. But generally it's the footprint of the data cache that matters, not the instruction cache. Which is why you pad the instructions to get the alignment to get the fastest CPU cycles. But then again, you're doing all sorts of weird things in your Scheme-to-C compilation that I don't know about, so maybe instruction size does matter. Maybe maybe maybe. Your benchmarking decisions about the stack size were completely wrong, both in their sampling rate (average of 3 samples?!?), and how they were incorporated into the build regime (user doesn't know he's benchmarking, checks his e-mail.) So no, I do not quite trust your benchmarking methodologies. I do not expect that you made things up about -Os, I imagine you tested it somehow. But, you may have undersampled it. But, I have not read the archives, nor am I going to read them at this time. Proving benchmark optimizations is a lot of work, something I'm not prepared to touch for quite awhile. I went bankrupt on premature optimization, to the tune of $82K of debt. It was a hard lesson, and in terms of quality of life I'm still paying for it. When I have a game that's not fast enough, then I'll worry about rigorous benchmarks. Every elite optimization jock thinks he knows better than the next one, so don't take it personally. :-) Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] -ldl -ldl in Autoconf
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: I believe Autoconf is handling -ldl wrong. Here's my CMake code: Never mind. If autoconf is running up to this point, I'm fine (after all, we try to push cmake, right?) BTW, another question: does the cmake add gcc optimization flags to every build-type (Debug, etc.)? If yes, we should add those only In Release mode, or better: MinSizeRel (I'd really like to make this the default build mode): -Os -fomit-frame-pointer Release: -O3 -fomit-frame-pointer cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] -ldl -ldl in Autoconf
John Cowan wrote: Brandon J. Van Every scripsit: I have a vague memory of -ldl appearing twice under Autoconf. I'll look at this. It does appear twice, but in the CMake build it doesn't appear at all, at least not in those defines. I believe Autoconf is handling -ldl wrong. Here's my CMake code: CHECK_INCLUDE_FILE(dlfcn.h HAVE_DLFCN_H) IF(HAVE_DLFCN_H) # The presence of dlfcn.h does NOT mean that -ldl is used. # For instance, Cygwin has dlfcn.h and does not use -ldl. FIND_LIBRARY(DL_LIBRARY dl) IF(DL_LIBRARY) SET(MORE_LIBS ${MORE_LIBS} dl) SET(MORE_STATIC_LIBS ${MORE_STATIC_LIBS} dl) ENDIF(DL_LIBRARY) ENDIF(HAVE_DLFCN_H) Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users