mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

On 3/30/2002 at 9:17 PM Andrew Begel wrote:

>There's something funny going on with sed in MSYS 1.0.6. 
>
>
>After some experimentation, it does appear to be completely related to
>the line endings in the file. If the source file has DOS line endings
>\r\n, sed doesn't properly find regexps that occur at the end of the
>line ($); if the source file has unix line endings, even MSYS' sed
>behaves properly. 
>

Hmm...  I'll have to take a look at the sed source and fix it for \r\n line
endings.  Thanks for the report.  In the meantime perhaps a preliminary
regexp of '\r$' would help.

I first thought you were going to report something I found yesterday with
the "XP For Home" OS and sed.  The following doesn't seem to want to work:
  `echo $COMSPEC | sed -e 's#\\#/#g#'`
The result is that I get the \ version returned.  I can make it work on the
command line but not in the evaluated script.  I'll have to research this
some more also.

Earnie.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

There's something funny going on with sed in MSYS 1.0.6.=20

I have a file that is getting processed by sed to turn trailing double
quotes into single quotes.=20

sample input file:

configure___ c_switch_system=3D "-mno-cygwin -Wno-sign-compare
-fno-caller-saves -DWIN32_NATIVE"=20


I run:

sed -e "s/[ 	]*=3D[ 	\"]*/=3D'/" -e "s/[ 	\"]*\$/'/" < myinputfile

The characters in the char class []'s are space, tab and double quote.
The first regexp correctly turns the above line into:

configure___ c_switch_system=3D'-mno-cygwin -Wno-sign-compare
-fno-caller-saves -DWIN32_NATIVE"=20

However, if I run the second regexp, in MSYS, I get the following:

configure___ c_switch_system=3D'-mno-cygwin -Wno-sign-compare
-fno-caller-saves -D
'IN32_NATIVE"

If I use Cygwin's sed (using Cygwin's bash), I get the correct output:

configure___ c_switch_system=3D'-mno-cygwin -Wno-sign-compare
-fno-caller-saves -DWIN32_NATIVE'

-----------------

After some experimentation, it does appear to be completely related to
the line endings in the file. If the source file has DOS line endings
\r\n, sed doesn't properly find regexps that occur at the end of the
line ($); if the source file has unix line endings, even MSYS' sed
behaves properly.=20

-----------------

Conclusion: It would help greatly if Microsoft decided to go with the
flow and remove \r's from all of their files and never generate them
again. ;)

Andy

=20

"Earnie Boyd" <ear...@ya...> writes:

> *********** BEGIN FORWARDED MESSAGE  ***********
> 
> On 3/29/2002 at 2:30 PM Al Holmes <ho...@sa...> wrote:
> 
> Please forgive me for writing on this subject.
> I've looked everywhere, but no insight.
> 
> "This program cannot be run in DOS mode."
> 
> All .exe files in the mingw bin directory give me this message.
> Windows 2000 from command prompt and also MSYS.
> 
> MinGW-1.1.tar.gz : Just downloaded from sourceforge.
> 
> MSYS is just what I need, but could use the development tools too!!

I'm using the MinGW-1.1.tar.gz distribution on Win2K (no sp) without
problems, neither with MSYS 1.0.x, nor normal Win2k shell nor Cygwin.

Please show _exactly_ the commands you enter since you launch the
shell, their output and the PATH environment variable setting so we
can see how to reproduce the problem.

Also, it would be helpful if you include the directory listing of the
mingw\bin directory (where gcc.exe is).

-- 
Oscar

Hi folks,

	The below sounds like something to do with configuration of Win2k.  Don't see this occur on NT4.  bash shell 
launches fine (1.06) and .exe, even within the msys tree run fine under NT4 without problems.

	Fortunately or unfortunately, I have no way to test it since I do not have Win2k.

	Paul G.

On 30 Mar 2002 at 13:17, Earnie Boyd wrote:

> 
> *********** BEGIN FORWARDED MESSAGE  ***********
> 
> On 3/29/2002 at 2:30 PM Al Holmes <ho...@sa...> wrote:
> 
> Please forgive me for writing on this subject.
> I've looked everywhere, but no insight.
> 
> "This program cannot be run in DOS mode."
> 
> All .exe files in the mingw bin directory give me this message.
> Windows 2000 from command prompt and also MSYS.
> 
> MinGW-1.1.tar.gz : Just downloaded from sourceforge.
> 
> MSYS is just what I need, but could use the development tools too!!
> 
> Many thanks if you choose to help me out.
> 
> Al Holmes.
> 
> 
> *********** END FORWARDED MESSAGE  ***********
> 
> 
> _________________________________________________________
> 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

*********** BEGIN FORWARDED MESSAGE  ***********

On 3/29/2002 at 2:30 PM Al Holmes <ho...@sa...> wrote:

Please forgive me for writing on this subject.
I've looked everywhere, but no insight.

"This program cannot be run in DOS mode."

All .exe files in the mingw bin directory give me this message.
Windows 2000 from command prompt and also MSYS.

MinGW-1.1.tar.gz : Just downloaded from sourceforge.

MSYS is just what I need, but could use the development tools too!!

Many thanks if you choose to help me out.

Al Holmes.


*********** END FORWARDED MESSAGE  ***********


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

SourceForge has recognized GeoCrawlers shortfalls and has created an
archive of it's own.  This archive is in beta testing but does have a
search function.  To access the this archive you can use
https://sourceforge.net/mailarchive/forum.php?forum_id=4855 for the
address.  If you forget this link you can access the link from the "Lists"
page on the SourceForge site at https://sourceforge.net/projects/mingw/.

Other search options I like are http://www.google.com and add msys or mingw
to the search criteria.

Earnie.

On 3/24/2002 at 8:45 PM William Trenker wrote:
Hello,

I'm new to Msys / Mingw  but not to Cygwin.  Is there any way to search the
Msys mailing list archive?  I'm having teething problems with Msys.

I've got Msys installed and running, I've got MingW as a subdirectory under
that.  I've made a dumb try.c that is just a main() with a printf.  It
compiles ok and the -o option gives me a try.exe with no errors.  But when
I go to run it (./try) I get "Permission Denied".  ls -l shows that all the
x permissions are set.

I wouldn't bother you folks with such a trivial question but I can't seem
to find a search option on the mailing list archive.

Thanks,
Bill



"The commandments of the LORD are right, bringing joy to the heart. The
commands of the LORD are clear, giving insight to life .. . . For this is
the love of God, that we keep His commandments. And His commandments are
not burdensome." (Psalm 19:8, 1John 5:3)    torahteacher.com

>On 3/25/2002 at 2:54 PM William Trenker wrote:
>I understand that make.exe is disabled in .../msys/1.0/bin in deference to
>gmake.exe.
>

Are you using version 1.0.6?  I've copied gmake.exe to make in the
msys\1.0\bin directory.  The scripts should find make without the .exe.  If
that's not happening or they suffix make with the .exe then it'll use the
MinGW-1.1 version of make.  You can either use `gmake MAKE=gmake' to
correct the problem or rename gmake.exe to make.exe.

>My confusion is how to tell scripts like ./configure from other distros
>how to run gmake instead of make.  For example, I'm trying to get the GNU
>M4 macro-preprocessor running in preparation for getting GNU Autoconf
>going.  When I run ./configure in the M4 distro directory it works just
>fine until somewhere it wants to call make, in which case I get a "Missing
>DLL" error when it tries to find make.exe in ..../msys/1.0/bin.  

Uh, m4 is distributed with MSys.  Why do you need to build it?

> If I edit
>the resulting Makefile script and set MAKE=gmake then it runs ok.  (Mind
>you, the resulting Makefile causes gmake to stop on an error because it
>can't fine sys/signal.h which M4 seems to need but that's a MingW
>question.)  Lot's of fun.
>

I can answer that here, it's not part of the runtime distribution because
it's POSIX and not ANSI.

>Since gmake is the MSys installation default I want to stay with it but I
>don't know how to make the ./configure from other packages work with
>gmake.  Hopefully, I don't have to edit each Makefile generated within
>MSys.
>

In my initial analysis, I did not know if the make.exe from MinGW-1.1 would
suffice or not.  So, I opted to deliver the MSYS version of make as gmake.
To help the scripts along you simply define the MAKE variable via the
command line, i.e.: gmake MAKE=gmake.  I've since concluded that the
MinGW-1.1 make isn't sufficient for MSys but still wanted to give those who
prefer to use that chance.  However, I'm probably being too lenient and
should just call gmake.exe make.exe and be done with it.

>It's probably an environment variable I'm missing.  Can someone point me
>in the right direction?
>

MAKE=gmake.

Earnie.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi folks,

	Have been having a similar problem.


> Travis Howell wrote:
> > > When I start MSYS 1.04 the rxvt shell starts up but I get the following
> > errors:
> > ': not a valid identifier
> > ': not a valid identifier
> > ': not a valid identifier
> > ': not a valid identifier
> > : command not found
> > : command not found
> > 'h: /etc/profile: line 20: syntax error near unexpected token `do
> > 'h: /etc/profile: line 20: `for i in /etc/profile.d/*.sh ; do
> > sh-2.04$
> > I really need to fix this soon.  It's the dreaded \r\n in the
> /etc/profile file.  
> 
> 1) Start up MSYS ignoring the above errors.  
> 2) cd /etc
> 3) tr -d '\r' < profile > profile.new
> 4) mv profile.new profile
> 5) Exit MSYS and restart.
> 
> > I'm using Windows XP Home Edition, installed MSYS 1.04 to main C:\ directory
> > ( C:\msys\1.0 ) and have altered the MSYS shortcut to start in the bin
> > directory.
> > My user id has a space in the name though, could that be part ? or any other
> > ideas ?
> > Also I have Cygwin installed (at C:\cygwin) if it makes any difference
> > It shouldn't make a difference.  Cygwin programs probably won't run
> under MSYS so I suggest modifying your PATH so that your MSYS
> environment won't find Cygwin.  You can modify PATH in the /etc/profile
> file or the ~/.bash_profile file.
> 
> Earnie.
> 


	This is a hack which does allow you to eliminate the errors noted above (the dreaded r/n/).

	

	Just add the following lines to your msys.bat file (edit), as follows:

...

set CYGWIN="nowinsymlinks notty notitle binmode nontsec nontea nosmbntsec"


<add the following lines>

rem ember this is a hack

set MSYS_bin="d:\msys\1.0\bin"
set MSYS_etc="d:\msys\1.0\etc"
set MSYS_temp=%MSYS_bin%;%MSYS_etc%

set PATH=%MSYS_temp%;%PATH%
cd %MSYS_etc%
tr -d '\r' <profile> profile.new
mv profile.new profile

cd %MSYS_bin%

rem end of hack

<end of add of lines>

rem ember to set the "Start in:" field of the shortcut.
...

###

	This does fix the problem before the bash shell is even started.

	Paul G.

Hi folks,

	Just was fooling around with $HOME variable.  Discovered it is not assigned, under NT4 if the %HOME% 
variable is not defined in system environment variables (user).  Taking it one step further, if the %HOME% variable is 
defined as something (say "d:/foo") then $HOME is left as "d:/foo" and the sh script  (profile) does not redefine it.  So, 
if you want to define $HOME you must have a %HOME% environment variable set to "" (null, or space).  If you do 
this, then $HOME is set to "/bin/".

	Is that the way it is supposed to be?

	Thanks,

		Paul G.

Hi folks,

	Just throwing in my tuppence.

	Before I go on, let me remind everyone, this mailing list is not for dealing with MSYS based problems.  MSYS 
is not Mingw, but it can use the Mingw development tools.  In other words, MSYS can "use" Mingw or any gcc that 
the developer might have a notion to use, it is not Mingw.  Mingw, out of the distro box, does not support automake or 
./config.  Nor was it ever designed to use automake or ./config.  Mingw is designed to be used through either 
cmd.exe or command.exe (DOS Console under Win32).  MSYS provides a unix-like shell, which allows the 
developer to build using automake and/or ./config processing through an rxvt interface.

	If you have any questions about MSYS, then those should be directed to the mingw-msys m/l.  Not this one.

	Besides, you are more likely to get a valid and authoratative response to these sorts of questions if you post 
them to the appropriate mailing list (min...@li...) then you are if you post such questions to 
the mingw-users list.

On 29 Mar 2002 at 18:34, Jean le Roux wrote:

> I solved the problem, but in a roundabout way.
> 
> Here's what I did, please suggest better aproaches if you have any.
> 
> > When I compile I get:
> > 
> > makefile:165: warning: overriding commands for target `.s.o'
> > makefile:162: warning: ignoring old commands for target `.s.o'
> > makefile:182: warning: overriding commands for target `.s.lo'
> > makefile:179: warning: ignoring old commands for target `.s.lo' c++
> > -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.cc c++
> > -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c common.cc /bin/sh
> > ../libtool --mode=link c++  -g -O2  -o isep-config.exe  main.o
> > common.o -lcrypto  ../libtool: cygpath: command not found c++ -g -O2
> > -o isep-config.exe main.o common.o  -lcrypto common.o: In function
> > `verify_own_mac(mac_t)':
> > //e/projects/multicast/isep/confsrc/common.cc:334: undefined
> > reference to `Netbios@4' common.o: In function `get_own_mac(mac_t &,
> > int)': //e/projects/multicast/isep/confsrc/common.cc:364: undefined
> > reference to `Netbios@4'
> > //e/projects/multicast/isep/confsrc/common.cc:393: undefined
> > reference to `Netbios@4' make: *** [isep-config.exe] Error 1
> > 
> > I include windows.h. I saw it includes nb30.h, but for surety's sake
> > I included nb30.h explicitely aswell.
> 
> The problem is not with the include.. the compiler would have caught
> "implicite declaration" of Netbios() in such a case. I realised this
> after some reflection and considderation as to _where_ the compilation
> goes wrong.
> 
> The problem is, however, with libnetapi32.a. It's not being linked in.
> I use the same configure.in and Makefile.am for compiling my projects
> in RH Linux 7.1 and Windoze NT. Under Linux the link line will only
> need -lcrypto, under windows it needs -lcrypto and -lnetapi32, due to
> the extra use of nb30.h.
> 
> Now, as of yet I know no clean cut way (or even a dirty one) of
> splitting my Makefile.am and/or configure.in to do different things
> under windows and linux. I can't go add -lnetapi32 to my Makefile.am's
> isep_config_LDADD =  -lcrypto .. this would cause the linux build to
> complain. 
> 
> Does anyone know how to test for windows and split functionality in a
> Makefile.am ?

	Have you thought about asking, somewhere in your make process, which OS you are actually building for?  
Mingw knows.  Linux probably has no way to truly know unless you want to play with cross-compiling.  It is appearing 
that you are dangerously close to cross-compiling problems (which really are not the focus of this mailing list except 
where existing cross-compiling hybrids, which use Mingw, are concerned.  MSYS does not fall under this category.).

	MSYS is MSYS, I must restate.  MSYS has some oddities to it that can not be reproduced using the dos 
console under Win32 because MSYS actually invokes a "shell" which is neither cmd.com or command.com, even 
though the "shell" invoked is launched from a dos console.  That "shell" is not the command console (win95 or other 
Windows).  The initiation of that shell is something you can fiddle with if you want, though I wouldn't suggest it unless 
you are ready for lots of headaches.

	Finally, take a look at the system variables you have available for the platform you are building for.  Some of 
those system variables tell make scripts which OS is actually running.  To cut another cookie, automake and (g)make 
are not the same thing.


	Paul G.

Hi,

	You are welcome to subscribe.  There are not any restrictions on the mailing list, outside the normal spam 
filters, to stop you from subscribing.  In fact, I would encourage you to subscribe, especially if you are expecting to do 
a lot of work with MSYS, as you have outlined below.

On 28 Mar 2002 at 18:04, GNUTeam wrote:

> Hi!!
> I am building a gcc toolchain for target sh-coff using mingw and msys.
> Previously I have successfully build a mingw toolchain for the same
> using canadian cross. I am a new user to msys and during building of
> the toolchain I am a stuck at the make all of binutils. Configure in
> binutils was successful. I am using binutils-2.11.2, gcc-3.0.3 and
> newlib-1.9.0 for my build. Following is the error I am getting - ...
> /bin/sh /home/kpit/src/binutils-2.11.2patch/bfd/../move-if-change
> tofiles ofiles touch stamp-ofiles /bin/sh ./libtool --mode=link gcc -W
> -Wall -O2  -o libbfd.la -rpath /usr/sh-coff3.0.3/lib -release
> GNUH8-v0201  archive.lo ar chures.lo bfd.lo cache.lo coffgen.lo
> corefile.lo format.lo init.lo libbfd.lo opncls.lo reloc.lo section.lo
> syms.lo targets.lo
>  hash.lo linker.lo srec.lo binary.lo tekhex.lo ihex.lo stabs.lo
>  stab-syms.lo
> dwarf2.lo `cat ofiles`
> ./libtool: cygpath: command not found
> mkdir .libs
> libtool: link: warning: undefined symbols not allowed in
> i386-pc-mingw32 shared libraries lib /OUT:.libs/libbfd.lib  archive.o
> archures.o bfd.o cache.o coffgen.o corefile.o format.o init.o libbfd.o
> opncls.o reloc.o section.o syms.o targets.o hash.o linker.o srec.o
> binary.o tekhex.o ihex.o stabs.o stab-syms.o dwarf2.o coff-sh.o
> cofflink.o cpu-sh.o ./libtool: lib: command not found make[3]: ***
> [libbfd.la] Error 127 make[3]: Leaving directory
> `/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd' make[2]:
> *** [all-recursive] Error 1 make[2]: Leaving directory
> `/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd' make[1]:
> *** [all-recursive-am] Error 2 make[1]: Leaving directory
> `/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd' make: ***
> [all-bfd] Error 2
> 
> Please guide me in this. Please CC to my address as I am not
> subscribed user of the list. Thanks in advance Regards Rekha Bhintade
> KPIT Infosystems Ltd Pune, INDIA

	Paul G.

Hi!!
I am building a gcc toolchain for target sh-coff using mingw and msys.
Previously I have successfully build a mingw toolchain for the same using
canadian cross. I am a new user to msys and during building of the toolchain
I am a stuck at the make all of binutils. Configure in binutils was
successful. I am using binutils-2.11.2, gcc-3.0.3 and newlib-1.9.0 for my
build.
Following is the error I am getting -
...
/bin/sh /home/kpit/src/binutils-2.11.2patch/bfd/../move-if-change tofiles
ofiles
touch stamp-ofiles
/bin/sh ./libtool --mode=link gcc -W -Wall -O2  -o libbfd.la -rpath
/usr/sh-coff3.0.3/lib -release GNUH8-v0201  archive.lo ar
chures.lo bfd.lo cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo
opncls.lo reloc.lo section.lo syms.lo targets.lo
 hash.lo linker.lo srec.lo binary.lo tekhex.lo ihex.lo stabs.lo stab-syms.lo
dwarf2.lo `cat ofiles`
./libtool: cygpath: command not found
mkdir .libs
libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32
shared libraries
lib /OUT:.libs/libbfd.lib  archive.o archures.o bfd.o cache.o coffgen.o
corefile.o format.o init.o libbfd.o opncls.o reloc.o
section.o syms.o targets.o hash.o linker.o srec.o binary.o tekhex.o ihex.o
stabs.o stab-syms.o dwarf2.o coff-sh.o cofflink.o
cpu-sh.o
./libtool: lib: command not found
make[3]: *** [libbfd.la] Error 127
make[3]: Leaving directory
`/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory
`/home/kpit/sh-coffbld3.0.3/build-binutils-2.11.2patch/bfd'
make: *** [all-bfd] Error 2

Please guide me in this. Please CC to my address as I am not subscribed user
of the list.
Thanks in advance
Regards
Rekha Bhintade
KPIT Infosystems Ltd
Pune, INDIA

On Tue, Mar 26, 2002 at 09:32:52PM -0500, Randy W. Sims wrote:
> 
> $ mount
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp on /tmp type user (binmode,noumount)
> y:\home on /home type user (binmode,noumount)
> y:\bin on /bin type user (binmode,cygexec,noumount)
> y:\bin on /usr/bin type user (binmode,cygexec,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)
> n: on /n type user (binmode,noumount)
> p: on /p type user (binmode,noumount)
> x: on /x type user (binmode,noumount)
> y: on / type user (binmode,noumount)
> y: on /y type user (binmode,noumount)
> y: on /usr type user (binmode,noumount)
> 
> You cannot mkdir over any of these mount points. (personally, I don't like
> having these hard coded, but it is something I can live with.)

Yes, indeed. Thanx. I was not sure where the heck the /usr was coming
from. Even if hardcoded (in the sense that it MUST me mounted), I
would have expected there to be dir for the mount point.

Now I understand the dir setup a lot better :)

-- 
Jean le Roux
Binary Entropy Catalyst

Wiker's Law:
	Government expands to absorb revenue and then some.

> Hmmm
>
> It seems I can't do
> $ mkdir /usr under msys
>
> I get a "file already exists" error.
>
> on a
>
> $ cd /usr
> $ ls
>
> I discover that /usr _is_ / ?!?
>
> Is this a bug in the new release or what ?

msys hard codes some mount points, which can be seen by typing mount from an
msys console

$ mount
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp on /tmp type user (binmode,noumount)
y:\home on /home type user (binmode,noumount)
y:\bin on /bin type user (binmode,cygexec,noumount)
y:\bin on /usr/bin type user (binmode,cygexec,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)
n: on /n type user (binmode,noumount)
p: on /p type user (binmode,noumount)
x: on /x type user (binmode,noumount)
y: on / type user (binmode,noumount)
y: on /y type user (binmode,noumount)
y: on /usr type user (binmode,noumount)

You cannot mkdir over any of these mount points. (personally, I don't like
having these hard coded, but it is something I can live with.)

MinGW can be placed anywhere so long as MinGW/bin is in your path. MinGW
finds it headers by relative paths, not any hard coded paths. (i.e. it looks
for ../include & ../mingw32/include, etc. I think the msys recommended way
though, is to install it to a directory named MinGW in msys/1.0. So that it
looks like

msys
  1.0
    bin
    doc
    etc
    home
    MinGW
      bin
      include
      info-html
      lib
      man
      mingw32
        bin
        include
        lib
          ldscripts
    uninstall

If installed like this, everything should work without modification as msys
set up the path as path/to/msys/bin:/path/to/msys/MinGW  - where
path/to/msys will be something like c:/msys/1.0/.

In my setup, I already had mingw setup with a lot of other gnu tools in a
directory modeled on the fhs std. I found a little utility at
sysinternals.com to create junctions on a ntfs5 file systems which are like
symbolic links. Using that I was able to map my /usr directory to
path/to/msys/mingw directory, which has worked perfectly so far. (note that
with this setup it is important that msys/bin comes before any other GNU
utilities which might conflict.)

HTH,
Randy W. Sims

On Wed, 27 Mar 2002 19:05:52 +0000, "Soren Andersen"
<sor...@sp...> said:

> I invite readers to go look at the article I posted to newsgroup
> awhile ago regarding the overall autotools build system. It is my
> passionate conviction that people need to be very careful of how much
> they put blind faith in autotools. But if your blood pressure is a
> problem right now perhaps skip it, because it's a rowdy posting not
> calculated to make friends for me everywhere (you've been warned!):
> --------- watch for long url wrapping ----- http://groups.google.com-
> /groups?q=%2BSoren+%2Bautomake&hl=en&selm=Xns91D2A2408EF9Dsorenngrp8-
> 9%4064.8.1.226&rnum=3
> ---------------------------------------------

Whoa, OK, that url does not work. Sorry, please try this one instead:
--------wrapwatch----------------
http://groups.google.com/groups?hl=en&selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226
-------endwrapwatch-------------

    Best, 
      Soren Andersen

On Wed, Mar 27, 2002 at 06:51:35PM +0000, Soren Andersen wrote:
> First of all, must admonish precision to deflect potential
> misunderstandings: that is *not* a 'configure' script but a
> configure.[in|ac] input file for autoconf. What gets produced by
> that is the ./configure script, which of course is very very long
> and will give you a major headache to read.

I stand corrected. I meant "configure.in", but I did not type
"configure.in". Sorry for any confusion caused.

> Now I am really confused. I thought you had changed your strategy
> and placed all your MinGW tree in a separate place?? Are you now
> mounting the root of that mingw tree to /mingw in the canonical
> msys manner (you haven't mentioned doing so): via in an entry in
> /etc/fstab?

No, again I find myself having to apologise. Im my quest to find the
missing headers (which has now come to a greatfull end) I tried
several tactics. One was to move the mingw stuff around (and out) of
the msys tree. I did this to see if path problems would
manifest/resolve. I a previous email i did state that my mingw was
move _outside_ msys. This did not solve any problems, and therefore I
moved it back _into_ msys, ie to /mingw from /c/mingw.

 
> And it nearly always *does the right thing* without intercession
> unless you are doing something paranormal like trying to run a
> cross-compiler!

Jeez.. not that brave yet :)

> I'm going to try and help by posting a lot of text here, sorry.
> This is how to diagnose your gcc universe; it consists of two
> commands that you can run. Text is blurted out into the console
> without wariness for wrapping so I've cleaned up the output in a
> text editor by fixing up wrong line breaks and inserting newlines
> to clarify the output -- yours won't look like this. I've inserted
> comments inside curly braces.

Thanx for the info. I'm not entirely comfortable around gcc yet, and
some of these "tricks" still elude me. "RTFM" I hear the masses
shout, "RTFM"... I'm getting to it :) 

> Jean, I just cannot help but feel that somehow you are outsmarting
> yourself. 

seems that I did, since the problem was with my configure.in all
along :(, and not with gcc/msys at all. But it is resolved now.

Thanx you very much for your patience and guidance in resolving this.
-- 
Jean le Roux
Binary Entropy Catalyst

On Wed, 27 Mar 2002 20:43:59 +0200, "Jean le Roux" <je...@in...> said:
> On Wed, Mar 27, 2002 at 08:29:48PM +0200, Jean le Roux wrote:
> > Now the question, why does it not stick to the compiler it found in
> > the first place ?
> 
> Hmm, i did an autoscan for the project, and merged the results with
> my configure.in. Then it picked up the header files, becasue it was
> using the correct compiler.
> 
> the difference in the two is basically
> 
> AC_PROG_CXX -->i had this
> these were added
> AC_PROG_AWK
> AC_PROG_CC
> AC_PROG_INSTALL
> AC_PROG_LN_S
> 
> Seems I'm sorted, for now :)

Good! Yes, it matters in some very important cases, the precedence of calling autoconf macros, and this is one of the big gotchas. One needs to call AC_PROG_CC very early on before almost any other checks. Other checks will depend on the result of that one and it is a B I G weakness of autoconf that it won't correctly inform the user about the early failure in normal screen output.

I invite readers to go look at the article I posted to newsgroup awhile ago regarding the overall autotools build system. It is my passionate conviction that people need to be very careful of how much they put blind faith in autotools. But if your blood pressure is a problem right now perhaps skip it, because it's a rowdy posting not calculated to make friends for me everywhere (you've been warned!):
--------- watch for long url wrapping -----
http://groups.google.com/groups?q=%2BSoren+%2Bautomake&hl=en&selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226&rnum=3
---------------------------------------------

      Best,
      Soren Andersen

On Wed, 27 Mar 2002 20:07:21 +0200, "Jean le Roux" <je...@in...> said:


> When I run a simple little configure script for a 'hello world'
> program:
> 
>       dnl Process this file with autoconf to produce a configure
>       script.
>       AC_INIT(x.cc)
[snip]

First of all, must admonish precision to deflect potential misunderstandings: that is *not* a 'configure' script but a configure.[in|ac] input file for autoconf. What gets produced by that is the ./configure script, which of course is very very long and will give you a major headache to read.

> I get :
>       creating cache ./config.cache
>       checking for a BSD compatible install... /bin/install -c
>       checking whether build environment is sane... yes
>       checking whether make sets ${MAKE}... yes
>       checking for working aclocal... missing
>       checking for working autoconf... missing
>       checking for working automake... missing
>       checking for working autoheader... missing
>       checking for working makeinfo... found
>       checking for c++... c++
>       checking whether the C++ compiler (c++  ) works... yes
>       checking whether the C++ compiler (c++  ) is a cross-compiler...
>       no
>       checking whether we are using GNU C++... yes
>       checking whether c++ accepts -g... yes
>       checking how to run the C preprocessor... /lib/cpp
>       checking for ANSI C header files... no
>       checking for sys/stat.h... no
>       checking for sys/types.h... no
>       checking for sys/wait.h... no
>       checking for sys/time.h... no
>       checking for sys/ioctl.h... no
>       checking for windows.h... no
>       checking for working const... no
>       checking for size_t... no
>       checking whether time.h and sys/time.h may both be included... no
>       updating cache ./config.cache
>       creating ./config.status
>       creating Makefile
> 
> Why is it not finding my headers?
> 
> some other (possibly relevant) info
> My MinGW-1.1 is placed at /mingw

Now I am really confused. I thought you had changed your strategy and placed all your MinGW tree in a separate place?? Are you now mounting the root of that mingw tree to /mingw in the canonical msys manner (you haven't mentioned doing so): via in an entry in /etc/fstab?

The basic answer to the question you keep asking is the same as it was before (in a previous answer i made): the search paths for gcc to find its headers are *hardcoded* into the executable (the gcc compiler driver that runs all its various subpieces). And it nearly always *does the right thing* without intercession unless you are doing something paranormal like trying to run a cross-compiler!

I'm going to try and help by posting a lot of text here, sorry. This is how to diagnose your gcc universe; it consists of two commands that you can run. Text is blurted out into the console without wariness for wrapping so I've cleaned up the output in a text editor by fixing up wrong line breaks and inserting newlines to clarify the output -- yours won't look like this. I've inserted comments inside curly braces.

===================================

$ /h/mingw/bin/gcc --print-search-dirs
{my MinGW is located at H:/mingw}
install:
/mingw/lib/gcc-lib/mingw32/2.95.3-5/
{Don't be deceived; this ISN'T relevant, finally}

programs:
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/
/mingw/lib/gcc-lib/mingw32/
/usr/lib/gcc/mingw32/2.95.3-5/
/usr/lib/gcc/mingw32/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/bin/mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/bin/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/bin/mingw32/2.95.3-5/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/bin/
{See all the entries? Many of these are NOT relevant to our Win32 setup.}

libraries:
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/
/usr/lib/gcc/mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/lib/mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/lib/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/lib/mingw32/2.95.3-5/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/lib/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../mingw32/2.95.3-5/
h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../mingw32/2.95.3-5/
/mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../
/lib/mingw32/2.95.3-5/
/lib/
/usr/lib/mingw32/2.95.3-5/
/usr/lib/
{same as above -- see that some are Win32 paths and some aren't?
  the only ones that really matter to us are the Win32 paths.}


$ touch foo.c && gcc -v -c foo.c; rm -f foo.c
Reading specs from h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/specs
gcc version 2.95.3-5 (mingw special)
[snip]


#include <...> search starts here:
 h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../include
 h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/../../../../mingw32/include
 h:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-5/include
End of search list.

The following default directories have been omitted from the search path:
 /mingw/lib/gcc-lib/mingw32/2.95.3-5/../../../../include/g++-3
 /usr/local/mingw32/include
End of omitted list.

{SEE?!? GCC does the right thing! The only things that are finally searched for included system headers and the compiler's own version-specific special stuff are the right ones: the Win32 paths starting with h: on my system!}

===================================

Jean, I just cannot help but feel that somehow you are outsmarting yourself. Try this above diagnostic strategy *first* and then work from there. If it fails you completely then I offer you these environmental things to investigate but I *emphasize* that it should NOT be necessary to set any off these normally and you do so at your risk of unpleasant side-effects!

GCC_EXEC_PREFIX=[driveletter:?]/[something]/lib/gcc-lib/
COMPILER_PATH=[driveletter:?]/[something]/architecture/bin
LIBRARY_PATH=[driveletter:?]/[something]/lib
C_INCLUDE_PATH=[driveletter:?]/[something]/include

  Regards,
     Soren Andersen

On Wed, Mar 27, 2002 at 08:29:48PM +0200, Jean le Roux wrote:
> Now the question, why does it not stick to the compiler it found in
> the first place ?

Hmm, i did an autoscan for the project, and merged the results with
my configure.in. Then it picked up the header files, becasue it was
using the correct compiler.

the difference in the two is basically

AC_PROG_CXX -->i had this
these were added
AC_PROG_AWK
AC_PROG_CC
AC_PROG_INSTALL
AC_PROG_LN_S

Seems I'm sorted, for now :)

Thanx again all who contributed!
-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

Don't speak about Time, until you have spoken to him.

On Wed, Mar 27, 2002 at 05:56:59PM +0000, Soren Andersen wrote:

> You need to forensically not believe what ./configure *seems* to be
> telling you and find out what is really happening in a doubting and
> microscopic way.

I went through config.log and found this juicy bit:

configure:784: checking for c++
configure:816: checking whether the C++ compiler (c++  ) works
configure:832: c++ -o conftest    conftest.C  1>&5
configure:858: checking whether the C++ compiler (c++  ) is a cross-compiler
configure:863: checking whether we are using GNU C++
configure:891: checking whether c++ accepts -g
configure:940: cc -c   conftest.c 1>&5
./configure: cc: command not found
configure: failed program was:
#line 932 "configure"
#include "confdefs.h"
#include <stdlib.h>
...
#include "confdefs.h"
#include <stdlib.h>
extern "C" void std::exit (int); using std::exit;
int main() {
exit (42);
; return 0; }
configure:940: cc -c   conftest.c 1>&5
./configure: cc: command not found
configure: failed program was:
#line 932 "configure"
...

Notice that it switches from a happy c++ for the compiler, to
a not-so-happy cc. this causes all the header tests to fail.

Today I lived and learned :)

Now the question, why does it not stick to the compiler it found in
the first place ?

-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

Ah, Soren Andersen beat me to the punch on this.. please take the 
mail as purely informational.

Thanx Soren!
-- 
Jean le Roux
Binary Entropy Catalyst

Hi all

Thanx for all the mails and help so far, but my problem is still not
resolved :)

When I run a simple little configure script for a 'hello world'
program:

      dnl Process this file with autoconf to produce a configure script.
      AC_INIT(x.cc)

      AM_INIT_AUTOMAKE(MINGWTEST, 0.0.0)

      dnl Checks for programs.
      AC_PROG_CXX

      dnl Checks for header files.
      AC_HEADER_STDC
      AC_CHECK_HEADERS(sys/stat.h sys/types.h sys/wait.h sys/time.h
      sys/ioctl.h)
      AC_CHECK_HEADERS(windows.h)

      dnl Checks for typedefs, structures, and compiler characteristics.
      AC_C_CONST
      AC_TYPE_SIZE_T
      AC_HEADER_TIME

      dnl Checks for library functions.

      AC_OUTPUT(Makefile)

I get :
      creating cache ./config.cache
      checking for a BSD compatible install... /bin/install -c
      checking whether build environment is sane... yes
      checking whether make sets ${MAKE}... yes
      checking for working aclocal... missing
      checking for working autoconf... missing
      checking for working automake... missing
      checking for working autoheader... missing
      checking for working makeinfo... found
      checking for c++... c++
      checking whether the C++ compiler (c++  ) works... yes
      checking whether the C++ compiler (c++  ) is a cross-compiler... no
      checking whether we are using GNU C++... yes
      checking whether c++ accepts -g... yes
      checking how to run the C preprocessor... /lib/cpp
      checking for ANSI C header files... no
      checking for sys/stat.h... no
      checking for sys/types.h... no
      checking for sys/wait.h... no
      checking for sys/time.h... no
      checking for sys/ioctl.h... no
      checking for windows.h... no
      checking for working const... no
      checking for size_t... no
      checking whether time.h and sys/time.h may both be included... no
      updating cache ./config.cache
      creating ./config.status
      creating Makefile

Why is it not finding my headers?

some other (possibly relevant) info
My MinGW-1.1 is placed at /mingw
My /etc/profile is (due to the above) unchanged
My NT environment contains no mention of MSys or MinGW

make -v gives:
      GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
      Built for i386-pc-msys
      Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
      	Free Software Foundation, Inc.
      This is free software; see the source for copying conditions.
      There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
      PARTICULAR PURPOSE.

      Report bugs to <bug...@gn...>.

gcc-v gives:
      Reading specs from C:/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/specs
      gcc version 2.95.3-6 (mingw special)


Hope someone out there can sched some light on this for me

-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
		-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

On Wed, 27 Mar 2002 12:03:18 +0200, "Jean le Roux" <je...@in...>
said:
> Thanx for all the help so far guys, but I still have pain :(
> 
> I whacked all the installed stuff and redid from start, this time
> keeping MinGW in a separate dir thans msys
> eg /c/MinGW and /c/msys/1.0/
> I added the /c/MinGW/bin to my PATH in /etc/profile

> Next I ran ./configure on my project. All seems to go ok, except
> that it says it cant find ANSI C headers (or any other headers for
> that matter)
 
> Also, the configure test for mingw32 environment comes up negative,
> this does not feel right.

You must be getting very frustrated, and I sympathize. Wish I could
offer easier solution to you. But these are very complex pieces of
software.

The first thing I want to note is that your previously reported
troubles with perl (your perl being ActivePerl compiled for you at
ActiveState) are I think also exactly what bothered me in the past too.
A suggestion I have is that building your own perl from source might be
something to look at to save yourself compatibility related troubles in
the future. Such an "msys perl", analogous to Cygwin Perl (and in fact
I would take the Cygwin port as the template from which to draw
insights about how to achieve such a build on msys), would of course
"know about" msys paths.

Secondly, I need to warn you not to make assumptions that you know what
is going on with './configure'. You diagnose below that it's "msys'
fault" -- that gcc isn't finding its system headers because of the way
msys is set up. While I am not saying this isn't true, I can offer the
suggestion that you dig in and read your {./config.log} file *very*
carefully right now to trace *precisely* what went wrong on your
previous configure attempt. See, ./configure has a way of failing tests
just like what you describe -- cannot report ANSI headers and cannot
find that its MinGW, for two instances -- when it has *already failed
another action* beforehand (probably a running of gcc somehow) in that
./configure session. This is a weakness I have noted in the ./configure
-slash- autotooled build system.

On such occasions I have gone in and read the log carefully and
discovered that, most often, gcc was being (quietly, secretly) passed
options on its commandline by ./configure, things like '-lfoobar' etc.,
that were causing it to too-quietly fail certain tests. Instead of
croaking cleanly and in a timely way, what ./configure will often do in
a case like this is to "accumulate" the error-condition as it goes on
noisily claiming to be trying later tests. You need to forensically not
believe what ./configure *seems* to be telling you and find out what is
really happening in a doubting and microscopic way.

> How do I check the search priority for gcc? Do I need to add the
> /c/MinGW/include to my PATH aswell?

> I did a 
> $ ./configure --includedir=/c/MinGW/include
> aswell. no change.

I don't know. But one thing I'll note is that i am not having to be as
picky in my general commands in msys but instead mostly specify paths
in Win32-style, so instead of above "/c/MinGW/include" I might usually
just say "C:/MinGW/include" and things work just fine. msys makes the
translations it needs to make when it needs to make them -- it mostly
just works without one trying to outsmart it so much (OTOH the
previously-discussed case of ActivePerl is a special instance; the same
kind of issues would be troublesome in various ways if you were a
Cygwin user trying to work with ActivePerl, for ex.). If this wasn't
the case I don't think msys would be of very much value; if software it
uses cannot grasp a Win32-style path then what would be the point.


   Good Luck,
      Soren Andersen

On Wed, Mar 27, 2002 at 06:38:36PM +0200, Emre Turkay wrote:
> make -v gives following (in the directory that Im trying to compile 
> $ make -v
> GNU Make version 3.77, by Richard Stallman and Roland McGrath.
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98
>         Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.

> $ ./make.exe -v
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> Built for i386-pc-msys
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
>         Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.

I would verture to say that the make you are calling is the wrong
one (wherever/make.exe vs bin/make.exe).

You need to call the msys one most likely, so that it can translate
the paths properly. It looks like the 'make' you are calling is the one
supplied with Dev-C++, not MSys's.

-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

I can't seem to bring myself to say, "Well, I guess I'll be toddling along."
It isn't that I can't toddle.  It's that I can't guess I'll toddle.
		-- Robert Benchley

On Wed, Mar 27, 2002 at 06:11:50PM +0200, Emre Turkay wrote:
> I have installed Dev-C++ and using mingw compiler coming with it.  
> gcc --version tells 2.95.2
> Dev-C++ is installed in C:\Dev-C++ directory; gcc and make is in;
> C:\Dev-C++\bin directory.

> Because /c/Dev-C++/Bin/ is coming before /bin; the make.exe must be from
> mingw package. 

do a "make -v" and see what the "Built for {foo}" says, that will tell
us which one is being used.

> I also think that is a path problem; does anybody know if the stlport
> lib. requires includes/libs of the installed compiler ?  If this is the
> case, I think it cannot find those files...

It should, it is building a lib to be used when linking with that
compiler. I read in the INSTALL file that one can customise the
STLport to implement iostreams as wrappers for existing iosteam
classes.. that would definitely imply the need for a set of cimplier
headers.

Where in all this do you fir MSys in ? It looks like you simply use
the mingw-gcc and such, with Dev-C++ (with which i'm not familiar
with). 

-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

There are many intelligent species in the universe, and they all own cats.