Re: [Mingw-users] error when using autoconf 2.60 or 2.61 with MSYS/MinGW

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Mingw-users] error when using autoconf 2.60 or 2.61 with MSYS/MinGW

Keith MARSHALL
Continuing a discussion originating on MinGW-Users:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/22580

Vincent Torri wrote:

> I use MSYS-1.0.11 CORE (from snapshot)...
>
> I've installed MSYS DTK 1.0.1
>
> I've just installed autoconf 2.61 in /usr/local. I get the same
> error. For example, when compiling automake 1.10:
>
> checking whether autoconf is installed... yes
> checking whether autoconf works... no
>
> the config.log file reports:
>
> configure:2310: checking whether autoconf is installed
> configure:2315: eval autoconf --version
> autoconf (GNU Autoconf) 2.61
> Copyright (C) 2006 Free Software Foundation, Inc.
> ...
> configure:2318: $? = 0
> configure:2326: result: yes
> configure:2336: checking whether autoconf works
> configure:2343: cd conftest && eval autoconf -o /dev/null conftest.ac
> /usr/local/bin/autoconf:
> /home/vincent/automake-1.10/conftest/D:/msys/1.0/local/bin/autom4te:
>  No such file or directory
> /usr/local/bin/autoconf: exec:
> /home/vincent/automake-1.10/conftest/D:/msys/1.0/local/bin/autom4te:
>  cannot execute: No such file or directory
> configure:2346: $? = 126
> configure:2355: result: no
>
> If I just run autoconf in a lib I want to compile:
>
> /usr/local/bin/autoconf:
> /home/vincent/libdvi/D:/msys/1.0/local/bin/autom4te:
>  No such file or directory
> /usr/local/bin/autoconf: exec:
> /home/vincent/libdvi/D:/msys/1.0/local/bin/autom4te:
>  cannot execute: No such file or directory

I certainly cannot reproduce this; I just did

  $ cd tmp

  $ pwd
  /home/keith/tmp

  $ file `which autoconf`
  /usr/local/bin/autoconf: Bourne shell script text executable

  $ file `which autom4te`
  /usr/local/bin/autom4te: perl script text executable

  $ file `which perl`
  /bin/perl.exe: PE executable for MS Windows (console) Intel 80386

  $ perl --version

  This is perl, v5.6.1 built for msys

  Copyright 1987-2001, Larry Wall
  ...

  $ autoconf --version
  autoconf (GNU Autoconf) 2.61
  Copyright (C) 2006 Free Software Foundation, Inc.
  ...

  $ echo AC_INIT > configure.ac

  $ autoconf

  $ ls
  autom4te.cache  configure  configure.ac

Note that this exactly as I would expect, indicating normal operation.
If I explicitly move autom4te out of the way...

  $ (cd `dirname \`which autom4te\`` && mv autom4te autom8)

  $ autoconf
  /usr/local/bin/autoconf: line 582: /usr/local/bin/autom4te:
   No such file or directory
  /usr/local/bin/autoconf: line 582: exec: /usr/local/bin/autom4te:
   cannot execute: No such file or directory

  $ (cd `dirname \`which autom8\`` && mv autom8 autom4te)

...then autoconf does fail, as expected, but I still see the POSIX
style path names in the error messages.

> Note that autoconf 2.59 has no problem.

This is even more mysterious.  It appears that you have identified a
possible cause...

> Cesar Strauss wrote:
>> How did you invoke the configure script?
>>
>> I saw this problem in the past, when I used DOS paths in the configure
>> line (--prefix=`cd /mingw && pwd -W`). A solution was to use the POSIX
>> path (--prefix=/mingw). I believe this is because autoconf is
>> interpreted by perl, which is a MSYS application, and has POSIX
>> semantics.
>
> I think that I have found the problem. I have not mentioned that I used
> a mingw port made my myself (with portmaker), and the configure script
> is called like that :
>
> CONFIGURE_OPTIONS=${CONFIGURE_OPTIONS-"--prefix='`win32path
${PREFIX}`'"}
>
> So it is certainly the problem.

It certainly seems plausible;  however, when I originally built autoconf
2.60, I had

  ac_default_prefix=`cd /usr/local && pwd -W`

in my config.site file.  This would have identically the same effect as
that `CONFIGURE_OPTIONS` setting, (`win32path is a function, which if
PREFIX is set to /usr/local, effectively expands to that same command).

> when I compile from source, there is no problem.

...this would seem to confirm the hypothesis, that this is indeed the
problem.

> sorry for having bothering you

No bother, and the discussion has certainly been useful; no need to
apologise.

> and having not mentioned that i was using a mingw port.

Well, we all dismiss some things as unlikely to be relevant, until
enlightenment dawns.  Note how I've formulated that CONFIGURE_OPTIONS
setting; it will only take effect if CONFIGURE_OPTIONS has not been
previously assigned a value.  For your mingwPORT, you could add

  CONFIGURE_OPTIONS='--prefix=${PREFIX}'

to mingwPORT.ini, (note the single quotes), to preserve the POSIX
style path for the PREFIX assignment in configure.  (If that doesn't
work, I want to know, please, because this is a feature of mingwPORT
which I'm still developing).

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: [Mingw-users] error when using autoconf 2.60 or 2.61 with MSYS/MinGW

Vincent Torri-2


On Tue, 8 May 2007, Keith MARSHALL wrote:

>> CONFIGURE_OPTIONS=${CONFIGURE_OPTIONS-"--prefix='`win32path
> ${PREFIX}`'"}
>>
>> So it is certainly the problem.
>
> It certainly seems plausible;  however, when I originally built autoconf
> 2.60, I had
>
>  ac_default_prefix=`cd /usr/local && pwd -W`
>
> in my config.site file.  This would have identically the same effect as
> that `CONFIGURE_OPTIONS` setting, (`win32path is a function, which if
> PREFIX is set to /usr/local, effectively expands to that same command).

I've just tried on my computer:

  cd /usr/local && pwd -W

the result is:

D:/msys/1.0/local

win32path returns indeed the value of pwd -W, so the problem is that
function.

I don't really know the options of pwd (I have found no doc about the
MSYS version), but it seems that there is 3 available parameters : P, L
and W. Here are the results on my computer when run in /usr/local:

vincent@TORRI /usr/local
$ pwd -P
/usr/local

vincent@TORRI /usr/local
$ pwd -L
/usr/local

vincent@TORRI /usr/local
$ pwd -W
D:/msys/1.0/local

Hope this helps

Vincent Torri

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: [Mingw-users] error when using autoconf 2.60 or 2.61 with MSYS/MinGW

Keith MARSHALL




Hi Vincent,

Thanks for your continuing attention to this; much appreciated.

Vincent Torri wrote, quoting me:

>>  ac_default_prefix=`cd /usr/local && pwd -W`
>>
>> in my config.site file.  This would have identically the same
>> effect as that `CONFIGURE_OPTIONS` setting, (`win32path is a
>> function, which if PREFIX is set to /usr/local, effectively
>> expands to that same command).
>
> I've just tried on my computer:
>
>   cd /usr/local && pwd -W
>
> the result is:
>
> D:/msys/1.0/local
>
> win32path returns indeed the value of pwd -W, so the problem is
> that function.

The problem is *not* the win32path function -- it does exactly what
it is intended to.

The problem is with the assumption that a configure script running
under MSYS should always encode $prefix using native Woe32 semantics.
In the majority of cases, that is the recommended behaviour, and the
*default* behaviour in mingwPORT is to set it thus.

Unfortunately, there are some cases where this default is *not*
appropriate; building the autotools appears to be one such case.

In such cases, the mingwPORT *must* override the default assignment
of `CONFIGURE_OPTIONS', to ensure that POSIX semantics are preserved
in the assignment of $prefix.  The problem is that your mingwPORT
didn't do this.

This is not intended as a criticism of anything you've done; this
functionality is still very much under development, and is, as yet,
undocumented -- you surely could not have been expected to know of
this requirement.  Your work, and in particular your reporting of
the problems you encounter, is extremely valuable in helping us to
refine the mingwPORT framework; that's why I'm particularly keen
to know if overriding the assignment of `CONFIGURE_OPTIONS', by
setting it explicitly in mingwPORT.ini as

  CONFIGURE_OPTIONS='--prefix=$PREFIX'

or maybe it needs extra quoting

  CONFIGURE_OPTIONS='--prefix="$PREFIX"'

does actually work as I expect, and resolves the issue for your
mingwPORT of autoconf-2.61.

> I don't really know the options of pwd (I have found no doc about the
> MSYS version), but it seems that there is 3 available parameters : P,
> L and W.

It's built into the shell, and accessible via the `help' command:

  $ help pwd
  pwd: pwd [-LPW]
     Print the current working directory.  With the -P option, pwd
     prints the physical directory, without any symbolic links; the
     -L option makes pwd follow symbolic links; the -W option makes
     pwd print the Win32 value of the physical directory.

BTW, there are two reasons why I use a `win32path' function, rather
than simply invoking `pwd -W' directly:

1) `cd /path/for/prefix && pwd -W' fails, if `/path/for/prefix'
   represents a directory which has yet to be created; the
   function `win32path' catches that, and recursively decomposes
   the path until it finds an initial prefix for which `pwd -W'
   succeeds, then reassembles the full path, relative to the
   result of that translation.

2) When I'm developing mingwPORTs, working on my GNU/Linux box,
   I can redefine `win32path' in a mingwPORT.site file, so that
   I can map a virtual Woe32 file system, for use by the port
   code, without needing to modify that code itself.

Regards,
Keith.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: error when using autoconf 2.60 or 2.61with MSYS/MinGW

Vincent Torri-2

Hey

> The problem is *not* the win32path function -- it does exactly what
> it is intended to.

ok

> The problem is with the assumption that a configure script running
> under MSYS should always encode $prefix using native Woe32 semantics.
> In the majority of cases, that is the recommended behaviour, and the
> *default* behaviour in mingwPORT is to set it thus.
>
> In such cases, the mingwPORT *must* override the default assignment
> of `CONFIGURE_OPTIONS', to ensure that POSIX semantics are preserved
> in the assignment of $prefix.  The problem is that your mingwPORT
> didn't do this.

> that's why I'm particularly keen
> to know if overriding the assignment of `CONFIGURE_OPTIONS', by
> setting it explicitly in mingwPORT.ini as
>
>  CONFIGURE_OPTIONS='--prefix=$PREFIX'
>
> or maybe it needs extra quoting
>
>  CONFIGURE_OPTIONS='--prefix="$PREFIX"'
>
> does actually work as I expect, and resolves the issue for your
> mingwPORT of autoconf-2.61.

I've tried both It fixes the problem. Here is, for example, my
mingwPORT.ini:

PACKAGE=autoconf
VERSION=2.61
ARCHIVETYPE=tar.bz2
ARCHIVEFILE=autoconf-2.61.tar.bz2
ARCHIVEPATH=/tmp
ARCHIVEHOME=http://www.gnu.org
DOWNLOADURI=http://ftp.gnu.org/gnu/autoconf
SRCDIR=${SRCROOT-"$HOME/src"}/autoconf-2.61
BUILDDIR=./bld
PREFIX=${PREFIX-"/mingw"}
CONFIGURE_OPTIONS='--prefix="$PREFIX"'
CFLAGS="-O3 -s -mms-bitfields -march=`uname -m`"
CXXFLAGS="$CFLAGS"

autoconf behaves flawlessly and I can compile automake.

the automake port also needs that modification

If you think that these ports are worth being on sourceforge, I can make a
tarball for you.

I'm also planning to make a port of gettext, with the patch mentioned
earlier on the list.

regards

Vincent Torri

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: error when using autoconf 2.60 or 2.61with MSYS/MinGW

Keith Marshall-3
On Wednesday 09 May 2007 19:28, Vincent Torri wrote:

> > I'm particularly keen
> > to know if overriding the assignment of `CONFIGURE_OPTIONS', by
> > setting it explicitly in mingwPORT.ini as
> >
> >  CONFIGURE_OPTIONS='--prefix=$PREFIX'
> >
> > or maybe it needs extra quoting
> >
> >  CONFIGURE_OPTIONS='--prefix="$PREFIX"'
> >
> > does actually work as I expect, and resolves the issue for your
> > mingwPORT of autoconf-2.61.
>
> I've tried both It fixes the problem.

Good to know, thanks.  I think the latter form, as you've used in the
example below, is safer;  who knows when a user may try to set PREFIX
to some path including spaces, crazy as that idea may be :-)

> Here is, for example, my
> mingwPORT.ini:
>
> PACKAGE=autoconf
> VERSION=2.61
> ARCHIVETYPE=tar.bz2
> ARCHIVEFILE=autoconf-2.61.tar.bz2
> ARCHIVEPATH=/tmp
> ARCHIVEHOME=http://www.gnu.org
> DOWNLOADURI=http://ftp.gnu.org/gnu/autoconf
> SRCDIR=${SRCROOT-"$HOME/src"}/autoconf-2.61
> BUILDDIR=./bld
> PREFIX=${PREFIX-"/mingw"}
> CONFIGURE_OPTIONS='--prefix="$PREFIX"'
> CFLAGS="-O3 -s -mms-bitfields -march=`uname -m`"
> CXXFLAGS="$CFLAGS"
>
> autoconf behaves flawlessly and I can compile automake.

Excellent.

> the automake port also needs that modification
>
> If you think that these ports are worth being on sourceforge, I can
> make a tarball for you.

That would be good.  When you are ready, please post them on the tracker
at: https://sourceforge.net/tracker/?group_id=2435&atid=752210

> I'm also planning to make a port of gettext, with the patch mentioned
> earlier on the list.

You might like to review one that is already waiting for consideration:
https://sourceforge.net/tracker/index.php?func=detail&aid=1581041&group_id=2435&atid=752210

If that could benefit from the patch you mention, then you could attach
an update to the outstanding item.

Thanks,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: error when using autoconf 2.60 or 2.61with MSYS/MinGW

Vincent Torri-2

Hey

On Sat, 12 May 2007, Keith Marshall wrote:

>> If you think that these ports are worth being on sourceforge, I can
>> make a tarball for you.
>
> That would be good.  When you are ready, please post them on the tracker
> at: https://sourceforge.net/tracker/?group_id=2435&atid=752210

it is done. Maybe someone should test them, to see if i've done a mistake
or not.

regards

Vincent Torri

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

border of the terminal showed when using UpdateLayeredWindow

Vincent Torri-2
In reply to this post by Keith MARSHALL

Hey,

I'm using UpdateLayeredWindow() to make a window having a shape. When that
window is above the msys terminal (with rxvt emulation), the visible part
of the window is black above the vertical border of the terminal (and not
above the horizontal border, btw). It's like my window is tranparent above
the vertical border of the terminal. There is no problem with other
windows.

is it normal ?

Vincent Torri

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys