RE: Make Problem
On 16 March 2006 09:28, Deepa Mahajan wrote: > When I try to execute the make command. I get the following errors > > $ make > make[1]: Entering directory `/home/Deepa/ > gcc -o ../bin/m1210.exe m1210.o Deepa.a -lm -lc -lz -ltcl -ltk > fu01.o:: undefined reference to `_libc_iname' > fu02.o:: undefined reference to `_libc_iname' > fu03.o:: undefined reference to `_libc_iname' > fu04.o:: undefined reference to `_libc_iname' > fu05.o:: undefined reference to `_libc_iname' > fu06.o:: more undefined references to `_libc_iname' follow > Info: resolving __impure_ptr by linking to __imp___impure_ptr (auto-import) > collect2: ld returned 1 exit status > make[1]: *** [../bin/m1210.exe] Error 1 > make[1]: Leaving directory `/home/Deepa/' > make: *** [all] Error 2 > > ANyone know how i can resolve them? > > Deepa My guess is that Deepa.a contains linux .obj files? Cygwin is only source-compatible, not binary, you need to recompile whatever sources that archive was generated from. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make Problem!!!!
This is an inidcation that c++.exe is not in the list of paths of your PATH environment variable. "JOSE (GRI)" wrote: > > Hi: > > I have got an environment problem with make: > > D: \make -f mcyg32 > > c++.exe -c /comun/src/cacheb.cpp -o /client/mcc_cyg/debg/cacheb.obj > -DLIBRERIA - > DDOS_SOURCE -DPRCIO -DVTREE=86 -DCOMPILADOR -DINTERPRETE -DCOM -D__386__ > -D__NT_ > _ -I/client/src -I/comun/src -I/cygwin/usr/include/mingw > -I/cygwin/usr/include/m > ingw/sys -I/cygwin/usr/include/w32api -I/JDK1.3.1/INCLUDE > -I/JDK1.3.1/INCLUDE/WI > N32 -Wall -mno-cygwin > make: c++.exe: Command not found > make: *** [/client/mcc_cyg/debg/cacheb.obj] Error 127 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make problem since 1.5.7
At 12:38 PM 3/26/2004, you wrote: >Hello, > >With all cygwin-versions starting with 1.5.7 (including the snapshot >20040322) I experience major problems with make, leading to a major (> >20x) increase in the time make needs for a specific single target in our >project make system (which is quite complex, includes >100 sub-makefiles >and is not written in-house). > >According to the task-manager the system happily divides all cpu-time >between two make-tasks and csrss.exe. > >I tried looking at "make -d" and strace output, but cannot make very >much sense of the output. > >One thing that does stick out in the "bad" case is an exceptionally >large number of "Got a SIGCHLD; 2 unreaped children" "Got a SIGCHLD; 1 >unreaped children" messages in the "make -d" output after the point >where make checks that it has to remake a specific file and before the >actual rebuilding (in this case, an "ar" call). > >The "make -d" output for the "good" case also contains some of those >messages, but far fewer. > >I can provide the strace and "make -d" output for both cases, if that >would help, but these files are VERY large. > >Thanks for any help or hints what to check, >Ingmar Sittl > >-- >--- >Ingmar Sittl, Dipl.-Inf., mobile applications >3SOFT GmbH, Frauenweiherstrasse 14, 91058 Erlangen, Germany >Tel: +49-9131-7701-276 mailto:[EMAIL PROTECTED] >Fax: +49-9131-7701-333 http://www.3SOFT.de > >Cygwin Win95/NT Configuration Diagnostics >Current System Time: Fri Mar 26 12:10:59 2004 > >Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 > >Path: C:\cygwin\bin >C:\cygwin\bin >C:\cygwin\usr\local\bin >C:\cygwin\usr\X11R6\bin >c:\j2sdk1.4.2\bin\ >c:\emacs-21.2\bin\ >c:\jikes-1.15\bin >c:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\ >c:\tmp\tornado2_1\host\i686-pc-cygwin\bin\ >c:\TornadoSH\host\x86-win32\bin ^^ Please pull these last 2 directories out of your path and try again. This eliminates the possibility of a tool conflict/interaction. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make problem since 1.5.7
Larry Hall wrote: > At 12:38 PM 3/26/2004, you wrote: > >>Hello, >> >>With all cygwin-versions starting with 1.5.7 (including the snapshot >>20040322) I experience major problems with make, leading to a major (> >>20x) increase in the time make needs for a specific single target in our >>project make system (which is quite complex, includes >100 sub-makefiles >>and is not written in-house). >> >>According to the task-manager the system happily divides all cpu-time >>between two make-tasks and csrss.exe. >> >>I tried looking at "make -d" and strace output, but cannot make very >>much sense of the output. >> >>One thing that does stick out in the "bad" case is an exceptionally >>large number of "Got a SIGCHLD; 2 unreaped children" "Got a SIGCHLD; 1 >>unreaped children" messages in the "make -d" output after the point >>where make checks that it has to remake a specific file and before the >>actual rebuilding (in this case, an "ar" call). >> >>The "make -d" output for the "good" case also contains some of those >>messages, but far fewer. >> >>I can provide the strace and "make -d" output for both cases, if that >>would help, but these files are VERY large. >> >>Thanks for any help or hints what to check, >>Ingmar Sittl >> >>-- >>--- >>Ingmar Sittl, Dipl.-Inf., mobile applications >>3SOFT GmbH, Frauenweiherstrasse 14, 91058 Erlangen, Germany >>Tel: +49-9131-7701-276 mailto:[EMAIL PROTECTED] >>Fax: +49-9131-7701-333 http://www.3SOFT.de >> >>Cygwin Win95/NT Configuration Diagnostics >>Current System Time: Fri Mar 26 12:10:59 2004 >> >>Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 >> >>Path: C:\cygwin\bin >> C:\cygwin\bin >> C:\cygwin\usr\local\bin >> C:\cygwin\usr\X11R6\bin >> c:\j2sdk1.4.2\bin\ >> c:\emacs-21.2\bin\ >> c:\jikes-1.15\bin >> c:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\ >> c:\tmp\tornado2_1\host\i686-pc-cygwin\bin\ >> c:\TornadoSH\host\x86-win32\bin > > >^^ > > Please pull these last 2 directories out of your path and try again. This > eliminates the possibility of a tool conflict/interaction. > > > -- > Larry Hall http://www.rfk.com > RFK Partners, Inc. (508) 893-9779 - RFK Office > 838 Washington Street (508) 893-9889 - FAX > Holliston, MA 01746 > > Hi, Changed PATH to /usr/local/bin:/usr/bin/:/bin, but still no change. Btw, relevant (I think) output from make -d (real path replaced with "some_path" for better readability) Must remake target `some_path/GUI_Module.lib_ar'. Got a SIGCHLD; 1 unreaped children. Got a SIGCHLD; 1 unreaped children. Got a SIGCHLD; 2 unreaped children. Got a SIGCHLD; 1 unreaped children. Got a SIGCHLD; 1 unreaped children. Got a SIGCHLD; 2 unreaped children. Got a SIGCHLD; 2 unreaped children. Got a SIGCHLD; 2 unreaped children. ... (in the good case, about one minute and ca. 200 times SIGCHLD messages, in the bad case at least 10 minutes and 2000 times this message) Got a SIGCHLD; 2 unreaped children. Got a SIGCHLD; 2 unreaped children. Putting child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1920 on the chain. Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1920 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 1920 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 816 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 816 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 320 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 320 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1924 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 1924 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1944 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 1944 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1700 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 1700 Live child 0x108b3a20 (some_path/GUI_Module.lib_ar) PID 1288 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x108b3a20 PID 1288 Removing child 0x108b3a20 PID 1288 from chain. Successfully remade target file `some_path/GUI_Module.lib_ar'. Finished prerequisites of target file `some_path/GUI_Module.lib'. Must remake target `some_path/GUI_Module.lib'. /cygdrive/c/tmp/tornado2_1/host/i686-pc-cygwin/bin/arsh -M < some_path/GUI_Module.lib_ar Putting child 0x106e3d68 (some_path/GUI_Module.lib) PID 816 on the chain. Live child 0x106e3d68 (some_path/GUI_Module.lib) PID 816 Got a SIGCHLD; 1 unreaped children. Reaping winning child 0x106e3d68 PID 816 Removing child 0x106e3d68 PID 816 from chain. Successfully remade target file `some_path/GUI_Module.lib'. -- --- Ingmar Sittl, Dipl.-Inf., mobile applications 3SOFT GmbH, Frauenweiherstrasse 14, 910
Re: Make problem since 1.5.7
At 03:39 AM 3/29/2004, Ingmar Sittl wrote: >Larry Hall wrote: >> At 12:38 PM 3/26/2004, Ingmar Sittl wrote: >> >>>Hello, >>> >>>With all cygwin-versions starting with 1.5.7 (including the snapshot >>>20040322) I experience major problems with make, leading to a major (> >>>20x) increase in the time make needs for a specific single target in our >>>project make system (which is quite complex, includes >100 sub-makefiles >>>and is not written in-house). >>> >>>According to the task-manager the system happily divides all cpu-time >>>between two make-tasks and csrss.exe. >>> >>>I tried looking at "make -d" and strace output, but cannot make very >>>much sense of the output. >>> >>>One thing that does stick out in the "bad" case is an exceptionally >>>large number of "Got a SIGCHLD; 2 unreaped children" "Got a SIGCHLD; 1 >>>unreaped children" messages in the "make -d" output after the point >>>where make checks that it has to remake a specific file and before the >>>actual rebuilding (in this case, an "ar" call). >>> >>>The "make -d" output for the "good" case also contains some of those >>>messages, but far fewer. >>> >>>I can provide the strace and "make -d" output for both cases, if that >>>would help, but these files are VERY large. >>> >>>Thanks for any help or hints what to check, >>>Ingmar Sittl >>> >>>-- >>>--- >>>Ingmar Sittl, Dipl.-Inf., mobile applications >>>3SOFT GmbH, Frauenweiherstrasse 14, 91058 Erlangen, Germany >>>Tel: +49-9131-7701-276 mailto:[EMAIL PROTECTED] >>>Fax: +49-9131-7701-333 http://www.3SOFT.de >>> >>>Cygwin Win95/NT Configuration Diagnostics >>>Current System Time: Fri Mar 26 12:10:59 2004 >>> >>>Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 >>> >>>Path: C:\cygwin\bin >>> C:\cygwin\bin >>> C:\cygwin\usr\local\bin >>> C:\cygwin\usr\X11R6\bin >>> c:\j2sdk1.4.2\bin\ >>> c:\emacs-21.2\bin\ >>> c:\jikes-1.15\bin >>> c:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\ >>> c:\tmp\tornado2_1\host\i686-pc-cygwin\bin\ >>> c:\TornadoSH\host\x86-win32\bin >> >> >>^^ >> >> Please pull these last 2 directories out of your path and try again. This >> eliminates the possibility of a tool conflict/interaction. >> >> >> -- >> Larry Hall http://www.rfk.com >> RFK Partners, Inc. (508) 893-9779 - RFK Office >> 838 Washington Street (508) 893-9889 - FAX >> Holliston, MA 01746 >> >> >Hi, > >Changed PATH to /usr/local/bin:/usr/bin/:/bin, but still no change. Well, something is still getting you to the wrong place. See below. >Got a SIGCHLD; 1 unreaped children. >Reaping winning child 0x108b3a20 PID 1288 >Removing child 0x108b3a20 PID 1288 from chain. > Successfully remade target file `some_path/GUI_Module.lib_ar'. > Finished prerequisites of target file `some_path/GUI_Module.lib'. >Must remake target `some_path/GUI_Module.lib'. >/cygdrive/c/tmp/tornado2_1/host/i686-pc-cygwin/bin/arsh -M < ^^ Yikes! You're still mixing tool-sets. That ain't gonna work! -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make problem since 1.5.7
Larry Hall wrote: > At 03:39 AM 3/29/2004, Ingmar Sittl wrote: > >>Larry Hall wrote: >> >>>At 12:38 PM 3/26/2004, Ingmar Sittl wrote: >>> >>> Hello, With all cygwin-versions starting with 1.5.7 (including the snapshot 20040322) I experience major problems with make, leading to a major (> 20x) increase in the time make needs for a specific single target in our project make system (which is quite complex, includes >100 sub-makefiles and is not written in-house). According to the task-manager the system happily divides all cpu-time between two make-tasks and csrss.exe. I tried looking at "make -d" and strace output, but cannot make very much sense of the output. One thing that does stick out in the "bad" case is an exceptionally large number of "Got a SIGCHLD; 2 unreaped children" "Got a SIGCHLD; 1 unreaped children" messages in the "make -d" output after the point where make checks that it has to remake a specific file and before the actual rebuilding (in this case, an "ar" call). The "make -d" output for the "good" case also contains some of those messages, but far fewer. I can provide the strace and "make -d" output for both cases, if that would help, but these files are VERY large. Thanks for any help or hints what to check, Ingmar Sittl -- --- Ingmar Sittl, Dipl.-Inf., mobile applications 3SOFT GmbH, Frauenweiherstrasse 14, 91058 Erlangen, Germany Tel: +49-9131-7701-276 mailto:[EMAIL PROTECTED] Fax: +49-9131-7701-333 http://www.3SOFT.de Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Mar 26 12:10:59 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\local\bin C:\cygwin\usr\X11R6\bin c:\j2sdk1.4.2\bin\ c:\emacs-21.2\bin\ c:\jikes-1.15\bin c:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\ c:\tmp\tornado2_1\host\i686-pc-cygwin\bin\ c:\TornadoSH\host\x86-win32\bin >>> >>> >>> ^^ >>> >>>Please pull these last 2 directories out of your path and try again. This >>>eliminates the possibility of a tool conflict/interaction. >>> >>> >>>-- >>>Larry Hall http://www.rfk.com >>>RFK Partners, Inc. (508) 893-9779 - RFK Office >>>838 Washington Street (508) 893-9889 - FAX >>>Holliston, MA 01746 >>> >>> >> >>Hi, >> >>Changed PATH to /usr/local/bin:/usr/bin/:/bin, but still no change. > > > > Well, something is still getting you to the wrong place. See below. > > > > > > >>Got a SIGCHLD; 1 unreaped children. >>Reaping winning child 0x108b3a20 PID 1288 >>Removing child 0x108b3a20 PID 1288 from chain. >> Successfully remade target file `some_path/GUI_Module.lib_ar'. >>Finished prerequisites of target file `some_path/GUI_Module.lib'. >>Must remake target `some_path/GUI_Module.lib'. >>/cygdrive/c/tmp/tornado2_1/host/i686-pc-cygwin/bin/arsh -M < > > > ^^ > > Yikes! You're still mixing tool-sets. That ain't gonna work! > > > -- > Larry Hall http://www.rfk.com > RFK Partners, Inc. (508) 893-9779 - RFK Office > 838 Washington Street (508) 893-9889 - FAX > Holliston, MA 01746 > > The referenced arsh binary was compiled locally for the currently installed cygwin (cygwin version at compile time was 1.5.6) from the windriver-provided sources to work around some problems with the original tornado-binaries. The path to AR is set inside the Makefile like this AR=/path/to/arsh Calling this specific arsh from the bash does work, whatever the cygwin version, so I see no problem with calling it from within make, or am I completely wrong here ?? Ingmar -- --- Ingmar Sittl, Dipl.-Inf., mobile applications 3SOFT GmbH, Frauenweiherstrasse 14, 91058 Erlangen, Germany Tel: +49-9131-7701-276 mailto: Ingmar dot Sittl at 3SOFT.de Fax: +49-9131-7701-333 http://www.3SOFT.de -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make problem since 1.5.7
At 10:19 AM 3/29/2004, you wrote: >Larry Hall wrote: >> >>>Got a SIGCHLD; 1 unreaped children. >>>Reaping winning child 0x108b3a20 PID 1288 >>>Removing child 0x108b3a20 PID 1288 from chain. >>> Successfully remade target file `some_path/GUI_Module.lib_ar'. >>>Finished prerequisites of target file `some_path/GUI_Module.lib'. >>>Must remake target `some_path/GUI_Module.lib'. >>>/cygdrive/c/tmp/tornado2_1/host/i686-pc-cygwin/bin/arsh -M < >> >> >> ^^ >> >> Yikes! You're still mixing tool-sets. That ain't gonna work! >> >> >> -- >> Larry Hall http://www.rfk.com >> RFK Partners, Inc. (508) 893-9779 - RFK Office >> 838 Washington Street (508) 893-9889 - FAX >> Holliston, MA 01746 >> >> > >The referenced arsh binary was compiled locally for the currently >installed cygwin (cygwin version at compile time was 1.5.6) from the >windriver-provided sources to work around some problems with the >original tornado-binaries. > >The path to AR is set inside the Makefile like this >AR=/path/to/arsh > >Calling this specific arsh from the bash does work, whatever the cygwin >version, so I see no problem with calling it from within make, or am I >completely wrong here ?? That sounds OK. Assuming that this is the only binary pulled in from the tornado distribution, it's not obvious that this would cause a problem. I'm out of ideas at the moment, beyond the obvious debugging. -- Larry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make-Problem Postgres on Cygwin
Manuel, Please post instead of sending private email. However, your timing is impeccable. I just got around (yesterday) to building PostgreSQL under the latest Cygwin gcc2 and gcc packages. On Fri, Nov 22, 2002 at 01:23:48PM +0100, Tarabas wrote: > I read your thread abut problems installing Postgresql on Cygwin as > source-distribution. I got exactly the same problems with that! > > Before you ask: > I HAVE TO use the source-build because I need to patch the maximum arguments > for a function on postgresql for my application, so installing binary is not > an option! > > I first got the Problem that the IPC-lib was not found in the configure > which was solved by configuring with > > $ LDFLAGS=-L/usr/local/lib ./configure > instead of the simple "./configure" ... > > Also the IPC-Daemon is installed an running! (ps -aef|grep ipc show's it!) > > Now i get an error when calling the make: > > <-snip-> > make[4]: Entering directory '/postgresql-7.2.3/src/backend/storage/ipc' > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include >-I/usr/local/include -DBUILDING_DLL=1 -c -o -ipc.o ipc.c > cc1: warning: changing search order for system directory "/usr/local/include" > cc1: warning: as it has already been specified as a non-system-directory The "-I/usr/local/include" is causing configure to get confused and mis-configure PostgreSQL which causes the following (and other) problems: > ipc.c: In function 'InternalIpcSemaphoreCreate': > ipc.c:271: warning: implicit declaration of function `semget' > ipc.c:271: `IPC_CREAT' undeclared (first use in this function) > ipc.c:271: (Each undeclared identifier is reported only once > ipc.c:271: for each function it appears in.) > <-snip-> > > any ideas how to fix that ?! Yes. To build PostgreSQL 7.2.3 under gcc2, use the following procedure: 1. apply attached postgresql-7.2.3-gcc2.patch $ patch -p1 http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 diff -rup postgresql-7.2.3.orig/src/makefiles/Makefile.win postgresql-7.2.3-gcc2/src/makefiles/Makefile.win --- postgresql-7.2.3.orig/src/makefiles/Makefile.win2001-09-05 22:58:33.0 -0400 +++ postgresql-7.2.3-gcc2/src/makefiles/Makefile.win2002-11-21 12:43:07.0 +-0500 @@ -2,7 +2,7 @@ LDFLAGS+= -g DLLTOOL= dlltool DLLWRAP= dllwrap -DLLLIBS= -lcygipc -lcrypt +DLLLIBS= -L/usr/local/lib -lcygipc -lcrypt BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres MK_NO_LORDER=true MAKE_DLL=true diff -rup postgresql-7.2.3.orig/src/makefiles/Makefile.win postgresql-7.2.3-gcc3/src/makefiles/Makefile.win --- postgresql-7.2.3.orig/src/makefiles/Makefile.win2001-09-05 22:58:33.0 -0400 +++ postgresql-7.2.3-gcc3/src/makefiles/Makefile.win2002-11-21 10:52:41.0 +-0500 @@ -2,7 +2,7 @@ LDFLAGS+= -g DLLTOOL= dlltool DLLWRAP= dllwrap -DLLLIBS= -lcygipc -lcrypt +DLLLIBS= -L/usr/local/lib -lcygipc -lcrypt BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres MK_NO_LORDER=true MAKE_DLL=true diff -rup postgresql-7.2.3.orig/src/template/win postgresql-7.2.3-gcc3/src/template/win --- postgresql-7.2.3.orig/src/template/win 2000-10-21 18:36:14.0 -0400 +++ postgresql-7.2.3-gcc3/src/template/win 2002-11-21 10:31:22.0 -0500 @@ -1,4 +1,3 @@ CFLAGS=-O2 -SRCH_INC=/usr/local/include SRCH_LIB=/usr/local/lib LIBS=-lcygipc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make-Problem Postgres on Cygwin
Manuel, Sigh... Repeat after me: Post instead of sending private email. Keep replies on-list. Post instead of sending private email. Keep replies on-list. ... On Fri, Nov 22, 2002 at 06:48:39PM +0100, Tarabas wrote: > Thanks a lot for your help! The "make" and "make install" worked fine > after the patch BUT I sadly have to bother you again. > > After I did the ./initdb /usr/local/pgsql/data > and the ./postmaster -D /usr/local/pgsql/data -i & > > and then tried to do ANYTHING on the DB (either connecting via pgAdmin > oder createdb or createuser), I get the Message: > > "FATAL 1: IndexSupportInitialize: bogus pg_index tuple" > > Any suggestions ?! No. I just ran a gcc3 postmaster (i.e., postgres.exe) against a previously initialized database without any problems. From posts to pgsql-cygwin@, I'm under the impression that others have successfully built, initialized (i.e., ran initdb), and ran postmaster with my supplied patches. > I used the gcc3-patch to compile postgres. Initdb ran fine without any > errors and the postmaster started fine too. Could this still be > related to that patch ?! I don't think so. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Make-Problem Postgres on Cygwin
Hi The problem persists and I get the following error using make...even after applying the patch. Help me see where I am missing it. Awaiting your input. Thanks. Godson R. ==[begin quote]=== make[3]: `SUBSYS.o' is up to date. make[3]: Leaving directory `/cygdrive/e/postgresql-7.2.1/src/backend/storage/fre espace' make -C ipc SUBSYS.o make[3]: Entering directory `/cygdrive/e/postgresql-7.2.1/src/backend/storage/ip c' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/ incl ude -I/usr/local/include -DBUILDING_DLL=1 -c -o ipc.o ipc.c cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory ipc.c: In function `InternalIpcSemaphoreCreate': ipc.c:271: warning: implicit declaration of function `semget' ipc.c:271: `IPC_CREAT' undeclared (first use in this function) ipc.c:271: (Each undeclared identifier is reported only once ipc.c:271: for each function it appears in.) ipc.c:271: `IPC_EXCL' undeclared (first use in this function) ipc.c:318: warning: implicit declaration of function `semctl' ipc.c:318: `SETALL' undeclared (first use in this function) ipc.c: In function `IpcSemaphoreKill': ipc.c:351: `IPC_RMID' undeclared (first use in this function) ipc.c: In function `IpcSemaphoreLock': ipc.c:378: storage size of `sops' isn't known ipc.c:422: warning: implicit declaration of function `semop' ipc.c:378: warning: unused variable `sops' ipc.c: In function `IpcSemaphoreUnlock': ipc.c:441: storage size of `sops' isn't known ipc.c:441: warning: unused variable `sops' ipc.c: In function `IpcSemaphoreTryLock': ipc.c:475: storage size of `sops' isn't known ipc.c:478: `IPC_NOWAIT' undeclared (first use in this function) ipc.c:475: warning: unused variable `sops' ipc.c: In function `IpcSemaphoreGetValue': ipc.c:519: `GETVAL' undeclared (first use in this function) ipc.c: In function `IpcSemaphoreGetLastPID': ipc.c:530: `GETPID' undeclared (first use in this function) ipc.c: In function `InternalIpcMemoryCreate': ipc.c:561: warning: implicit declaration of function `shmget' ipc.c:561: `IPC_CREAT' undeclared (first use in this function) ipc.c:561: `IPC_EXCL' undeclared (first use in this function) ipc.c:638: warning: implicit declaration of function `shmat' ipc.c:638: warning: assignment makes pointer from integer without a cast ipc.c: In function `IpcMemoryDetach': ipc.c:664: warning: implicit declaration of function `shmdt' ipc.c: In function `IpcMemoryDelete': ipc.c:681: warning: implicit declaration of function `shmctl' ipc.c:681: `IPC_RMID' undeclared (first use in this function) ipc.c: In function `SharedMemoryIsInUse': ipc.c:697: storage size of `shmStat' isn't known ipc.c:707: `IPC_STAT' undeclared (first use in this function) ipc.c:697: warning: unused variable `shmStat' ipc.c: In function `IpcMemoryCreate': ipc.c:818: warning: assignment makes pointer from integer without a cast ipc.c:850: `IPC_RMID' undeclared (first use in this function) ipc.c: In function `IpcSemaphoreCreate': ipc.c:940: `IPC_RMID' undeclared (first use in this function) ipc.c:966: `SETVAL' undeclared (first use in this function) make[3]: *** [ipc.o] Error 1 make[3]: Leaving directory `/cygdrive/e/postgresql-7.2.1/src/backend/storage/ipc ' make[2]: *** [ipc-recursive] Error 2 make[2]: Leaving directory `/cygdrive/e/postgresql-7.2.1/src/backend/storage' make[1]: *** [storage-recursive] Error 2 make[1]: Leaving directory `/cygdrive/e/postgresql-7.2.1/src/backend' make: *** [all] Error 2 Administrator@WEBLOGIC /cygdrive/e/postgresql-7.2.1/src $ [end quote]== -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Tishler Sent: Friday, November 22, 2002 7:51 PM To: Tarabas Cc: Cygwin; Pgsql-Cygwin Subject: Re: Make-Problem Postgres on Cygwin Manuel, Please post instead of sending private email. However, your timing is impeccable. I just got around (yesterday) to building PostgreSQL under the latest Cygwin gcc2 and gcc packages. On Fri, Nov 22, 2002 at 01:23:48PM +0100, Tarabas wrote: > I read your thread abut problems installing Postgresql on Cygwin as > source-distribution. I got exactly the same problems with that! > > Before you ask: > I HAVE TO use the source-build because I need to patch the maximum arguments > for a function on postgresql for my application, so installing binary is not > an option! > > I first got the Problem that the IPC-lib was not found in the configure > which was solved by configuring with > > $
Re: Make-Problem Postgres on Cygwin
Godson, On Tue, Nov 26, 2002 at 02:10:45PM +0530, Godson Retna wrote: > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include >-I/usr/local/include -DBUILDING_DLL=1 -c -o ipc.o ipc.c > cc1: warning: changing search order for system directory "/usr/local/include" > cc1: warning: as it has already been specified as a non-system directory The above implies that you either did not successfully apply my patch or you forgot to reconfigure after doing so. My WAG is the latter. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Make-Problem Postgres on Cygwin
Jason Thanks for all your valuable input. The installation has been completed successfully. I downloaded PostgreSQL 7.2.3. and followed your posts on this line. Best Regards. Godson R. -Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 6:26 PM To: Godson Retna Cc: Cygwin; Pgsql-Cygwin Subject: Re: Make-Problem Postgres on Cygwin Godson, On Tue, Nov 26, 2002 at 02:10:45PM +0530, Godson Retna wrote: > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/ include -I/usr/local/include -DBUILDING_DLL=1 -c -o ipc.o ipc.c > cc1: warning: changing search order for system directory "/usr/local/include" > cc1: warning: as it has already been specified as a non-system directory The above implies that you either did not successfully apply my patch or you forgot to reconfigure after doing so. My WAG is the latter. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MAKE - problem with small/capital letters in filenames
> -Original Message- > From: Graff_Zoltan [mailto:zotyo@;z1.fszek.hu] > Sent: Tuesday, October 29, 2002 6:05 AM > To: [EMAIL PROTECTED] > Subject: MAKE - problem with small/capital letters in filenames > > > Hi! > > I've got a simple makefile. It works well under DOS (with DJGPP) and > under Linux (Debian Woody). But it does not work under Cygwin. What versions of 'make' are you running on DOS, Linux, and Cygwin? Different versions have different behavior. As requested at http://cygwin.com/bugs.html, please include the output of 'cygcheck -s -v -r' (as an attachment). This will provide anyone looking at your question with information such as which version of Cygwin you are running and which version of 'make' you have installed. > The message: no rule to make 'hello.d' > The makefile: > > all: > $(CC) $(CFLAGS) hello.c -o hello.exe > > include hello.d > > %.d: %.c > @ $(CC) -MM $(CFLAGS) $< > $@ > > The above 'makefile' works on my installation of cygwin: $ ls makefile hello.c hello.c makefile $ make -f makefile makefile:4: hello.d: No such file or directory gcc -MM hello.c > hello.d gcc hello.c -o hello.exe It might be more evident what is causing your problem once you have included your 'cygcheck -s -v -r' output (as an attachment). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: RE: MAKE - problem with small/capital letters in filenames
try: %.D: %.C or %.d: %.C > -Original Message- > From: Graff_Zoltan [mailto:zotyo@;z1.fszek.hu] > Sent: Thursday, October 31, 2002 5:24 AM > To: Harig, Mark A. > Subject: Re: RE: MAKE - problem with small/capital letters in > filenames > > > > $ ls makefile hello.c > > hello.c makefile > Yes, it works if hello.c exists. But not work when HELLO.C exist. > My files are on the netware file server, and I see all files with > upper case letters under WinXp. > Under DOS and Linux the makefile works only with lower case letters. > > If I change the '%.d: %.c' > line to 'hello.d: hello.c' (with lower case letters) > it works well. > > %.c isn't good, but hello.c is? > Are the upper and lower case letters equal in file names, or not? > If yes, '%.d: %.c' should work. > If not, 'hello.d: hello.c' should not work. > > Thanks > Zoltan Graff > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: RE: MAKE - problem with small/capital letters in filenames
On Thu, 31 Oct 2002, Harig, Mark A. wrote: > try: > > %.D: %.C > > or > > %.d: %.C > > > -Original Message- > > From: Graff_Zoltan [mailto:zotyo@;z1.fszek.hu] > > Sent: Thursday, October 31, 2002 5:24 AM > > To: Harig, Mark A. > > Subject: Re: RE: MAKE - problem with small/capital letters in > > filenames > > > > > $ ls makefile hello.c > > > hello.c makefile > > Yes, it works if hello.c exists. But not work when HELLO.C exist. > > My files are on the netware file server, and I see all files with > > upper case letters under WinXp. > > Under DOS and Linux the makefile works only with lower case letters. > > > > If I change the '%.d: %.c' > > line to 'hello.d: hello.c' (with lower case letters) > > it works well. > > > > %.c isn't good, but hello.c is? > > Are the upper and lower case letters equal in file names, or not? > > If yes, '%.d: %.c' should work. > > If not, 'hello.d: hello.c' should not work. > > > > Thanks > > Zoltan Graff Please keep replies on-list. Thanks. Zoltan, In the Windows filesystem, there is indeed no difference between lowercase and uppercase letters in filenames (unless the Posix option is turned on under NT, but it probably isn't in your case). Cygwin has an option (in the CYGWIN environment variable) that controls whether it recognizes wrong-case filenames. The option is "check_case:", where is one of "strict", "relaxed", and "adjust". You can read up more on this in the User's Guide. From the information you provided, it seems you have it set to either "relaxed" or "adjust" (or unset, which defaults to "relaxed", IIRC). The check_case option, however, will only have effect if you try *opening* the file. The "%.d" construct in Makefiles performs another action on filenames, called "globbing". The globbing (same as the shell's "*.d") is not performed by Cygwin, but rather by the shell (or, in your case, make itself). Since the Cygwin ports of shells and make use stock Unix code as their base, there is no provision for globbing files with the wrong case (unless one was specifically put in, which I doubt). There may be options to control this, however, of which I'm not aware, so do read the man and info pages. This explains why "hello.d" works, but "%.d" doesn't: when the target is "hello.d", make tries to open (or stat) the file using Cygwin's system calls, and thus ignores the case (provided check_case is set appropriately). When the target is "%.d", make tries to glob all filenames that end in ".d" (not ignoring case), and thus doesn't find your HELLO.D. You can test this using "ls" in a shell (bash, in this case): $ export CYGWIN="$CYGWIN check_case:relaxed" $ ls hello.c $ ls Hello.C Hello.C $ ls *.C /bin/ls: *.C: No such file or directory $ If the options to allow case-insensitive globbing are present, all you have to do is turn them on (using the MAKEFLAGS environment variable for make, and the appropriate .*rc file for the shell, IIRC). If these options are not available, there are still a few ways to fix this. One is modifying your makefile to include both "%.d" and "%.D" as targets *every time* you need globbing. Another is keeping files on a local drive and using either rsync or cvs to synchronize it with the network drive (you'd have to set up a repository on the network drive for cvs, of course). And the third way, if you're feeling adventurous, is fixing the Cygwin ports of your favorite shell and make to allow case-insensitive globbing, and contributing the patches through this list to benefit the whole comminity and immortalizing your name in the archives as the guy who made globbing case-insensitive. :-D Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: RE: MAKE - problem with small/capital letters in filenames
Eventually, a gratefully accepted patch to the User's Manual (or FAQ) will be submitted that includes Igor Pechtchanski's detailed explanation, and we'll be able to simply point questioners to it with a URL. > > Zoltan Graff > > Please keep replies on-list. Thanks. > > Zoltan, > > In the Windows filesystem, there is indeed no difference > between lowercase > and uppercase letters in filenames (unless the Posix option > is turned on > under NT, but it probably isn't in your case). > > Cygwin has an option (in the CYGWIN environment variable) > that controls > whether it recognizes wrong-case filenames. The option is > "check_case:", where is one of "strict", "relaxed", and > "adjust". You can read up more on this in the User's Guide. From the > information you provided, it seems you have it set to either > "relaxed" or > "adjust" (or unset, which defaults to "relaxed", IIRC). > > The check_case option, however, will only have effect if you > try *opening* > the file. The "%.d" construct in Makefiles performs another action on > filenames, called "globbing". The globbing (same as the > shell's "*.d") is > not performed by Cygwin, but rather by the shell (or, in your > case, make > itself). Since the Cygwin ports of shells and make use stock > Unix code as > their base, there is no provision for globbing files with the > wrong case > (unless one was specifically put in, which I doubt). There > may be options > to control this, however, of which I'm not aware, so do read > the man and > info pages. > > This explains why "hello.d" works, but "%.d" doesn't: when > the target is > "hello.d", make tries to open (or stat) the file using Cygwin's system > calls, and thus ignores the case (provided check_case is set > appropriately). When the target is "%.d", make tries to glob all > filenames that end in ".d" (not ignoring case), and thus > doesn't find your > HELLO.D. You can test this using "ls" in a shell (bash, in > this case): > > $ export CYGWIN="$CYGWIN check_case:relaxed" > $ ls > hello.c > $ ls Hello.C > Hello.C > $ ls *.C > /bin/ls: *.C: No such file or directory > $ > > If the options to allow case-insensitive globbing are present, all you > have to do is turn them on (using the MAKEFLAGS environment variable > for make, and the appropriate .*rc file for the shell, IIRC). > > If these options are not available, there are still a few ways to fix > this. One is modifying your makefile to include both "%.d" > and "%.D" as > targets *every time* you need globbing. Another is keeping files on a > local drive and using either rsync or cvs to synchronize it with the > network drive (you'd have to set up a repository on the > network drive for > cvs, of course). And the third way, if you're feeling adventurous, is > fixing the Cygwin ports of your favorite shell and make to allow > case-insensitive globbing, and contributing the patches > through this list > to benefit the whole comminity and immortalizing your name in > the archives > as the guy who made globbing case-insensitive. :-D > Igor > -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: make problem: command works thru CLI, not thru make file
On Tue, 8 Jun 2004, santhosh km wrote: > Hi, > > I am trying porting of c files to VxWorks thru cygwin > using the GNU-Make Version 3.80 . > I have a problem while using makefile. The problem is > the commond: > "ccsimpc -o HELLO_WORLD helloWorld.c" > works on the command line and I get the HELLO_WORLD > executable file. > But doesn't work thru makefile, I get the error as: > make: *** [x] Error 1 > > Here the ccsimpc is equivalent to gcc, but ccsimpc is > the compiler for VxWorks. > > My make file helloWorld.mk, which has one target and > one line is > > x: > ccsimpc -o HELLO_WORLD helloWorld.o I assume those spaces are a tab, right? And is hellowWorld.o a typo? If not, that's the problem. An exact copy and past of the output and Makefile would be more helpful than your hand chosen snippets. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RE: RE: MAKE - problem with small/capital letters in filenames
Hi! > If the options to allow case-insensitive globbing are present, all you > have to do is turn them on (using the MAKEFLAGS environment variable > for make, and the appropriate .*rc file for the shell, IIRC). I see. I'll try to find this option. > If these options are not available, there are still a few ways to fix > this. One is modifying your makefile to include both "%.d" and "%.D" as > targets *every time* you need globbing. Doesn't work. HELLO.D generated, but 'no rule ot make target hello.d'. > Another is keeping files on a > local drive and using either rsync or cvs to synchronize it with the > network drive If nothing else work I'll try this. Thanks Zoltan Graff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
