Re: [Chicken-users] Chicken-setup 2.3 fails on Cygwin
I can get this to duplicate as well. I wondered for a while why this doesn't happen with the MINGW build and took a look at the create-directory lambda in chicken-setup. I noticed that in the verbose output we were not getting an echo of the create-directory function. So I changed the function to this: (define create-directory (if windows (lambda (dir) (when (run-verbose) (printf win: creating directory `~a'~%~! dir)) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) Sure enough it spits out win: creating directory `numbers.egg.dir' I would guess that it should use mkdir on cygwin. The question is how to figure out if we are on cygwin. Pat On 3/21/06, John Cowan [EMAIL PROTECTED] wrote: Matthew Welland scripsit: No idea if this is related but I had a similar problem where if the current directory had a space in the path chicken-setup would fail. Running chicken-setup in a location where the path was free of spaces worked fine. That's one of the classic problems with porting Unix programs to Cygwin. Of course, it's a problem in principle on Unix too, but it doesn't come up as often. Usually a discreet use of double-quotes around the $PATH variable solves the problem. -- XQuery Blueberry DOMJohn Cowan Entity parser dot-com [EMAIL PROTECTED] Abstract schemata http://www.ap.org XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken-setup 2.3 fails on Cygwin
This works for chicken-setup.scm create-directiory on cygwin: (define create-directory (if (and windows (not (eq? (build-platform) 'cygwin))) (lambda (dir) (when (run-verbose) (printf creating directory `~a'`~a' ~%~! dir )) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) Maybe, if others think it is ok, it should be added to chicken-setup.scm. Pat On 3/22/06, Patrick Brannan [EMAIL PROTECTED] wrote: I can get this to duplicate as well. I wondered for a while why this doesn't happen with the MINGW build and took a look at the create-directory lambda in chicken-setup. I noticed that in the verbose output we were not getting an echo of the create-directory function. So I changed the function to this: (define create-directory (if windows (lambda (dir) (when (run-verbose) (printf win: creating directory `~a'~%~! dir)) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) Sure enough it spits out win: creating directory `numbers.egg.dir' I would guess that it should use mkdir on cygwin. The question is how to figure out if we are on cygwin. Pat On 3/21/06, John Cowan [EMAIL PROTECTED] wrote: Matthew Welland scripsit: No idea if this is related but I had a similar problem where if the current directory had a space in the path chicken-setup would fail. Running chicken-setup in a location where the path was free of spaces worked fine. That's one of the classic problems with porting Unix programs to Cygwin. Of course, it's a problem in principle on Unix too, but it doesn't come up as often. Usually a discreet use of double-quotes around the $PATH variable solves the problem. -- XQuery Blueberry DOMJohn Cowan Entity parser dot-com [EMAIL PROTECTED] Abstract schemata http://www.ap.org XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken-setup 2.3 fails on Cygwin
Whoops, I left some debugging refuse in what I sent in. Try this instead: (define create-directory (if (and windows (not (eq? (build-platform) 'cygwin))) (lambda (dir) (when (run-verbose) (printf creating directory `~a' ~%~! dir )) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) On 3/22/06, Patrick Brannan [EMAIL PROTECTED] wrote: This works for chicken-setup.scm create-directiory on cygwin: (define create-directory (if (and windows (not (eq? (build-platform) 'cygwin))) (lambda (dir) (when (run-verbose) (printf creating directory `~a'`~a' ~%~! dir )) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) Maybe, if others think it is ok, it should be added to chicken-setup.scm. Pat On 3/22/06, Patrick Brannan [EMAIL PROTECTED] wrote: I can get this to duplicate as well. I wondered for a while why this doesn't happen with the MINGW build and took a look at the create-directory lambda in chicken-setup. I noticed that in the verbose output we were not getting an echo of the create-directory function. So I changed the function to this: (define create-directory (if windows (lambda (dir) (when (run-verbose) (printf win: creating directory `~a'~%~! dir)) (foreign-lambda void create_directory c-string)) (lambda (dir) (when (run-verbose) (printf creating directory `~a'~%~! dir)) (system* mkdir -p ~a dir) ) ) ) Sure enough it spits out win: creating directory `numbers.egg.dir' I would guess that it should use mkdir on cygwin. The question is how to figure out if we are on cygwin. Pat On 3/21/06, John Cowan [EMAIL PROTECTED] wrote: Matthew Welland scripsit: No idea if this is related but I had a similar problem where if the current directory had a space in the path chicken-setup would fail. Running chicken-setup in a location where the path was free of spaces worked fine. That's one of the classic problems with porting Unix programs to Cygwin. Of course, it's a problem in principle on Unix too, but it doesn't come up as often. Usually a discreet use of double-quotes around the $PATH variable solves the problem. -- XQuery Blueberry DOMJohn Cowan Entity parser dot-com [EMAIL PROTECTED] Abstract schemata http://www.ap.org XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken-setup 2.3 fails on Cygwin
Can you run it with -v (verbose) and post the output? On 3/20/06, John Cowan [EMAIL PROTECTED] wrote: I built Chicken 2.3 from source on a Cygwin system that had no previous copy of Chicken on it. It built and installed successfully, but chicken-setup consistently fails as follows: $ chicken-setup numbers The extension numbers does not exist. Do you want to download it ? (yes/no/abort) [yes] yes downloading catalog ... downloading catalog from www.call-with-current-continuation.org ... downloading numbers.egg from (www.call-with-current-continuation.org eggs/ 80) ... Error: (change-directory) can not change current directory - No such file or directory: numbers.egg.dir Creating numbers.egg.dir myself does not help. It does not matter which egg I try to install; repeating this run correctly skips the download step but then crashes with the same error. -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.ap.org The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mingw Makefile and Instructions
Felix, Sorry for the delay. I've been on vacation. Anyway, it is not quite as simple as just replacing a few lines. If we did that we would break the rest of the Unix builds. I need to change a couple of the conditionals in csc.scm.in so that they have three cases: one for Unix, one for MINGW, and one for Win32. There is the possibility that I could make the Unix case universal, but since I don't have a Linux box at the moment I worry about not testing and breaking the build for everyone. I will work on something tonight and send in a real patch file. Pat ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mingw Makefile and Instructions
I would certainly agree that this is not the right way to do things. A few patches that correctly identify MINGW would be pretty easy to implement. Right now, csc thinks everything is either Unix or Windows. And there are hard coded assumptions for either model. A good fix shouldn't be too hard. On 3/1/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Patrick Brannan wrote: I recommend that you eliminate all extraneous path entries. I ran into some strange linking issues with some of my standard path entries. == Change these files: *** csc.scm.in Line 105 remove '-DHAVE_CHICKEN_CONFIG ' Line 185 should be: (define default-library-files '(%staticlibfiles%)) Line 529 should be: (set! compile-options (cons* -DC_SHARED compile-options)) *** chicken.h Line 80 should be # if defined(__CYGWIN__) We need to resolve what The Right Way To Do Things [TM] actually is. In my experience, asking people to change the source code to perform a build, does not result in builds that other people replicate. It's usually too much of a PITA, error prone, and even if someone else gets it working, the next person who comes along goes through a learning curve all over again. If these changes are supposed to be in the source, then let's make them. If they shouldn't, if they would impact other ways of building Chicken, then let's figure out a way that doesn't. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MINGW Build with make file and no MS Tools
I agree that we should merge the efforts at some point. I was just having a lot of problems with basic compilation and linking issues and cmake was getting in the way. Not because it is bad, but because it is a whole new language that I did not really learn well. While I am not a make genius, I do know it and what I don't know is well documented. The focus of my efforts was in getting the basic chicken tools building with MINGW and no MS dependencies. I'm trying to work out things like compiler flags, code patches, and a day to day working environment. This should help chicken move forward on the win32 platform. Patrick ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MINGW Build with make file and no MS Tools
Sergey, I just reran the instructions in the read me. My console session and the output from make are attached. I think that the problem is the inclusion of posix.c intstead of posixwin.c. I believe that there will be a few others following that one. On a separate topic. I just realized that the batch file in my readme was out of date. I will get it all together, rerun the build and send it in. Pat Instructions + Console Session CURRENT MINGW BUILD FAILURE MinGW: Use the MSYS environment (http://www.mingw.org/msys.shtml) available for MinGW. This will let the installation be done according to the UNIX instructions below. (The BOOTSTRAP_PATH make option may be specified in a form like C:/chicken-1.66 ... spaces in the path to the existing CHICKEN installation will cause problems) Sergey Khorev reported how to build Chicken under MinGW with support for shared libraries with some hacking involved: 1) Install MinGW and MSYS 2) Don't use rxvt (default MSYS shortcut), better run MSYS's shell using command sh --login -i 3) ./configure 4) edit Makefile to set BOOTSTRAP_PATH if required 5) patch libtool with sed -e 's/\(deplibs_check_method=\).*/\1pass_all/' libtool libtool.new cp libtool.new libtool (it seems that libtool tries to be too smart, giving stupid results). 6) mkdir $MINGWDIR/lib/.libs; cp $MINGWDIR/lib/libws2_32.a $MINGWDIR/lib/.libs/libws2_32.dll.a where MINGWDIR is the where MinGW is installed 7) make, make install, enjoy You might want to use C regular expressions package instead of the default one, written in Scheme. In this case you should download latest packages from http://gnuwin32.sf.net (either pcre-*-bin.zip, pcre-*-dep.zip, pcre-*-lib.zip or regex-spencer-*-bin.zip and regex-spencer-*-lib.zip). Unpack downloaded zip files into one directory. Steps 1) and 2) as above. 3a) For simplicity create environment variable with its path, e.g. export RE_DIR=c:/Devel/pcre Then copy import libraries: cd RE_DIR/lib mkdir .libs If you use PCRE, issue cp libpcre.dll.a .libs else cp libregex.dll.a .libs Put libpcre0.dll or regex.dll somewhere to PATH (e.g. WINDOWS\System32) 3b) CFLAGS=-I$RE_DIR/include CPPFLAGS=-I$RE_DIR/include LDFLAGS=-L$RE_DIR/lib ./configure Other steps like in normal MinGW build Console Session: $ env ... !C:=C:\msys\1.0\bin ... SYSTEMDRIVE=C: WINDIR=C:\WINDOWS $ MACHTYPE=i686-pc-msys PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 5, GenuineIntel OS=Windows_NT MSYSTEM=MINGW32 PROCESSOR_ARCHITECTURE=x86 TEMP=/tmp PROCESSOR_LEVEL=6 SYSTEMROOT=C:\WINDOWS HOMEDRIVE=\\ MAKE_MODE=unix SHELL=/bin/sh HOSTTYPE=i686 SESSIONNAME=Console OSTYPE=msys TERM=cygwin PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32 _=/bin/env ... $ ./configure checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... none checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking for a BSD-compatible install... /bin/install -c checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... C:/mingw/mingw32/bin/ld.exe checking if the linker (C:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for C:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking for as... as checking for objdump... objdump checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no
[Chicken-users] MINGW Build with make file and no MS Tools
Now I have chicken 2.3 building with mingw and no MS tools at all. Everything works including csc, chicken-setup, and dll eggs. [Some of the eggs don't work, but I think that it is a separate problem.] If anyone cares I will get this organized and send it in. Meanwhile, I have attached a text file and some instructions. Personally I think this will be a good way for a lot of win32 users to go. None of the code changes that I made are significant and the getting started process is fairly simple. Patrick By the way - the existing mingw installation instructions, in the readme, do not work at all. Building Chicken With Mingw and Msys Chicken Version 2.3 == Mingw Setup Mingw Packages - http://www.mingw.org/download.shtml mingw-runtime-3.9.tar.gz w32api-3.6.tar.gz gcc-core-3.4.2-20040916-1.tar.gz binutils-2.15.91-20040904-1.tar.gz mingw-utils-0.3.tar.gz gcc-g++-3.4.2-20040916-1.tar.gz [Probably not needed] MSYS-1.0.10.exe msysDTK-1.0.1.exe [For sed you can get elsewhere save some space] You probably don't need all of the packages listed, but at a minimum you will need the mingw-runtime, gcc, w32api, and msys packages. I installed the others. 1. Extract the gz files into C:\mingw. If you put them anywhere else you will need to adjust all paths accordingly 2. Run the msys installer. It will run a script following the install. As the script runs you will be prompted for two items: - Where is you mingw? Enter the correct location. - Make fstab entries? Say yes. You should be done with mingw setup at this point. == Alternate setup using Dev-C++ Bloodshed Dev-C++ Packages - I used the package updater to get/update win32, gcc, and binutils. == Other Tools You will need sed if you want to use csc. This is because we preprocess csc to substitute text for tool locations. There are several places that you can get sed for windows. If you have gone with the mingw / msys installation you should already have it. If you used the Dev-C++ installation you will probably need to get it from http://unxutils.sourceforge.net/. Make sure that you get it on you path. == Set up the path Set your path and start a command prompt using something like this batch file: set CHICKEN_HOME=C:\working\mingw-only\chicken-2.3 set MINGW_PATH=C:\mingw\bin;C:\msys\1.0\bin set PATH=C:\working\mingw-only\chicken-2.3;%MINGW_PATH%;C:\WINDOWS\system32; cmd.exe Now you can just run this batch file to get a working environment. I recommend that you eliminate all extraneous path entries. I ran into a lot of problems when I used my standard classpath. Since I do all sorts of development on this machine the path environment variable had many entries. Somehow the executables I was creating required strange dlls to run. Since you, like me, probably don't want exes that require dlls from Oracle's jre distribution, eliminate the problem in the first place by getting rid of any extra path entries. == Customize the variables at the top of the make file Look at the top of the make file and set the variables as appropriate. There should be a better way to do this than hardwired values, but right now there isn't. == Build Chicken make -f Makefile.mingw chicken.exe After you build it try running chicken.exe against an scm file. It should produce a c file if everything worked out ok. == Build CSI make -f Makfile.mingw csi.exe Try it out! == Build CSC make -f Makefile.mingw csc.exe Try it out with csc foo.scm bar.scm. == Issues *** I can build chicken to use a shared library and it works fine, but it creates a huge exe. I don't really know what I'm doing, so if anyone has any ideas I would be glad to hear them. The -DPIC option does not work at all and cannot be used. There is probably something basic wrong here but I don't know what it is. Gcc knows about file extensions so if you use unusual file extensions like .obj or .obs gcc doesn't link the dlls and exes. Somebody who knows more about gnu C developement could probably fix this problem in 5 minutes. *** The method that csc.scm uses to obtain tool locations is unusual. It would be nice if it read a config file or used environment variables instead.
Re: [Chicken-users] benchmarks and test suites
I don't think that STACK_GROWS_DOWNWARDS has any effect on WIN32 builds. I've had it in and out and it has made no difference. More concerning is the hard-coding of things like -DHAVE_CHICKEN_CONFIG_H in csc.scm.in. Since this isn't setup for windows who knows what might go wrong. Right now csc works ok with the following mods when it is run through sed as it is in the mingw makefile I attached. *** csc.scm.in Line 105 removed the -DHAVE_CHICKEN_CONFIG define Line 185 (define default-library-files '(%libdir%/libchicken.a)) (define default-library-files '(%staticlibfiles%)) Line 529 Removed -fPIC and -DPICBy the way, I ran all of the benchmarks and they worked fine. Pat On 2/25/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Patrick Brannan wrote: Fixing the PIC thing involved changing line 80 of chicken.h from # if defined(__CYGWIN__) || defined(__MINGW32__) to # if defined(__CYGWIN__) I'm not sure exactly why, but the c pre-processor was generating some funny dllimport dllexport statements with the __MINGW32__ in there. Every benchmark I have tried has run. After some patches csc and chicken-setup ran as well. I think we may be the only two who care about this. Nevertheless, I will document my changes and post them. Chicken is a lot of fun to work with.You know, I've been around that issue.But I guess I didn't resolve it.My issue turned out to be a -D typo, and so I never did verifywhether the #if you show above was correct or not.Another issue I'munclear on is STACK_GROWS_DOWNWARDS.Cheers,Brandon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Problem with -DPIC When Building with MinGw
Well, after looking at the preprocessor output I figured it out. All it took was a small change to chicken.h. There were also some patches to csc.scm.in. Anyway, now I have chicken 2.3 building with mingw and no MS tools at all. Everything works including csc, chicken-setup, and dll eggs. If anyone cares I will get this organized and send it in. Personally I think this will be a good way for a lot of win32 users to go. None of the code changes that I made are significant and the getting started process is fairly simple. Patrick By the way - the existing mingw installation instructions, in the readme, do not work at all.On 2/24/06, Patrick Brannan [EMAIL PROTECTED] wrote:I have a question about building chicken 2.3 with mingw. Why does -DPIC cause mingw to fail while linking the dll? Everything works fine without -DPIC except for the dynamic extensions. I probably missed something simple, but I don't see what it is. I'm definitely operating at the outer edges of my gcc / linking knowledge. The make file and an explanatory text doc are attached. When we build chicken 2.3 with the attached build file and -DPIC defined the build fails when linking the dll with the following output from mingw's gcc: gcc -shared ./runtime.o ./library.o ./eval.o ./profiler.o ./scheduler.o ./extras.o ./match-support.o ./lolevel.o ./tinyclos.o ./pregexp.o ./utils.o ./tcp.o ./posixwin.o ./srfi-1.o ./srfi-4.o ./srfi-13.o ./srfi-14.o ./srfi-18.o ./stub.o -lws2_32 -o libchicken.dll -Wl,--image-base=0x1000 -Wl,--out-implib,libchicken.a Creating library file: libchicken.a ./extras.o(.text+0x10f):extras.c: undefined reference to `_imp__C_temporary_stack' ./extras.o(.text+0x130):extras.c: undefined reference to `_imp__C_temporary_stack' ... Lots more like this. _C_temporary_stack is defined in chicken.h When built with cygwin the link command is executed as follows and it works: gcc -shared .libs/libchicken_la-runtime.o .libs/libchicken_la-library.o .libs/libchicken_la-eval.o .libs/libchicken_la-profiler.o .libs/libchicken_la-scheduler.o .libs/libchicken_la-extras.o .libs/libchicken_la-match-support.o .libs/libchicken_la-lolevel.o .libs/libchicken_la-tinyclos.o .libs/libchicken_la-utils.o .libs/libchicken_la-tcp.o .libs/libchicken_la-pcre.o .libs/libchicken_la-posix.o .libs/libchicken_la-stub.o .libs/libchicken_la-srfi-1.o .libs/libchicken_la-srfi-4.o .libs/libchicken_la-srfi-13.o .libs/libchicken_la-srfi-14.o .libs/libchicken_la-srfi-18.o /usr/lib/libpcre.dll.a -o .libs/cygchicken-0.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libchicken.dll.a = As an example here are the commands used to build runtime.o and extras.o under cygwin: gcc -DHAVE_CONFIG_H -I. -I. -I. -DC_STACK_GROWS_DOWNWARD=1 -DC_INSTALL_LIB_HOME=\/usr/local/lib/chicken\ -DC_INSTALL_HOME=\/usr/local/share/chicken\ -DC_USE_C_DEFAULTS -DC_NO_PIC_NO_DLL -DC_BUILDING_LIBCHICKEN -Os -fomit-frame-pointer -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -DHAVE_ALLOCA_H -c runtime.c -DPIC -o .libs/libchicken_la-runtime.o gcc -DHAVE_CONFIG_H -I. -I. -I. -DC_STACK_GROWS_DOWNWARD=1 -DC_INSTALL_LIB_HOME=\/usr/local/lib/chicken\ -DC_INSTALL_HOME=\/usr/local/share/chicken\ -DC_USE_C_DEFAULTS -DC_NO_PIC_NO_DLL -DC_BUILDING_LIBCHICKEN -Os -fomit-frame-pointer -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -DHAVE_ALLOCA_H -c extras.c -DPIC -o .libs/libchicken_la-extras.o Here are the commands used to build runtime.o and extras.o under mingw: gcc -Os -DC_DEFAULT_TARGET_STACK_SIZE=30 -DC_STACK_GROWS_DOWNWARD=1 -DC_NO_PIC_NO_DLL -DHAVE_LOADLIBRARY -DHAVE_GETPROCADDRESS -DHAVE_WINDOWS_H -Wno-unused -Wno-uninitialized -IC:/working/mingw-only/chicken-2.3 -DPIC -DC_BUILDING_LIBCHICKEN -c runtime.c -oruntime.o gcc -c -Os -DC_DEFAULT_TARGET_STACK_SIZE=30 -DC_STACK_GROWS_DOWNWARD=1 -DC_NO_PIC_NO_DLL -DHAVE_LOADLIBRARY -DHAVE_GETPROCADDRESS -DHAVE_WINDOWS_H -Wno-unused -Wno-uninitialized -IC:/working/mingw-only/chicken-2.3 -DPIC extras.c -o extras.o Using nm to look at the symbols under cygwin: $ nm libchicken_la-runtime.o | grep temporary_stack 0010 C _C_temporary_stack 0010 C _C_temporary_stack_bottom 0010 C _C_temporary_stack_limit ... $ nm libchicken_la-extras.o | grep temporary_stack U _C_temporary_stack U
Re: [Chicken-users] purpose of dynamic Chicken libraries?
Brandon, I have given this some thought and I have come to the conclusion that having chicken.dll and dynamic chicken.exe doesn't matter too much. Now, that isn't the same as saying that I don't need to be able to create dll's that can be loaded by other applications. One of my original uses of chicken was to build a dll that was loaded by a WTL (windows c++ gui framework) application. The basic idea worked fine though I never finished the project. But I guess that I could always have linked to a static library. So in the end maybe I would agree with your buddy for this case. And having a single exe, large though it may be, eliminates a lot of potential problems. But what about eggs and csi? If we don't have functioning dynamic libraries will we have to rebuild csi every time we want to load a new library in csi? Back when I actually had chicken working on windows the egg system worked pretty well using dlls. PatOn 2/16/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: For what purposes are dynamic Chicken libraries really essential?Rightnow I'm winning; my -DPIC problems were merely a typo in a define.But,building dynamic libraries is definitely a source of complication and maintenance difficulty.An associate who offered to help me out,suggested that I just drop it, that it's pointless in the scheme ofthings.I replied that I didn't know enough about how people useChicken to make that decision.So, I am asking you, how / why do you use dynamic libraries?If you didn't have them available, how wouldthat impact you?Cheers,Brandon Van Every___Chicken-users mailing list Chicken-users@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Help debugging windows build
This email addresses a problem that is unique to a particular Windows XP installation. If you have no interest in this, then stop reading now. I normally don't submit this kind of stuff, but I am stuck and need some ideas. My hope is that someone who understands Windows compilation and shared library loading better than I do can give me an idea or two that will help me work through this. If you have any suggestions, links to articles, or whatever, you will have my undying gratitude. I recently had to switch computers and haven't gotten chicken to build properly since. Whether I use the build script or the makefile the result is the same. The build appears to complete normally, but when I run anything I end up with a windows dialog box (details at bottom) unless I have a few very odd directories in my path. My suspicion is that one of my library files (with a mingw or vc environment) is incompatible with a dll in the system32 directory on this machine. My reason for that suspicion is that I can make things run if I add certain directories to the path when running. I have had scenarios where the app would run until I eliminated a certain Java bin directory -- oracle 1.8 java if you have to know -- from the path. When I would look in the directory there would be an msvcrt.dll in there. Unfortunately, dropping the mscvrt.dll in the chicken's dir doesn't fix anything. If I run chicken.exe with PATH1 I get the error listed at the bottom even though this is how it was compiled. So my theory is that the import libraries being picked during the compilation do not match the dlls being loaded at runtime. I just don't know if there is a quick way to work through the problem. If I run it with PATH2 it runs fine. PATH1 set PATH=C:\working\cmake\chicken-2.216;C:\programs\darcs-w32;C:\Programs\CMake_2.2\bin;C:\ProgramFiles\Microsoft Visual C++ Toolkit 2003\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\WINDOWS\SYSTEM32\;C:\Program Files\Microsoft Platform SDK\Bin;C:\Program Files\Microsoft Platform SDK\Bin\WinNT;C:\Program Files\Microsoft Platform SDK\Bin\win64 PATH2 set PATH=C:\working\cmake\chicken-2.216;C:\Program Files\Microsoft Platform SDK\Bin\;C:\Program Files\Microsoft Platform SDK\Bin\WinNT\;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program Files\Microsoft Platform SDK\Bin\win64\;C:\WINDOWS\SYSTEM32\;C:\Program Files\Java\jdk1.5.0_04\bin;C:\Oracle\Ora92\bin;C:\Oracle\Ora92\jre\1.4.2\bin\client;C:\Oracle\Ora92\jre\1.4.2\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\PROGRAM FILES\THINKPAD\UTILITIES;C:\Program Files\Java\j2re1.4.2_01\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; ERROR DIALOG INFO Error signature AppName: chicken.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.2180 Offset: 0003426d Error Report ?xml version=1.0 encoding=UTF-16? DATABASE EXE NAME=chicken.exe FILTER=GRABMI_FILTER_PRIVACY MATCHING_FILE NAME=chicken.dll SIZE=1806336 CHECKSUM=0xF81C5AD3 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x0 LINK_DATE=02/03/2006 17:01:14 UPTO_LINK_DATE=02/03/2006 17:01:14 / MATCHING_FILE NAME=chicken.exe SIZE=1441792 CHECKSUM=0xA161AEF4 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x0 LINK_DATE=02/03/2006 17:01:15 UPTO_LINK_DATE=02/03/2006 17:01:15 / MATCHING_FILE NAME=test\chicken.dll SIZE=1806336 CHECKSUM=0x71B75D6 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x0 LINK_DATE=02/01/2006 22:33:12 UPTO_LINK_DATE=02/01/2006 22:33:12 / MATCHING_FILE NAME=test\foo.exe SIZE=27136 CHECKSUM=0xCDC6BC44 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x0 LINK_DATE=02/01/2006 23:30:36 UPTO_LINK_DATE=02/01/2006 23:30:36 / /EXE EXE NAME=ntdll.dll FILTER=GRABMI_FILTER_THISFILEONLY MATCHING_FILE NAME=ntdll.dll SIZE=708096 CHECKSUM=0x9D20568 BIN_FILE_VERSION=5.1.2600.2180 BIN_PRODUCT_VERSION=5.1.2600.2180 PRODUCT_VERSION=5.1.2600.2180 FILE_DESCRIPTION=NT Layer DLL COMPANY_NAME=Microsoft Corporation PRODUCT_NAME=Microsoft Windows Operating System FILE_VERSION=5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) ORIGINAL_FILENAME=ntdll.dll INTERNAL_NAME=ntdll.dll LEGAL_COPYRIGHT= Microsoft Corporation. All rights reserved. VERFILEDATEHI=0x0 VERFILEDATELO=0x0 VERFILEOS=0x40004 VERFILETYPE=0x2 MODULE_TYPE=WIN32 PE_CHECKSUM=0xAF2F7 LINKER_VERSION=0x50001 UPTO_BIN_FILE_VERSION=5.1.2600.2180 UPTO_BIN_PRODUCT_VERSION=5.1.2600.2180 LINK_DATE=08/04/2004 07:56:36 UPTO_LINK_DATE=08/04/2004 07:56:36 VER_LANGUAGE=English (United States) [0x409] / /EXE EXE NAME=kernel32.dll FILTER=GRABMI_FILTER_THISFILEONLY MATCHING_FILE NAME=kernel32.dll SIZE=983552 CHECKSUM=0x4CE79457 BIN_FILE_VERSION=5.1.2600.2180 BIN_PRODUCT_VERSION=5.1.2600.2180 PRODUCT_VERSION=5.1.2600.2180 FILE_DESCRIPTION=Windows NT BASE API Client DLL COMPANY_NAME=Microsoft Corporation PRODUCT_NAME=Microsoft Windows Operating System FILE_VERSION=5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) ORIGINAL_FILENAME=kernel32 INTERNAL_NAME=kernel32
Re: [Chicken-users] Windows build status
Have you checked to see if anything you compile runs with a normal path? Try cutting the path down to CHICKEN_HOME and the system32 directory. I'm having a lot of issues with this. On 2/3/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Brandon J. Van Every wrote: Brandon J. Van Every wrote: In a burst of energy yesterday, I got a how to build with CMake document mostly done.But it is not quite finished, because I used the MinGW 5.0.0 downloader / installer for my MinGW installation, and using that, chicken.exe turns into complete buggy crap.I think MinGW 5.0.0 is a bad compiler setup. I didn't have any better luck with the GCC 3.4.5 [Candidate] versions.Oddly, there are no compilers listed as [Current] versions on mingw.org. Meanwhile, I can't seem to access sourceforge.net right now to look for older versions.Maybe it's Sprint's fault, my internet connection seems to be awfully unreliable late at night.Or maybe everyone else thinks that 4 am is the time to do disruptive maintenance rather than get real work done. I'm going to try with an older archive of GCC 3.4.4 I have lying around. I finally solved the mystery.The Microsoft Platform SDK has to beinstalled, and its paths, include, and lib variables have to be set inthe Windows environment.I'm not sure why this is necessary.I amwondering if it's a Chicken issue, a CMake issue, or a MinGW issue. Someone seems to need a tool or lib that the PSDK provides.Anyone gotany ideas?Anyways, the MinGW 5.0.0 downloader / installer works just fine, so I'llchange my build instructions accordingly.It's the most convenient way to install MinGW.Cheers,Brandon Van Every___Chicken-users mailing listChicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
Certainly.On 10/24/05, felix winkelmann [EMAIL PROTECTED] wrote: On 10/23/05, Patrick Brannan [EMAIL PROTECTED] wrote:I was negligent in the documentation I sent with the cmake files. I left out the fact that I always created a command prompt by running a batch file to set up my build environment. The batch file is set up exactly in accordance with the instructions in vctk-install.txt. Here it is:start console.bat===setlocal set LIB=C:\Program Files\Microsoft Platform SDK\Lib;C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib\set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;C:\Program Files\Microsoft Visual C++ Toolkit 2003\includeset PATH=C:\Program Files\Microsoft Platform SDK\Bin;C:\Program Files\Microsoft Platform SDK\Bin\WinNT;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;C:\WINDOWS\Microsoft .NET\Framework\v1.1.4322;C:\Program Files\Microsoft Platform SDK\Bin\win64;C:\WINDOWS\SYSTEM32\set CHICKEN_HOME=C:\working\scheme\chicken-2.2 set CHICKEN_REPOSITORY=C:\working\scheme\repositoryset PATH=%CHICKEN_HOME%;%PATH%cmdend console.batThanks, may I include this as an example in the README? cheers,felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
Sorry for the double email, Brandon. I sent the first copy of this to you instead of the group. Anyway, here is the email again, sent to the group this time. I did develop this with the Microsoft free tools. In fact I did it on two machines, one of which never had Visual C++ installed. I was negligent in the documentation I sent with the cmake files. I left out the fact that I always created a command prompt by running a batch file to set up my build environment. The batch file is set up exactly in accordance with the instructions in vctk-install.txt. Here it is: start console.bat=== setlocal set LIB=C:\Program Files\Microsoft Platform SDK\Lib;C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib\ set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;C:\Program Files\Microsoft Visual C++ Toolkit 2003\include set PATH=C:\Program Files\Microsoft Platform SDK\Bin;C:\Program Files\Microsoft Platform SDK\Bin\WinNT;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;C:\WINDOWS\Microsoft .NET\Framework\v1.1.4322;C:\Program Files\Microsoft Platform SDK\Bin\win64;C:\WINDOWS\SYSTEM32\ set CHICKEN_HOME=C:\working\scheme\chicken-2.2 set CHICKEN_REPOSITORY=C:\working\scheme\repository set PATH=%CHICKEN_HOME%;%PATH% cmd end console.bat If you have the free c++ environment set up as described in vctk-install.txt then you should be able to run CMake after generating a command prompt with the batch file above. Of course if you don't have things where they are expected things will probably not work too well. My biggest disappointment in using CMake is that I could not find a way to build two targets with the same source files using different defines without resorting to including a generated config file. So to build static and dynamic versions of chicken you would have to run CMake twice. Maybe someone smarter than me can solve this problem. I posted a message to the CMake list and received no response. Probably because to them it is a dumb question. I'm certainly no heavyweight c/c++ developer. Patrick On 10/22/05, Brandon J. Van Every [EMAIL PROTECTED] wrote: Graham Fawcett wrote:Running `cmake -G NMake Makefiles` didn't Just Work. I usedcmakesetup.exe, which is a GUI for writing a configuration cache.Before running this, I had to add the MSVC toolchain to my PATH. I don't normally have them on PATH; and without them, cmakesetupwouldn't work properly. IOW, you cannot just run cmakesetup from theStart..Programs menu unless you have your tools on the PATH. Note that `cmake -G NMake Makefiles` did not work even when my tools were onthe path.I used the Chicken 2.2 tarball as a guinea pig, just addingCMakeLists.txt to it and no other actions.When I use my fully licensed retail version of VC++ 7.1, 'cmake -G NMake Makefiles' generates itsoutput without a hitch.When I use the free VC++ Toolkit, I get a bunchof errors.So, the problem is surely that the retail compiler has all sorts of tools and paths configured properly, and the free versiondoesn't.Probably there is more work to get a valid build environmentgoing with the free version.I did run the appropriate vcvars32.batwith the free version, but that isn't enough to solve the problem.I bet I don't have the Platform SDK set up properly to work with the freeversion; for instance, I don't see any includes or paths for it in theenvioronment.Also beware of the 'csi' shadowing gotcha, as the Platform SDK has its own csi.exe apparently.After that, cmakesetup ran fine. I had to specifyEXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH; I also built thebinaries in the source directory. Trying to specify a different output directory seemed to cause problems; it looked like the cache waswritten to the build directory rather than the source directory when Itried this.I haven't tried this yet.I haven't gone up the learning curve of cmake's theory of operation.Sorry I'm just way too tired from thephysically demanding work of signature gathering.Yes I am lame.I'monly good at getting people interested in better build systems.:-) I'll make more stabs as time and energy allow.Cheers,Brandon J. Van Every(cruise (director (of SeaFunc)'(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc___Chicken-users mailing listChicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Maybe it's not so bad. I got it completing an entire build using the
shared library on Windows. Now that I have dug into it a bit more, I
think that the tool has merit, but is not documented well. I can list
the following positive points:
1. You really can build something easily with CMake. The configuration language can be terse when compared to make.
2. The install for Windows worked as advertised. They even release binaries.
5. Creates build files for all sorts of systems.
6. You do not have to re-run cmake for minor cmake updates. Make or nmake will call cmake and update as needed.
7. The user base seems active based on their list traffic.
On the negative side:
1. Documentation is weak.
2. Setting properties on files and targets did not always do what I expected.
3. MinGw is not officially supported though apparently it works.
4. The CMake approach takes a little getting used to. I was expecting
something like Maven or Ant for C but it is not like that at all. The
CMake language is a mix of imperative and declarative.
As far as my previous complaints go, I hadn't researched enough for a
couple of them. You can set the OUTPUT_FILE name for an executable
target. This doesn't seem to work for library targets. You could work
around this by configuring the build for shared or static.
CMake has a nice facility for configuration files that I have not used.
It might make all the defines in my CMakeLists file go away.
Anyway, I have attached my CMakeLists.txt file for you to look at.
Several parts could be optimized with some thought. For one thing,
building all of the scm files at the end (csi, chicken-setup, etc)
could be handled in a FOREACH loop. For another, we might use
configurable files as includes to handle the defines.
To make the test work with chicken 2.2 first fix the winsock.h include
bug in tcp, posix, and scheduler. Then run the following commands. (I
assume you have the free MS tools installed as described in
vctk-install.txt.
cmake -G NMake MakeFiles .
nmake
My CMakeCache is also attached. It is generated the first time you run
CMake. You can set up compiler and linker flags in this file.
You could easily set up the cmake to prompt for install directories
etc. It's not perfect, but I think it is workable and that it might
actually save some time.On 10/3/05, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote:
BTW I still can't see my own posts, which is a bit annoying.I only see this behavior on this list.I *think* that's likely caused by a Mailman configuration setting.Atleast, if memory serves me right, it does have one such setting.
I find that annoying as well. :/Alejo.http://azul.freaks-unidos.net/---=(Comunidad de Usuarios de Software Libre en Colombia)=--=(
http://bachue.com/colibri )=--=( [EMAIL PROTECTED])=---___Chicken-users mailing list
Chicken-users@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/chicken-users
PROJECT (Chicken)
SET(STD_C_FLAGS -DC_DEFAULT_TARGET_STACK_SIZE=30 -DC_NO_PIC_NO_DLL
-DHAVE_LOADLIBRARY -DHAVE_GETPROCADDRESS -DHAVE_WINDOWS_H)
SET(SHARED_LIB_FLAGS -DC_BUILDING_LIBCHICKEN -DPIC ${STD_C_FLAGS})
SET(STATIC_LIB_FLAGS -DC_BUILDING_LIBCHICKEN -DPIC ${STD_C_FLAGS})
SET(SHARED_EXE_FLAGS -DPIC ${STD_C_FLAGS})
SET (CHICKEN_LIB_SOURCES
runtime.c library.c
eval.c profiler.c
scheduler.c extras.c
match-support.c lolevel.c
stub.c tinyclos.c
pregexp.c utils.c
tcp.c posixwin.c
srfi-1.csrfi-4.c
srfi-13.c srfi-14.c
srfi-18.c)
SET_SOURCE_FILES_PROPERTIES(${CHICKEN_LIB_SOURCES} PROPERTIES
COMPILE_FLAGS ${SHARED_LIB_FLAGS})
ADD_LIBRARY(chicken_lib SHARED ${CHICKEN_LIB_SOURCES})
TARGET_LINK_LIBRARIES(chicken_lib ws2_32)
SET_TARGET_PROPERTIES(chicken_lib PROPERTIES
LINK_FLAGS /nologo /implib:libchicken.lib /dll)
SET (CHICKEN_EXE_SOURCES
chicken.c support.c
partition.c easyffi.c
compiler.c optimizer.c
batch-driver.c c-platform.c
c-backend.c chicken.rc)
SET_SOURCE_FILES_PROPERTIES(${CHICKEN_EXE_SOURCES} PROPERTIES
COMPILE_FLAGS ${SHARED_EXE_FLAGS})
ADD_EXECUTABLE(chicken_exe ${CHICKEN_EXE_SOURCES})
TARGET_LINK_LIBRARIES(chicken_exe chicken_lib)
SET_TARGET_PROPERTIES(chicken_exe PROPERTIES OUTPUT_NAME chicken)
ADD_CUSTOM_COMMAND(OUTPUT csi.c
COMMAND chicken.exe
ARGS csi.scm -optimize-level 2 -debug-level 0 -quiet
-output-file csi.c -prologue build.scm
DEPENDS chicken.exe)
SET_SOURCE_FILES_PROPERTIES(csi.c PROPERTIES
GENERATED true
COMPILE_FLAGS ${SHARED_EXE_FLAGS})
ADD_EXECUTABLE(csi csi.c)
TARGET_LINK_LIBRARIES(csi chicken_lib)
ADD_CUSTOM_COMMAND(OUTPUT csc.c
COMMAND chicken.exe
ARGS csc.scm.in -optimize-level 2 -debug-level 0 -quiet
-output-file csc.c
DEPENDS chicken.exe)
