From: Andrew B. <ab...@ee...> - 2001-12-18 21:57:34
|
I took the test from configure (that failed on my computer) and ran it manually: testgc.cc ---------- /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char GC_malloc (); int main () { GC_malloc (); ; return 0; } ------------ bash-2.04$ g++ -o testgc.exe -g -O2 -L /e/usr/misc/lib -v testgc.cc -lgc ^^^ note the space after -L arg Reading specs from e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/specs gcc version 2.95.3-6 (mingw special) e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cpp0.exe -lang-c++ -v -iprefix e:\mingw\bin\../lib/gcc-lib/mingw32/2.95.3-6/ -D__GNUC__=3D2 -D__GNUG__=3D2 -D__GNUC_MINOR__=3D95 -D__cplusplus -Di386 -D_WIN32 = -DWIN32 -D__WIN32__ -D__MINGW32__=3D1.0 -D__MSVCRT__ -DWINNT -D_X86_=3D1 -D__STDC__=3D1 -D__stdcall=3D__attribute__((__stdcall__)) -D_stdcall=3D__attribute__((__stdcall__)) -D__cdecl=3D__attribute__((__cdecl__)) = -D__declspec(x)=3D__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=3D1.0 -D__MSVCRT__ -D__WINNT__ -D_X86_=3D1 -D__STDC__=3D1 -D__stdcall=3D__attribute__((__stdcall__)) -D___stdcall__=3D__attribute__((__stdcall__)) -D__cdecl=3D__attribute__((__cdecl__)) = -D__declspec(x)=3D__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=3D__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS -D__OPTIMIZE__ -g -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ testgc.cc E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii GNU CPP version 2.95.3-6 (mingw special) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3 e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include =20 e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/include e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/include End of search list. The following default directories have been omitted from the search path: /usr/local/mingw32/include End of omitted list. e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cc1plus.exe E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii -quiet -dumpbase testgc.cc -g -O2 -version -o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s GNU C++ version 2.95.3-6 (mingw special) (mingw32) compiled by GNU C version 2.95.3-6 (mingw special). =20 e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\as. exe -o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s =20 e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. exe -Bdynamic -o testgc.exe e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../crt2.o -L /e/usr/misc/lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Le:/mingw/bin/../lib/gcc-lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o -lgc -lstdc++ -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. exe: cannot find -lgc Looks like msys didn't transform the path /e/usr/misc/lib into e:/usr/misc/lib, even though it was its own argv. Hmm. Andy > -----Original Message----- > From: Earnie Boyd [mailto:ear...@ya...] > Sent: Tuesday, December 18, 2001 4:01 AM > To: Andrew Begel > Cc: min...@li... > Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 >=20 >=20 > Andrew Begel wrote: > >=20 > > On Sunday, December 16, 2001, at 09:11 AM, Earnie Boyd wrote: > >=20 > > >> > > >> However, when gcc tries to then find my library, it=20 > can't. According to > > >> the config.log file, the pathname /e/usr/misc/lib was=20 > passed without > > >> translation to the gcc command line, as=20 > -L/e/usr/misc/lib, which, of > > >> course, my MinGW gcc (2.95.3-6) can't see. > > >> > > >> Is there a good way to rewrite this use of AC_CHECK_LIB=20 > to get the > > >> posix->dos pathname translation to kick in? > > >> > > > > > > Put a space between the -L and the path /e/usr/misc/lib. > >=20 > > Sorry, I can't do that with gcc. There can be no spaces=20 > between -L and > > its path, and -I and its path. > >=20 >=20 > Huh, what version of GCC are you using? My version of GCC=20 > and all other > versions I've used sure doesn't care. Modify the Makefile and put a > space between the -L and the path to try it. Or wait for the=20 > release of > the fix. >=20 > Earnie. >=20 > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >=20 >=20 |
From: Andrew B. <ab...@ee...> - 2001-12-19 22:58:30
|
> -----Original Message----- > From: Earnie Boyd [mailto:ear...@ya...] > Sent: Wednesday, December 19, 2001 8:20 AM > To: Andrew Begel > Cc: MM List > Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 >=20 >=20 > So, could you try again, please. Respond with the output of=20 > `uname -a', > `mount', `g++ --version', and `ls -la /bin'. >=20 bash-2.04$ uname -a MINGW32_NT-5.0 JUNIPER 1.0.1(0.46/3/2) 2001-10-18 23:00 i686 unknown bash-2.04$ mount E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp on /tmp type user (binmode,noumount) E:\msys\1.0\home on /home type user (binmode,noumount) E:\msys\1.0\bin on /bin type user (binmode,noumount) E:\msys\1.0 on / type user (binmode,noumount) E:\msys\1.0 on /usr type user (binmode,noumount) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) f: on /f type user (binmode,noumount) g: on /g type user (binmode,noumount) h: on /h type user (binmode,noumount) i: on /i type user (binmode,noumount) n: on /n type user (binmode,noumount) p: on /p type user (binmode,noumount) s: on /s type user (binmode,noumount) bash-2.04$=20 bash-2.04$ g++ --version 2.95.3-6 bash-2.04$ ls -la /bin total 12084 drwxr-xr-x 2 abegel Administ 49152 Dec 14 14:19 . drwxr-xr-x 6 abegel Administ 4096 Dec 14 14:14 .. -rwxr-xr-x 1 abegel Administ 128522 Oct 2 10:45 a2p.exe -rwxr-xr-x 1 abegel Administ 364544 Oct 16 14:37 addr2line.exe -rwxr-xr-x 1 abegel Administ 332288 Oct 16 14:37 ar.exe -rwxr-xr-x 1 abegel Administ 544768 Oct 16 14:38 as.exe -rwxr-xr-x 1 abegel Administ 5060 Oct 16 06:22 autoconf -rwxr-xr-x 1 abegel Administ 8913 Oct 16 06:22 autoheader -rwxr-xr-x 1 abegel Administ 6248 Oct 16 06:22 autoreconf -rwxr-xr-x 1 abegel Administ 9928 Oct 16 06:22 autoscan -rwxr-xr-x 1 abegel Administ 3280 Oct 16 06:22 autoupdate -rwxr-xr-x 1 abegel Administ 17408 Oct 18 15:47 basename.exe -rwxr-xr-x 1 abegel Administ 480256 Oct 16 12:43 bash.exe -rwxr-xr-x 1 abegel Administ 5149 Oct 16 12:43 bashbug -rwxr-xr-x 1 abegel Administ 83968 Oct 15 20:41 bison.exe -rw-r--r-- 1 abegel Administ 163 Sep 4 17:23 bootinit -rwxr-xr-x 1 abegel Administ 102553 Oct 16 06:13 bunzip2.exe -rwxr-xr-x 1 abegel Administ 72704 Oct 15 20:45 byacc.exe -rwxr-xr-x 1 abegel Administ 102553 Oct 16 06:13 bzcat.exe -rwxr-xr-x 1 abegel Administ 102553 Oct 16 06:13 bzip2.exe -rwxr-xr-x 1 abegel Administ 25476 Oct 16 06:13 bzip2recover.exe -rwxr-xr-x 1 abegel Administ 74240 Oct 18 12:43 c++.exe -rwxr-xr-x 1 abegel Administ 37888 Oct 18 12:43 c++filt.exe -rwxr-xr-x 1 abegel Administ 37708 Oct 2 10:42 c2ph -rwxr-xr-x 1 abegel Administ 3754 Oct 18 15:07 c_rehash -rwxr-xr-x 1 abegel Administ 22016 Oct 18 19:34 cat.exe -rwxr-xr-x 1 abegel Administ 28160 Oct 16 16:17 chgrp.exe -rwxr-xr-x 1 abegel Administ 27648 Oct 16 16:17 chmod.exe -rwxr-xr-x 1 abegel Administ 29696 Oct 16 16:17 chown.exe -rwxr-xr-x 1 abegel Administ 17920 Oct 18 15:47 chroot.exe -rwxr-xr-x 1 abegel Administ 19456 Oct 18 19:34 cksum.exe -rwxr-xr-x 1 abegel Administ 10752 Oct 16 16:02 cmp.exe -rwxr-xr-x 1 abegel Administ 19968 Oct 18 19:34 comm.exe -rwxr-xr-x 1 abegel Administ 74240 Oct 16 16:17 cp.exe -rwxr-xr-x 1 abegel Administ 74752 Oct 18 12:43 cpp.exe -rwxr-xr-x 1 abegel Administ 64000 Oct 18 19:34 csplit.exe -rwxr-xr-x 1 abegel Administ 101376 Oct 16 15:48 ctags.exe -rwxr-xr-x 1 abegel Administ 23552 Oct 18 19:34 cut.exe -rwxr-xr-x 1 abegel Administ 663618 Oct 16 16:00 cvs.exe -rwxr-xr-x 1 abegel Administ 14522 Oct 16 16:00 cvsbug -rwxr-xr-x 1 abegel Administ 124595 Oct 18 21:07 cygcheck.exe -rwxr-xr-x 1 abegel Administ 33042 Oct 18 21:07 cygpath.exe -rwxr-xr-x 1 abegel Administ 49152 Oct 18 15:47 date.exe -rwxr-xr-x 1 abegel Administ 41984 Oct 16 16:17 dd.exe -rwxr-xr-x 1 abegel Administ 38400 Oct 16 16:17 df.exe -rwxr-xr-x 1 abegel Administ 66048 Oct 16 16:02 diff.exe -rwxr-xr-x 1 abegel Administ 17408 Oct 16 16:02 diff3.exe -rwxr-xr-x 1 abegel Administ 69632 Oct 16 16:17 dir.exe -rwxr-xr-x 1 abegel Administ 31232 Oct 16 16:17 dircolors.exe -rwxr-xr-x 1 abegel Administ 17408 Oct 18 15:47 dirname.exe -rwxr-xr-x 1 abegel Administ 409088 Oct 16 14:37 dlltool.exe -rwxr-xr-x 1 abegel Administ 35840 Oct 16 14:38 dllwrap.exe -rwxr-xr-x 1 abegel Administ 21411 Oct 2 10:42 dprofpp -rwxr-xr-x 1 abegel Administ 38400 Oct 16 16:17 du.exe -rwxr-xr-x 1 abegel Administ 18432 Oct 18 15:47 echo.exe -rwxr-xr-x 1 abegel Administ 83968 Oct 18 11:37 egrep.exe -rwxr-xr-x 1 abegel Administ 18432 Oct 18 15:47 env.exe -rwxr-xr-x 1 abegel Administ 20480 Oct 18 19:34 expand.exe -rwxr-xr-x 1 abegel Administ 51200 Oct 18 15:47 expr.exe -rwxr-xr-x 1 abegel Administ 31744 Oct 18 15:47 factor.exe -rwxr-xr-x 1 abegel Administ 12288 Oct 18 15:47 false.exe -rwxr-xr-x 1 abegel Administ 83968 Oct 18 11:37 fgrep.exe -rwxr-xr-x 1 abegel Administ 226931 Oct 16 16:24 find.exe -rwxr-xr-x 1 abegel Administ 23749 Oct 2 10:42 find2perl -rwxr-xr-x 1 abegel Administ 157184 Oct 16 16:29 flex.exe -rwxr-xr-x 1 abegel Administ 23552 Oct 18 19:34 fmt.exe -rwxr-xr-x 1 abegel Administ 20992 Oct 18 19:34 fold.exe -rwxr-xr-x 1 abegel Administ 100641 Oct 18 20:28 ftp.exe -rwxr-xr-x 1 abegel Administ 79872 Oct 18 12:43 g77.exe -rwxr-xr-x 1 abegel Administ 67584 Oct 16 14:38 gasp.exe -rwxr-xr-x 1 abegel Administ 174592 Oct 16 16:32 gawk.exe -rwxr-xr-x 1 abegel Administ 73216 Oct 18 12:43 gcc-msys.exe -rwxr-xr-x 1 abegel Administ 15360 Oct 18 12:43 gcov.exe -rwxr-xr-x 1 abegel Administ 3223558 Oct 18 09:45 gdb.exe -rwxr-xr-x 1 abegel Administ 157696 Dec 7 06:57 gmake.exe -rwxr-xr-x 1 abegel Administ 434688 Oct 16 14:38 gprof.exe -rwxr-xr-x 1 abegel Administ 83968 Oct 18 11:37 grep.exe -rwxr-xr-x 1 abegel Administ 1698 Oct 18 15:47 groups -rwxr-xr-x 1 abegel Administ 51712 Oct 18 12:01 gunzip.exe -rw-r--r-- 1 abegel Administ 3993 Oct 18 12:01 gzexe -rwxr-xr-x 1 abegel Administ 51712 Oct 18 12:01 gzip.exe -rwxr-xr-x 1 abegel Administ 20290 Oct 2 10:42 h2ph -rwxr-xr-x 1 abegel Administ 48793 Oct 2 10:42 h2xs -rwxr-xr-x 1 abegel Administ 25088 Oct 18 19:34 head.exe -rwxr-xr-x 1 abegel Administ 18432 Oct 18 15:47 hostname.exe -rwxr-xr-x 1 abegel Administ 21504 Oct 18 15:47 id.exe -rwxr-xr-x 1 abegel Administ 2883 Oct 16 06:22 ifnames -rwxr-xr-x 1 abegel Administ 3121 Oct 16 16:32 igawk -rwxr-xr-x 1 abegel Administ 166400 Oct 18 20:11 info.exe -rwxr-xr-x 1 abegel Administ 32768 Oct 18 20:11 install-info.exe -rwxr-xr-x 1 abegel Administ 78336 Oct 16 16:17 install.exe -rwxr-xr-x 1 abegel Administ 5682 Oct 18 20:28 iu-config -rwxr-xr-x 1 abegel Administ 28160 Oct 18 19:34 join.exe -rwxr-xr-x 1 abegel Administ 561664 Oct 16 14:38 ld.exe -rwxr-xr-x 1 abegel Administ 149719 Oct 18 12:20 less.exe -rwxr-xr-x 1 abegel Administ 21812 Oct 18 12:20 lessecho.exe -rwxr-xr-x 1 abegel Administ 30226 Oct 18 12:20 lesskey.exe -rwxr-xr-x 1 abegel Administ 99754 Oct 27 14:53 libW11.dll -rwxr-xr-x 1 abegel Administ 57856 Oct 16 16:17 ln.exe -rwxr-xr-x 1 abegel Administ 66676 Oct 16 16:24 locate.exe -rwxr-xr-x 1 abegel Administ 7168 Oct 18 20:28 logger.exe -rwxr-xr-x 1 abegel Administ 17408 Oct 18 15:47 logname.exe -rwxr-xr-x 1 abegel Administ 69632 Oct 16 16:17 ls.exe -rwxr-xr-x 1 abegel Administ 117622 Oct 18 12:25 m4.exe -rwxr-xr-x 1 abegel Administ 145920 Oct 18 12:54 make.exe -rwxr-xr-x 1 abegel Administ 131072 Oct 18 20:11 makeinfo.exe -rwxr-xr-x 1 abegel Administ 27648 Oct 18 19:34 md5sum.exe -rwxr-xr-x 1 abegel Administ 20666 Aug 29 13:39 mingwm10.dll -rwxr-xr-x 1 abegel Administ 28672 Oct 16 16:17 mkdir.exe -rwxr-xr-x 1 abegel Administ 24576 Oct 16 16:17 mkfifo.exe -rwxr-xr-x 1 abegel Administ 27136 Oct 16 16:17 mknod.exe -rwxr-xr-x 1 abegel Administ 30115 Oct 18 21:07 mount.exe -rwxr-xr-x 1 abegel Administ 760112 Oct 18 21:14 msys-1.0.dll -rwxr-xr-x 1 abegel Administ 1977 Oct 18 10:12 msysconfigure -rwxr-xr-x 1 abegel Administ 81920 Oct 16 16:17 mv.exe -rwxr-xr-x 1 abegel Administ 760112 Oct 18 21:13 new-msys-1.0.dll -rwxr-xr-x 1 abegel Administ 18944 Oct 18 15:47 nice.exe -rwxr-xr-x 1 abegel Administ 47616 Oct 18 19:34 nl.exe -rwxr-xr-x 1 abegel Administ 375808 Oct 16 14:38 nm.exe -rwxr-xr-x 1 abegel Administ 2534 Oct 18 15:47 nohup -rwxr-xr-x 1 abegel Administ 524800 Oct 16 14:37 objcopy.exe -rwxr-xr-x 1 abegel Administ 585728 Oct 16 14:37 objdump.exe -rwxr-xr-x 1 abegel Administ 35328 Oct 18 19:34 od.exe -rwxr-xr-x 1 abegel Administ 897536 Oct 18 15:07 openssl.exe -rwxr-xr-x 1 abegel Administ 20480 Oct 18 19:34 paste.exe -rwxr-xr-x 1 abegel Administ 59392 Oct 18 15:26 patch.exe -rwxr-xr-x 1 abegel Administ 19968 Oct 18 15:47 pathchk.exe -rwxr-xr-x 1 abegel Administ 788505 Oct 2 10:44 perl5.6.1.exe -rwxr-xr-x 1 abegel Administ 36615 Oct 2 10:42 perlbug -rwxr-xr-x 1 abegel Administ 17546 Oct 2 10:42 perlcc -rwxr-xr-x 1 abegel Administ 23460 Oct 2 10:42 perldoc -rwxr-xr-x 1 abegel Administ 23040 Oct 18 15:47 pinky.exe -rwxr-xr-x 1 abegel Administ 4579 Oct 2 10:42 pl2pm -rwxr-xr-x 1 abegel Administ 2482 Oct 2 10:42 pod2html -rwxr-xr-x 1 abegel Administ 8174 Oct 2 10:42 pod2latex -rwxr-xr-x 1 abegel Administ 18031 Oct 2 10:42 pod2man -rwxr-xr-x 1 abegel Administ 7080 Oct 2 10:42 pod2text -rwxr-xr-x 1 abegel Administ 3433 Oct 2 10:42 pod2usage -rwxr-xr-x 1 abegel Administ 3470 Oct 2 10:42 podchecker -rwxr-xr-x 1 abegel Administ 2579 Oct 2 10:42 podselect -rwxr-xr-x 1 abegel Administ 38912 Oct 18 19:34 pr.exe -rwxr-xr-x 1 abegel Administ 17408 Oct 18 15:47 printenv.exe -rwxr-xr-x 1 abegel Administ 23552 Oct 18 15:47 printf.exe -rwxr-xr-x 1 abegel Administ 38400 Oct 18 12:43 protoize.exe -rwxr-xr-x 1 abegel Administ 35173 Oct 18 21:07 ps.exe -rwxr-xr-x 1 abegel Administ 59392 Oct 18 19:34 ptx.exe -rwxr-xr-x 1 abegel Administ 17920 Oct 18 15:47 pwd.exe -rwxr-xr-x 1 abegel Administ 332288 Oct 16 14:37 ranlib.exe -rwxr-xr-x 1 abegel Administ 42169 Oct 18 20:28 rcp.exe -rwxr-xr-x 1 abegel Administ 18300 Oct 16 16:00 rcs2log -rwxr-xr-x 1 abegel Administ 190976 Oct 16 14:37 readelf.exe -rwxr-xr-x 1 abegel Administ 11264 Oct 18 20:28 rlogin.exe -rwxr-xr-x 1 abegel Administ 62464 Oct 16 16:17 rm.exe -rwxr-xr-x 1 abegel Administ 22528 Oct 16 16:17 rmdir.exe -rwxr-xr-x 1 abegel Administ 10752 Oct 18 20:28 rsh.exe -rwxr-xr-x 1 abegel Administ 131950 Oct 27 15:34 rxvt.exe -rwxr-xr-x 1 abegel Administ 15500 Oct 2 10:42 s2p -rwxr-xr-x 1 abegel Administ 24064 Oct 18 15:24 scp.exe -rwxr-xr-x 1 abegel Administ 20992 Oct 16 16:02 sdiff.exe -rwxr-xr-x 1 abegel Administ 47616 Oct 18 15:30 sed.exe -rwxr-xr-x 1 abegel Administ 22016 Oct 18 15:47 seq.exe -rwxr-xr-x 1 abegel Administ 83456 Oct 18 15:24 sftp.exe -rwxr-xr-x 1 abegel Administ 70656 Oct 1 14:42 sh.exe -rwxr-xr-x 1 abegel Administ 43008 Oct 16 16:16 shred -rwxr-xr-x 1 abegel Administ 43008 Oct 16 16:17 shred.exe -rwxr-xr-x 1 abegel Administ 312320 Oct 16 14:37 size.exe -rwxr-xr-x 1 abegel Administ 17408 Oct 18 15:47 sleep.exe -rwxr-xr-x 1 abegel Administ 43520 Oct 18 19:34 sort.exe -rwxr-xr-x 1 abegel Administ 15072 Oct 2 10:42 splain -rwxr-xr-x 1 abegel Administ 23040 Oct 18 19:34 split.exe -rwxr-xr-x 1 abegel Administ 524800 Oct 18 15:24 ssh-add.exe -rwxr-xr-x 1 abegel Administ 477696 Oct 18 15:24 ssh-agent.exe -rwxr-xr-x 1 abegel Administ 531968 Oct 18 15:24 ssh-keygen.exe -rwxr-xr-x 1 abegel Administ 237056 Oct 18 15:24 ssh-keyscan.exe -rwxr-xr-x 1 abegel Administ 752128 Oct 18 15:24 ssh.exe -rwxr-xr-x 1 abegel Administ 32768 Oct 18 21:07 strace.exe -rwxr-xr-x 1 abegel Administ 311296 Oct 16 14:37 strings.exe -rwxr-xr-x 1 abegel Administ 524800 Oct 16 14:38 strip.exe -rwxr-xr-x 1 abegel Administ 38400 Oct 18 15:47 stty.exe -rwxr-xr-x 1 abegel Administ 47104 Oct 18 15:46 su.exe -rwxr-xr-x 1 abegel Administ 18944 Oct 18 19:34 sum.exe -rwxr-xr-x 1 abegel Administ 20992 Oct 16 16:16 sync -rwxr-xr-x 1 abegel Administ 20992 Oct 16 16:17 sync.exe -rwxr-xr-x 1 abegel Administ 45056 Oct 18 19:34 tac.exe -rwxr-xr-x 1 abegel Administ 37376 Oct 18 19:34 tail.exe -rwxr-xr-x 1 abegel Administ 158208 Oct 18 16:27 tar.exe -rwxr-xr-x 1 abegel Administ 18944 Oct 18 15:47 tee.exe -rwxr-xr-x 1 abegel Administ 116865 Oct 18 20:28 telnet.exe -rwxr-xr-x 1 abegel Administ 36352 Oct 18 15:47 test.exe -rwxr-xr-x 1 abegel Administ 21641 Oct 18 20:11 texi2dvi -rwxr-xr-x 1 abegel Administ 23552 Oct 18 20:11 texindex.exe -rwxr-xr-x 1 abegel Administ 40380 Oct 18 20:28 tftp.exe -rwxr-xr-x 1 abegel Administ 38400 Oct 16 16:17 touch.exe -rwxr-xr-x 1 abegel Administ 32768 Oct 18 19:34 tr.exe -rwxr-xr-x 1 abegel Administ 12288 Oct 18 15:47 true.exe -rwxr-xr-x 1 abegel Administ 21504 Oct 18 19:34 tsort.exe -rwxr-xr-x 1 abegel Administ 17920 Oct 18 15:47 tty.exe -rwxr-xr-x 1 abegel Administ 17920 Oct 18 15:47 uname.exe -rwxr-xr-x 1 abegel Administ 20480 Oct 18 19:34 unexpand.exe -rwxr-xr-x 1 abegel Administ 23552 Oct 18 19:34 uniq.exe -rwxr-xr-x 1 abegel Administ 32768 Oct 18 12:43 unprotoize.exe -rwxr-xr-x 1 abegel Administ 4524 Oct 16 16:24 updatedb -rwxr-xr-x 1 abegel Administ 18944 Oct 18 15:47 users.exe -rwxr-xr-x 1 abegel Administ 69632 Oct 16 16:17 vdir.exe -rwxr-xr-x 1 abegel Administ 600576 Oct 18 19:57 vim.exe -rwxr-xr-x 1 abegel Administ 376 Oct 18 19:57 vimtutor -rwxr-xr-x 1 abegel Administ 30208 Oct 18 19:34 wc.exe -rwxr-xr-x 1 abegel Administ 21504 Oct 18 15:47 who.exe -rwxr-xr-x 1 abegel Administ 17920 Oct 18 15:47 whoami.exe -rwxr-xr-x 1 abegel Administ 415232 Oct 16 14:37 windres.exe -rwxr-xr-x 1 abegel Administ 64760 Oct 16 16:24 xargs.exe -rwxr-xr-x 1 abegel Administ 10752 Oct 18 19:57 xxd.exe -rwxr-xr-x 1 abegel Administ 16896 Oct 18 15:47 yes.exe -rw-r--r-- 1 abegel Administ 2072 Oct 18 12:01 zcmp -rw-r--r-- 1 abegel Administ 1048 Oct 18 12:01 zforce -rw-r--r-- 1 abegel Administ 1402 Oct 18 12:01 zgrep -rw-r--r-- 1 abegel Administ 1122 Oct 18 12:01 zmore -rw-r--r-- 1 abegel Administ 3650 Oct 18 12:01 znew bash-2.04$=20 ------------ I tried the same compile line again, with the space between -L and /e/usr/misc/lib, and got the same problem. However, you're correct that you can have a space between the -L and the path because if I substitute e:\\usr\\misc\\lib for /e/usr/misc/lib, it works.=20 I'll try your msys-1.03 release and see if that does the trick.=20 Thanks andy > In the mean time I'll try a few other scenarios. >=20 > Thanks, > Earnie. >=20 > > Reading specs from=20 > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/specs > > gcc version 2.95.3-6 (mingw special) > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cpp0.exe -lang-c++ -v > > -iprefix e:\mingw\bin\../lib/gcc-lib/mingw32/2.95.3-6/ = -D__GNUC__=3D2 > > -D__GNUG__=3D2 -D__GNUC_MINOR__=3D95 -D__cplusplus -Di386=20 > -D_WIN32 -DWIN32 > > -D__WIN32__ -D__MINGW32__=3D1.0 -D__MSVCRT__ -DWINNT -D_X86_=3D1 > > -D__STDC__=3D1 -D__stdcall=3D__attribute__((__stdcall__)) > > -D_stdcall=3D__attribute__((__stdcall__)) > > -D__cdecl=3D__attribute__((__cdecl__))=20 > -D__declspec(x)=3D__attribute__((x)) > > -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=3D1.0 > > -D__MSVCRT__ -D__WINNT__ -D_X86_=3D1 -D__STDC__=3D1 > > -D__stdcall=3D__attribute__((__stdcall__)) > > -D___stdcall__=3D__attribute__((__stdcall__)) > > -D__cdecl=3D__attribute__((__cdecl__))=20 > -D__declspec(x)=3D__attribute__((x)) > > -D__i386 -D__WIN32 -D__WINNT=20 > -D___stdcall=3D__attribute__((__stdcall__)) > > -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS > > -D__OPTIMIZE__ -g -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 > > -D__i386__ testgc.cc=20 > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii > > GNU CPP version 2.95.3-6 (mingw special) (80386, BSD syntax) > > #include "..." search starts here: > > #include <...> search starts here: > > =20 > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3 > > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include > >=20 > >=20 > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw > 32/include > > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/include > > End of search list. > > The following default directories have been omitted from the search > > path: > > /usr/local/mingw32/include > > End of omitted list. > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cc1plus.exe > > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii -quiet -dumpbase > > testgc.cc -g -O2 -version -o > > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > > GNU C++ version 2.95.3-6 (mingw special) (mingw32) compiled by GNU C > > version 2.95.3-6 (mingw special). > >=20 > >=20 > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw > 32\bin\as. > > exe -o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o > > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > >=20 > >=20 > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw > 32\bin\ld. > > exe -Bdynamic -o testgc.exe > > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../crt2.o -L > > /e/usr/misc/lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 > > -Le:/mingw/bin/../lib/gcc-lib > >=20 > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib > > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. > > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o -lgc -lstdc++ > > -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 > > -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt > >=20 > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw > 32\bin\ld. > > exe: cannot find -lgc > >=20 > > Looks like msys didn't transform the path /e/usr/misc/lib into > > e:/usr/misc/lib, even though it was its own argv. Hmm. > > >=20 > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >=20 >=20 |
From: Earnie B. <ear...@ya...> - 2001-12-19 23:16:05
|
Andrew Begel wrote: > > > -----Original Message----- > > From: Earnie Boyd [mailto:ear...@ya...] > > Sent: Wednesday, December 19, 2001 8:20 AM > > To: Andrew Begel > > Cc: MM List > > Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 > > > > > > So, could you try again, please. Respond with the output of > > `uname -a', > > `mount', `g++ --version', and `ls -la /bin'. > > > > bash-2.04$ uname -a > MINGW32_NT-5.0 JUNIPER 1.0.1(0.46/3/2) 2001-10-18 23:00 i686 unknown Ah-ha. That's it. 1.0.1 didn't support that functionality. Note, version 1.0.2 doesn't contain all of the binaries that you listed. As I've said earlier, I was over ambitious in what to distribute with that version. Version 1.0.2 only contains enough binaries to execute a typical configure script. When I create version 1.0.3 it will contain the same binaries as 1.0.2 but will handle some more functionality. You can download a snapshot of the 1.0.3.dll from ftp://ftp1.sf.net/pub/sourceforge/mingw/msys-1.0.dll-20011219.bz2 that you can replace your current msys-1.0.dll with. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2001-12-19 23:20:56
|
Earnie Boyd wrote: > > > When I create version 1.0.3 it will contain the same binaries as 1.0.2 > but will handle some more functionality. You can download a snapshot of > the 1.0.3.dll from > ftp://ftp1.sf.net/pub/sourceforge/mingw/msys-1.0.dll-20011219.bz2 that ^. ftp://ftp1.sf.net/pub/sourceforge/mingw/msys-1.0.dll.20011219.bz2 > you can replace your current msys-1.0.dll with. > Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Andrew B. <ab...@ee...> - 2001-12-19 23:56:52
|
Ok, after getting the new 1.0.3 DLL, my configure script works fine now. But, I've got a problem here. If msys only comes with enough to run a configure script, it's got to include enough to run the build itself too! Let's say I search for libraries in the configure script and find them in /c/usr/misc/lib, and I insert that into my Makefiles. Well, now the only shell capable of interpreting that path is the msys bash. Which means that my build itself has to be using msys' bash to start up gcc, or gcc won't be able to interpret the path! However, if msys had an explicit path-translate command, able to translate an msys posix path to a DOS one for insertion into my makefile, then I'm sure I could run the make in a normal bash, like that cygwin. andy On Wednesday, December 19, 2001, at 03:15 PM, Earnie Boyd wrote: > Andrew Begel wrote: >> >>> -----Original Message----- >>> From: Earnie Boyd [mailto:ear...@ya...] >>> Sent: Wednesday, December 19, 2001 8:20 AM >>> To: Andrew Begel >>> Cc: MM List >>> Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 >>> >>> >>> So, could you try again, please. Respond with the output of >>> `uname -a', >>> `mount', `g++ --version', and `ls -la /bin'. >>> >> >> bash-2.04$ uname -a >> MINGW32_NT-5.0 JUNIPER 1.0.1(0.46/3/2) 2001-10-18 23:00 i686 unknown > > Ah-ha. That's it. 1.0.1 didn't support that functionality. Note, > version 1.0.2 doesn't contain all of the binaries that you listed. As > I've said earlier, I was over ambitious in what to distribute with that > version. Version 1.0.2 only contains enough binaries to execute a > typical configure script. > > When I create version 1.0.3 it will contain the same binaries as 1.0.2 > but will handle some more functionality. You can download a snapshot of > the 1.0.3.dll from > ftp://ftp1.sf.net/pub/sourceforge/mingw/msys-1.0.dll-20011219.bz2 that > you can replace your current msys-1.0.dll with. > > Earnie. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > |
From: Earnie B. <ear...@ya...> - 2001-12-20 13:09:53
|
Andrew Begel wrote: > > Ok, after getting the new 1.0.3 DLL, my configure script works fine now. > Good, I think I recall suggesting that you were using 1.0.1 in my first response. > But, I've got a problem here. If msys only comes with enough to run a > configure script, it's got to include enough to run the build itself > too! Not a binary install. And I'm not wanting anyone to use MSYS to create MSYS programs. > Let's say I search for libraries in the configure script and find > them in /c/usr/misc/lib, and I insert that into my Makefiles. Well, now > the only shell capable of interpreting that path is the msys bash. Which > means that my build itself has to be using msys' bash to start up gcc, > or gcc won't be able to interpret the path! > I'd say you need to study autoconf, automake and libtools (collectively called autotools). You don't hardcode absolute paths in the Makefile.am or the configure.[ac|in] if you want portability. You also don't distribute the generated Makefile and other generated files from the configure script so there's no chance for the user to get your specific absolute path. > However, if msys had an explicit path-translate command, able to > translate an msys posix path to a DOS one for insertion into my > makefile, then I'm sure I could run the make in a normal bash, like that > cygwin. > The path translation utility isn't needed for MSYS, you're thinking of the Cygwin environment. I don't know what you mean by "normal bash". I've not changed any coding for bash so it's just as normal as Cygwin's bash. Hmm..., I think I see what you're driving at, you generated a Makefile using MSYS and tried using Cygwin to execute the make command. That isn't sane, and is like generating a Makefile on one system and taking it to a different system to be used to build the package. It ain't going to fly, no one should expect that it would. That is also analogous to building a model airplane with the parts from one style of airplane and the instructions from another. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Andrew B. <ab...@ee...> - 2001-12-20 18:26:01
|
On Thursday, December 20, 2001, at 05:09 AM, Earnie Boyd wrote: > Hmm..., I think I see what you're driving at, you generated a Makefile > using MSYS and tried using Cygwin to execute the make command. That > isn't sane, and is like generating a Makefile on one system and taking > it to a different system to be used to build the package. It ain't > going to fly, no one should expect that it would. That is also > analogous to building a model airplane with the parts from one style of > airplane and the instructions from another. > Yeah, now you've got it. So I used configure under an MSYS bash to generate my Makefile from my Makefile.in, and now what? All the paths that configure figured out where MSYS-style paths. Now, if there's no gmake that understands MSYS paths, I'm kinda stuck, no? All these great paths and nowhere to use them... There are two categories of translations that I'll need then, if I try to use gmake from MinGW or gmake from cygwin (more likely). I need to translate MSYS paths to DOS paths (if I use DOS tools, such as MinGW gcc.exe or a native XEmacs -batch to run some Lisp code) and also translate MSYS paths to cygwin paths (for unix-like tools, such as "sed" and "awk" and other nice utilities I use in my build process). Without the translation, or the ability to run Makefiles in MSYS using an MSYS gmake, I don't see how MSYS could be useful at all.... Please correct my line of reasoning here, if I'm just not seeing the right big picture. andrew |
From: Earnie B. <ear...@ya...> - 2001-12-20 18:42:22
|
Andrew Begel wrote: > > On Thursday, December 20, 2001, at 05:09 AM, Earnie Boyd wrote: > > > Hmm..., I think I see what you're driving at, you generated a Makefile > > using MSYS and tried using Cygwin to execute the make command. That > > isn't sane, and is like generating a Makefile on one system and taking > > it to a different system to be used to build the package. It ain't > > going to fly, no one should expect that it would. That is also > > analogous to building a model airplane with the parts from one style of > > airplane and the instructions from another. > > > > Yeah, now you've got it. So I used configure under an MSYS bash to > generate my Makefile from my Makefile.in, and now what? All the paths > that configure figured out where MSYS-style paths. Now, if there's no > gmake that understands MSYS paths, I'm kinda stuck, no? All these great > paths and nowhere to use them... > No, you're not stuck. The POSIX paths get translated to native win32 paths under MSYS. That's the point of MSYS. That's why it exists. > There are two categories of translations that I'll need then, if I try > to use gmake from MinGW or gmake from cygwin (more likely). POINT: You can't mix Cygwin and MSYS. There is a gmake distributed with MSYS if you need that one use that _NOT_ the Cygwin make. > I need to > translate MSYS paths to DOS paths (if I use DOS tools, such as MinGW > gcc.exe or a native XEmacs -batch to run some Lisp code) and also > translate MSYS paths to cygwin paths (for unix-like tools, such as "sed" > and "awk" and other nice utilities I use in my build process). > Forget using Cygwin with MSYS, not possible. The point of MSYS is to translate the paths on the arguments so that POSIXised paths get translated to Win32 style paths without you needing to think about it. As for the nice unix utilities, what's missing from MSYS that you need for building native MinGW applications? > Without the translation, or the ability to run Makefiles in MSYS using > an MSYS gmake, I don't see how MSYS could be useful at all.... Please > correct my line of reasoning here, if I'm just not seeing the right big > picture. > I thought that you said you were able to use MSYS to build your application. What exactly are you having a problem with? I'm lost in your confusion. All that you should need do is configure make (if you want the MinGW version of make) or `gmake MAKE=gmake' (for the MSYS version of make). Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Andrew B. <ab...@ee...> - 2001-12-20 22:28:24
|
Fantastic. it's now working. I need to pull in MSYS's make.exe, tee.exe, hostname.exe, date.exe, dirname.exe, and basename.exe to make my configure and build process work.=20 One flaw I had been having was using cygwin's ln -s to create a symlink, and well, DOS couldn't see it. I switched to mkdir and now everything seems to be working fine.=20 Ooh, one more thing. How do I take an MSYS POSIX path and add it to the windows PATH variable? I generate some bash scripts to run my development tools (the ones that I've built as part of this build process) and one of the things they need to do is augment the PATH (on Unix they augment LD_LIBRARY_PATH).=20 Andy > -----Original Message----- > From: Earnie Boyd [mailto:ear...@ya...] > Sent: Thursday, December 20, 2001 10:42 AM > To: Andrew Begel > Cc: MM List > Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 >=20 >=20 >=20 >=20 > Andrew Begel wrote: > >=20 > > On Thursday, December 20, 2001, at 05:09 AM, Earnie Boyd wrote: > >=20 > > > Hmm..., I think I see what you're driving at, you=20 > generated a Makefile > > > using MSYS and tried using Cygwin to execute the make=20 > command. That > > > isn't sane, and is like generating a Makefile on one=20 > system and taking > > > it to a different system to be used to build the package.=20 > It ain't > > > going to fly, no one should expect that it would. That is also > > > analogous to building a model airplane with the parts=20 > from one style of > > > airplane and the instructions from another. > > > > >=20 > > Yeah, now you've got it. So I used configure under an MSYS bash to > > generate my Makefile from my Makefile.in, and now what? All=20 > the paths > > that configure figured out where MSYS-style paths. Now, if=20 > there's no > > gmake that understands MSYS paths, I'm kinda stuck, no? All=20 > these great > > paths and nowhere to use them... > >=20 >=20 > No, you're not stuck. The POSIX paths get translated to native win32 > paths under MSYS. That's the point of MSYS. That's why it exists. >=20 > > There are two categories of translations that I'll need=20 > then, if I try > > to use gmake from MinGW or gmake from cygwin (more likely).=20 >=20 > POINT: You can't mix Cygwin and MSYS. There is a gmake=20 > distributed with > MSYS if you need that one use that _NOT_ the Cygwin make. >=20 > > I need to > > translate MSYS paths to DOS paths (if I use DOS tools, such as MinGW > > gcc.exe or a native XEmacs -batch to run some Lisp code) and also > > translate MSYS paths to cygwin paths (for unix-like tools,=20 > such as "sed" > > and "awk" and other nice utilities I use in my build process). > >=20 >=20 > Forget using Cygwin with MSYS, not possible. The point of MSYS is to > translate the paths on the arguments so that POSIXised paths get > translated to Win32 style paths without you needing to think=20 > about it.=20 > As for the nice unix utilities, what's missing from MSYS that you need > for building native MinGW applications? >=20 >=20 > > Without the translation, or the ability to run Makefiles in=20 > MSYS using > > an MSYS gmake, I don't see how MSYS could be useful at=20 > all.... Please > > correct my line of reasoning here, if I'm just not seeing=20 > the right big > > picture. > >=20 >=20 > I thought that you said you were able to use MSYS to build your > application. What exactly are you having a problem with? I'm lost in > your confusion. All that you should need do is >=20 > configure > make (if you want the MinGW version of make) or `gmake=20 > MAKE=3Dgmake' (for > the MSYS version of make). >=20 > Earnie. >=20 > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >=20 >=20 |
From: Earnie B. <ear...@ya...> - 2001-12-21 12:08:27
|
Andrew Begel wrote: > > Fantastic. it's now working. I need to pull in MSYS's make.exe, tee.exe, > hostname.exe, date.exe, dirname.exe, and basename.exe to make my > configure and build process work. > gmake == make and is already provided in 1.0.2. The others I can add in 1.0.3. > One flaw I had been having was using cygwin's ln -s to create a symlink, > and well, DOS couldn't see it. I switched to mkdir and now everything > seems to be working fine. > Unfortunately only the most high level pieces of MS understand it's own .lnk files. Perhaps a todo in the future could be to translate the symlink to the actual file and pass that on to the Win32 program. > Ooh, one more thing. How do I take an MSYS POSIX path and add it to the > windows PATH variable? I generate some bash scripts to run my > development tools (the ones that I've built as part of this build > process) and one of the things they need to do is augment the PATH (on > Unix they augment LD_LIBRARY_PATH). > One of: 1) Add it as a normal Win32 path, translations are done automagically for that variable. 2) Create a ~/.bashrc file that adds it in POSIX style. E.G.: export PATH=$PATH:/path/to/foo 3) Change the /etc/profile file that sets the PATH to add your path. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2001-12-19 16:20:27
|
Andrew Begel wrote: > > I took the test from configure (that failed on my computer) and ran it > manually: > > testgc.cc > ---------- > > /* Override any gcc2 internal prototype to avoid an error. */ > #ifdef __cplusplus > extern "C" > #endif > /* We use char because int might match the return type of a gcc2 > builtin and then its argument prototype would still apply. */ > char GC_malloc (); > int > main () > { > GC_malloc (); > ; > return 0; > } > > ------------ > > bash-2.04$ g++ -o testgc.exe -g -O2 -L /e/usr/misc/lib -v testgc.cc -lgc > > ^^^ note the space after -L arg > I tried this with a slightly different test because I don't have -lgc but, with the space between the -L and the path I can't get this to fail with the can't find library error. Unfortunately the line wrap for this happened right after the -L so I can't confirm this but it appears that your test which produced the below output didn't actually have the space. The verbose output leaves the space in the output but I can't see if that was there due to the line wrap. So, could you try again, please. Respond with the output of `uname -a', `mount', `g++ --version', and `ls -la /bin'. In the mean time I'll try a few other scenarios. Thanks, Earnie. > Reading specs from e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/specs > gcc version 2.95.3-6 (mingw special) > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cpp0.exe -lang-c++ -v > -iprefix e:\mingw\bin\../lib/gcc-lib/mingw32/2.95.3-6/ -D__GNUC__=2 > -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_WIN32 -DWIN32 > -D__WIN32__ -D__MINGW32__=1.0 -D__MSVCRT__ -DWINNT -D_X86_=1 > -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) > -D_stdcall=__attribute__((__stdcall__)) > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) > -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=1.0 > -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 > -D__stdcall=__attribute__((__stdcall__)) > -D___stdcall__=__attribute__((__stdcall__)) > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) > -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) > -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS > -D__OPTIMIZE__ -g -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 > -D__i386__ testgc.cc E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii > GNU CPP version 2.95.3-6 (mingw special) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3 > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include > > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/include > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/include > End of search list. > The following default directories have been omitted from the search > path: > /usr/local/mingw32/include > End of omitted list. > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cc1plus.exe > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii -quiet -dumpbase > testgc.cc -g -O2 -version -o > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > GNU C++ version 2.95.3-6 (mingw special) (mingw32) compiled by GNU C > version 2.95.3-6 (mingw special). > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\as. > exe -o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. > exe -Bdynamic -o testgc.exe > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../crt2.o -L > /e/usr/misc/lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 > -Le:/mingw/bin/../lib/gcc-lib > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o -lgc -lstdc++ > -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 > -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. > exe: cannot find -lgc > > Looks like msys didn't transform the path /e/usr/misc/lib into > e:/usr/misc/lib, even though it was its own argv. Hmm. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2001-12-19 19:37:12
|
I've uploaded a snapshot 1.0.3 snapshot dll to SourceForge msys-1.0.dll.20011219.bz2. You can download via: http://prdownloads.sf.net/mingw/msys-1.0.dll.20011219.bz2 ftp://prdownloads.sf.net/pub/sourceforge/mingw/msys-1.0.dll.20011219.bz2 Please give this a try to see if it eliminates the problem. The difference should be that -L/path/to/foo should now work as well as --myparam=/path/to/foo. Earnie. Andrew Begel wrote: > > I took the test from configure (that failed on my computer) and ran it > manually: > > testgc.cc > ---------- > > /* Override any gcc2 internal prototype to avoid an error. */ > #ifdef __cplusplus > extern "C" > #endif > /* We use char because int might match the return type of a gcc2 > builtin and then its argument prototype would still apply. */ > char GC_malloc (); > int > main () > { > GC_malloc (); > ; > return 0; > } > > ------------ > > bash-2.04$ g++ -o testgc.exe -g -O2 -L /e/usr/misc/lib -v testgc.cc -lgc > > ^^^ note the space after -L arg > > Reading specs from e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/specs > gcc version 2.95.3-6 (mingw special) > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cpp0.exe -lang-c++ -v > -iprefix e:\mingw\bin\../lib/gcc-lib/mingw32/2.95.3-6/ -D__GNUC__=2 > -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_WIN32 -DWIN32 > -D__WIN32__ -D__MINGW32__=1.0 -D__MSVCRT__ -DWINNT -D_X86_=1 > -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) > -D_stdcall=__attribute__((__stdcall__)) > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) > -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=1.0 > -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 > -D__stdcall=__attribute__((__stdcall__)) > -D___stdcall__=__attribute__((__stdcall__)) > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) > -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) > -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS > -D__OPTIMIZE__ -g -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 > -D__i386__ testgc.cc E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii > GNU CPP version 2.95.3-6 (mingw special) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3 > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include > > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/include > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/include > End of search list. > The following default directories have been omitted from the search > path: > /usr/local/mingw32/include > End of omitted list. > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\cc1plus.exe > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccWsaaaa.ii -quiet -dumpbase > testgc.cc -g -O2 -version -o > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > GNU C++ version 2.95.3-6 (mingw special) (mingw32) compiled by GNU C > version 2.95.3-6 (mingw special). > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\as. > exe -o E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccILaaaa.s > > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. > exe -Bdynamic -o testgc.exe > e:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../crt2.o -L > /e/usr/misc/lib -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 > -Le:/mingw/bin/../lib/gcc-lib > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib > -Le:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. > E:\DOCUME~1\ABEGEL~1.EEC\LOCALS~1\Temp\ccu4aaaa.o -lgc -lstdc++ > -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 > -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld. > exe: cannot find -lgc > > Looks like msys didn't transform the path /e/usr/misc/lib into > e:/usr/misc/lib, even though it was its own argv. Hmm. > > Andy > > > -----Original Message----- > > From: Earnie Boyd [mailto:ear...@ya...] > > Sent: Tuesday, December 18, 2001 4:01 AM > > To: Andrew Begel > > Cc: min...@li... > > Subject: Re: [Mingw-msys] Re: configure problems with MSYS 1.02 > > > > > > Andrew Begel wrote: > > > > > > On Sunday, December 16, 2001, at 09:11 AM, Earnie Boyd wrote: > > > > > > >> > > > >> However, when gcc tries to then find my library, it > > can't. According to > > > >> the config.log file, the pathname /e/usr/misc/lib was > > passed without > > > >> translation to the gcc command line, as > > -L/e/usr/misc/lib, which, of > > > >> course, my MinGW gcc (2.95.3-6) can't see. > > > >> > > > >> Is there a good way to rewrite this use of AC_CHECK_LIB > > to get the > > > >> posix->dos pathname translation to kick in? > > > >> > > > > > > > > Put a space between the -L and the path /e/usr/misc/lib. > > > > > > Sorry, I can't do that with gcc. There can be no spaces > > between -L and > > > its path, and -I and its path. > > > > > > > Huh, what version of GCC are you using? My version of GCC > > and all other > > versions I've used sure doesn't care. Modify the Makefile and put a > > space between the -L and the path to try it. Or wait for the > > release of > > the fix. > > > > Earnie. > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |