-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/08/18 15:42, Bob Friesenhahn wrote:
> On Sat, 25 Aug 2018, Marko Lindqvist wrote:
>
>> Indeed. When considering addition of a new macro call to
>> configure.ac it often requires a lot of digging (usually from
>> NEWS) to find out if using that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/08/18 09:23, Sébastien Hinderer wrote:
> Keith Marshall (2018/08/23 20:00 +0100):
>> For --build, the output from config.guess should always be
>> suitable; for --host, it may be okay to affix an arbitrary
>&
On 23/08/18 18:08, Earnie wrote:
> If you're using MSVC, there is no crosstool chain of software so you
> specify a fictitious --host and --build to be the same such as
> {i686,x86_64}-pc-msvc and point the environment variables to the
> binaries.
But the OP seems to want to use AC_CANONICAL_*.
On 21/08/17 07:21, Ben Pfaff wrote:
>> As the --build value can be guessed, I think that it would be annoying
>> for the user to force him to use --build in case of cross-compilation.
>> IMHO, making case 3 like case 2 with the guessed value of BUILD (as
>> I've proposed above) would make sense.
On 13/10/16 15:24, Russell Shaw wrote:
> On 13/10/16 13:11, Luca Saiu wrote:
>
> ...
> > So, what I'm asking you is: does a clean solution exist, or compiling
> > without a runtime library is just not supported by the Autotools? It
> > sounds weird to say that for configuring you need a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/05/16 09:17, A.P. Horst wrote:
> On 5/30/2016 10:07, Keith Marshall wrote:
>> On 30/05/16 07:06, A.P. Horst wrote:
>>> I am using: msys-autoconf-2.68-1-msys-1.0.17
>>> msys-automake-1.11.1-1-msys-1.0.13
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/05/16 07:06, A.P. Horst wrote:
> I am using: msys-autoconf-2.68-1-msys-1.0.17
> msys-automake-1.11.1-1-msys-1.0.13
Just curious, but why? From the package description for the former:
> This msys port of autoconf has been modified
>
On 26/08/14 16:18, Paul Smith wrote:
Can't we just #define stat(_p,_b) _stat(_p,_b)? Not sure if that's
sufficient: I'm not overly familiar with the limitations on the POSIX
emulation functions in Windows.
That's effectively what MinGW does anyway, (although it does it through
an import
On 26/08/14 18:22, Eli Zaretskii wrote:
Date: Tue, 26 Aug 2014 08:25:38 -0700
From: Paul Eggert egg...@cs.ucla.edu
Cc: Autoconf Autoconf@gnu.org, Eric Blake ebl...@redhat.com,
bug-make bug-m...@gnu.org
As far as Windows goes, NTFS file systems have 100 ns resolution, and
FAT file
On 19/01/14 23:58, Per Bothner wrote:
This means I have to do AC_PROG_CC unconditionally, which means
you can't run configure unless a C compiler is available. This is
a shame, since you only need the C compiler if --enable-kawa-frontend
is selected.
I guess this is another facet of the
What is best recommended practice, to work around the issued described
in this MinGW bug: https://sourceforge.net/p/mingw/bugs/2155/ ?
In summary: building cross-gcc, all up to stage 1 compiler build is
fine, but stage 2 cannot proceed until the host libraries are built.
The stage 1 compiler
On 27/12/13 08:58, Guo Leaveye wrote:
Given a short WinSock program source _testlib.c_ here:
/* testlib.c */
#include stdio.h
#include windows.h
#include winsock2.h
I'm astonished that this works! If you include winsock2.h, then you
either should *not* include windows.h,
On 6 June 2013 12:12, Earnie Boyd wrote:
On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote:
Also when I just have:
echo $var | grep -Eq '^[0-9]+$'
echo $?
--8--
I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17
sh --version
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
On 6 June 2013 13:41, Eric Blake wrote:
A more robust, (and more portable), formulation may be:
echo $var | grep '^+\{0,1\}[0-9]\{1,\}$' /dev/null 21
Why fork, when straight shell will do?
case $var in
...
Agreed, avoiding the fork is a good idea, and I do often use case
On 03/02/13 09:49, Yann Droneaud wrote:
[Moving the discussion to autoconf@gnu.org]
So to create a valid --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub. I was surprised by the behavor and made
patches to
On 03/02/12 10:20, Werner LEMBERG wrote:
Thanks for the answers, Vincent and Peter!
You do as you do with whatever else you are requiring. Check if
#include windows.h is there, and check if you can link with some
API of your choice. [...]
I would have expected something like this as a
On 03/02/12 14:08, Keith Marshall wrote:
I'll dig out the MINGW_AC... standard macro I use, and post it later.
Found it, quicker than I expected; attached.
--
Regards,
Keith.
# MINGW_AC_WIN32_NATIVE_HOST
# --
# Check if the runtime platform is a native Win32 host
On Monday 17 May 2010 20:44:31 Daniel Leidert wrote:
What you are attempting doesn't make much sense to me yet. The
whole point of i18n is that the translation files can be
maintained independently of the executable, and that a person
can install a subset of the compiled .mo files
On Monday 17 May 2010 23:55:10 Ben Pfaff wrote:
I have one target which is actually a utility used during
*build* time. Is it possible to specify one target which should
*not* be built with the cross-compiler, but natively instead?
I find that the easiest way to deal with this problem is
On Tuesday 18 May 2010 21:10:00 Eric Blake wrote:
On 05/18/2010 05:58 AM, Keith Marshall wrote:
Of course, if your target is MS-Windows, it doesn't support
catgets or gettext OOTB, and even if you adopt one of the
available ports, it is likely that the user will neither know
nor think
On Sunday 16 May 2010 04:41:27 NightStrike wrote:
I've considered creating a separate config.ac/Makefile.am for
this one executable, but am hoping to find a simpler solution.
There's a way to do this as I recall, but I forget offhand. You'd
really be best off asking on the automake mailing
On Saturday 15 May 2010 18:52:10 Natalie Tasman wrote:
I have one target which is actually a utility used during *build*
time. Is it possible to specify one target which should *not* be
built with the cross-compiler, but natively instead?
I faced a similar problem, when I autoconfiscated `man'
On Friday 12 February 2010 20:55:03 David Bruce wrote:
AC_MSG_CHECKING([for native Win32])
case $host in
*-*-mingw*)
native_win32=yes
;;
*)
native_win32=no
;;
esac
I don't know the best way to solve your principal problem, but a
better way to check for this is to use
On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote:
interesting that this looks for cl.exe but not for CL.EXE. I
though uppercase would be correct
On MS-Windows hosts, the file system is case-insensitive, so there is
really no difference -- upper, lower or mixed case, they are the
On Tuesday 15 September 2009 05:31:04 Ralf Wildenhues wrote:
Could I add a related question:
Yes, but we'd slightly prefer if you started a new thread for a
new question.
That said, at least this much of your response is right on topic for
the original discussion...
is there a way to
On Wednesday 09 September 2009 18:12:02 Ralf Wildenhues wrote:
And yes, it is perfectly possible to have subpackages that do not
use Automake, or do not use Autoconf either. Their configure
scripts merely have to conform to what the GNU Coding Standards
say, and their makefiles too.
Which is
On Tuesday 11 August 2009 17:57:47 Dr. David Kirkby wrote:
It STILL does not work for me, though at least it is not a syntax
error.
This is what I have in configure.ac
minimum_perl_version=5.6.0
So, within configure you run
perl -e 'require 5.6.0'
Try running that yourself, from the
On Tuesday 11 August 2009 20:07:40 Dr. David Kirkby wrote:
Try running that yourself, from the shell prompt; do you see
what the problem is now? (Hint: you have a minor version of 8,
but you require a much later minor version of 600 or more --
it's arcane, but it seems to be how perl
On Sunday 17 May 2009 16:13:19 Ralf Wildenhues wrote:
Several mails in this thread have dealt with the same
issues twice or more times. It's as if people ask questions but
don't read answers, and that is what is very impolite towards
other people on this mailing list.
Ralf,
I do *not*
On Friday 15 May 2009 03:45:21 Alfred M. Szmidt wrote:
How about this? I took into account Ralf's comments as well.
We're talking a generic one-size-fits-all INSTALL here, right?
You *cannot* unequivocally assert this...
If you wish to install the package into a staging directory
On Wednesday 13 May 2009 14:22:25 Alfred M. Szmidt wrote:
The problem is if you pass --bindir=/foo to configure, and
then do `make install prefix=/bar', the files installed in bindir
will be installed in /foo, and not /bar as the user might have
exepcted; this is why passing prefix to `make
On Wednesday 29 April 2009 17:21:58 Zainab Qureshi wrote:
This is the error i am getting. C:/check is where i have placed
configure.ac
autoconf configure.ac
/mingw/bin/autoconf: /c/check/C:/MinGW/bin/autom4te: No such file
or
This looks well messed up. Since your problem is very specific
On Wednesday 15 April 2009 01:44:55 Eric Blake wrote:
CC_FOR_BUILD is not an autoconf variable, but one that is
typically supported by packages that need to support Canadian
cross builds (such as gcc).
It isn't just Canadian builds that may need access to native tools,
even when building for
On Wednesday 15 April 2009 07:06:09 Ralf Wildenhues wrote:
Not all packages follow GNU Coding Standards, therefore,
DESTDIR is not properly supported in a surprisingly large
number of packages.
We already enforce a level of GNUism on packages that use
autoconf/automake, I do not
On Wednesday 15 April 2009 17:00:53 Alfred M. Szmidt wrote:
What is the problem with DESTDIR=C:/foo?
Nothing, if it were just `DESTDIR=C:/foo', but it isn't; the usage
is `$(DESTDIR)$(prefix)', and in a correctly configured w32 build,
$(prefix) is already C:/something, so you end up with
On Tuesday 10 March 2009 07:18:26 Ralf Wildenhues wrote:
Undocumented (so watch out when updating Autoconf), but:
eval $ac_configure_args
Didn't that get clobbered, in some not so distant past releases?
(autoconf-2.60 and 2.61 IIRC; I can't remember if it was fixed in
2.62 or not, but it
On Monday 23 February 2009 01:39:52 Allan Caffee wrote:
Indeed I tried a very similiar scenario using gcc 4.2.4 on Ubuntu
(with a static library) and had the same problem.
Unsurprising, since you have specified your g++ command incorrectly.
Was the error similiar to your original post? A
On Monday 23 February 2009 04:26:11 Peter Johansson wrote:
aaragon wrote:
aara...@aaragon-laptop:~/Lib/lib$ nm -g libcpputils.so | grep
flip | c++filt 3c20 T cpputils::flip(double)
Isn't the problem that flip(double) is in namespace cpputils?
Well yes, and no. The real problem is that
On Monday 13 October 2008 13:56:21 Eric Blake wrote:
The existing text is correct (albeit a
bit confusing in the automake-user's case where Makefile.in is
generated, so the upstream Makefile.am needs the modification
instead), so I'm quite sure what wording to use here, whether or
not
On Friday 19 September 2008 21:31:15 Howard Larson wrote:
FWIW Ralf, I've just built autoconf-2.63 on an MSYS-1.0.11 box at
work. No errors in building. I've left the testsuite running,
but will not be able to report the final result until Monday; (I
don't use msw on my own boxes).
On Sunday 21 September 2008 21:12:22 Matěj Týč wrote:
Thank you, Brian, I have sent your message to the macro author, so
now it is really easy for him to fix it for others as well.
Why don't you just adapt it yourself, to suit your own requirements?
That after all, is the underpinning of the
On Saturday 20 September 2008 22:40:56 Matej Tyc wrote:
Then you need to use a macro that allows for specifying a header
to include. You can write one yourself, or try AC_CHECK_FUNC_IN
from the autoconf macro archive.
By the way, do you have an idea what's the cause of this failiure?
On Thursday 18 September 2008 06:07:28 'Ralf Wildenhues' wrote:
I have performed a search for a conftest.obj file and it does
not exist. As I mentioned in an earlier email, build of
libtool failed to produce any .obj files.
I have installed MinGW. Does it not have gcc? If not, how
On Tuesday 09 September 2008 23:08:26 Ralf Wildenhues wrote:
I for one am simply more likely to just delete a message thread
without reading it further when people top-post in it, or
bottom-post in it without removing irrelevant parts.
FWIW, I agree completely with Ralf on this.
I operate a
On Monday 28 July 2008 19:54:01 [EMAIL PROTECTED] wrote:
I have 2 files : foo.c and bar.c
when I cross compile, i want to compile foo.c with the host compiler
and bar.c with the current compiler
Is it possible if I pass values to --build and --host ?
Yes, it is possible, if you set the
On Wednesday 02 July 2008 06:42:50 Ralf Wildenhues wrote:
* Tim Post wrote on Wed, Jul 02, 2008 at 07:39:01AM CEST:
I've been including most checks that autoscan suggests. My
reasoning is that someone down the line might need those checks
and may not be able to autoreconf in order to
On Monday 30 June 2008 22:37:13 SUNIL NEGI wrote:
m4.exe is a valid file and is in the location /usr/local/bin
On *MSYS*? What MSYS version? What m4 version? From whence? If
it's in /usr/local/bin, then it either isn't an appropriate MSYS
build, or it isn't correctly installed; it *should*
On Friday 30 May 2008 17:24, SUNIL NEGI wrote:
autom4te: freezing produced output:
make[3]: *** [m4sugar.m4f] Error 1
make[3]: Leaving directory
`/home/snegi1/dlds/autoconf-2.62/lib/m4sugar' make[2]: ***
[all-recursive] Error 1
make[2]: Leaving directory `/home/snegi1/dlds/autoconf-2.62/lib'
).
FWIW, after applying this, the testsuite runs for seven hours, on my
1.7GHz Pentium-D Win2K box; after this protracted period, it completes
successfully, with zero unexpected results.
Regards,
Keith.
2008-05-08 Keith Marshall [EMAIL PROTECTED]
Work around MSYS bug, which would cause `make
On Saturday 10 May 2008 20:13, Eric Blake wrote:
According to Keith Marshall on 5/9/2008 2:18 PM:
| Having successfully built autoconf-2.62 for use with MSYS, on
| MS-Windows, `make check' fails as follows:--
|
| $ make check
| [...]
| /bin/sh ./testsuite
| rm: reading directory
Hi Mudeem,
This looks suspiciously like a cross-compiler installation problem.
On Friday 02 May 2008 20:32, Mudeem Siddiqui wrote:
configure:5589: checking argz.h usability
Here, we see configure correctly invoking the cross-compiler, to check
that argz.h can be compiled:
configure:5601:
On Monday 24 March 2008 16:51, Ralf Wildenhues wrote:
On Mon, Mar 24, 2008 at 07:10:24AM -0600, Eric Blake wrote:
I'll try looking into the MinGW failure, but I'm not sure how long
it will take me to reproduce it (I don't normally build in MinGW;
Here's some more data. I installed MinGW's
On Monday 24 March 2008 20:28, Ralf Wildenhues wrote:
The problem arises because the vanilla build with MinGW leaves the
stdio streams in O_TEXT mode, resulting in CRLF output, whereas the
MSYS build uses O_BINARY mode for these streams, resulting in just
LF output; the residual CRs from
On Sunday 16 March 2008 19:28, Paul Smith wrote:
On Sun, 2008-03-16 at 15:40 +0100, Dirk wrote:
My point is that autoconf is such a bloated, self-important,
wet-script-kiddie-dream that is DOESN'T make the build process
easier...
It rather encourages people to write their own config
On Saturday 15 March 2008 02:57, JoeOutflow wrote:
... the -L flags should be contained in the LDFLAGS
variable, but this is blank in the Makefiles. According to the manual
LDFLAGS is a preset output variable and a search for LDFLAGS
through the entire manual fails to turn up any explanation
On Saturday 15 March 2008 19:22, Tim Dennis wrote:
the macro call:
AC_SEARCH_LIBS(h5open_f,[hdf5_fortran],[],[],[ -L$prefix/lib
-I$prefix/lib])
This doesn't look right; that final argument isn't for specifying what
LDFLAGS should be, it is to specify *other* libraries which are needed
to
On Saturday 01 March 2008 19:38, Eric Blake wrote:
Also, MSYS is a notoriously difficult platform to port to.
Hmm. It has become a great deal easier, over the last six months, or
so. I've been using autoconf-2.61 on MSYS, since it was released; it
built and installed straight out of the box,
On Saturday 01 March 2008 20:08, Steven Zimmer wrote:
The problem with it is that the gnome-autogen.sh script searches for
the autotools using the autoconf --version or automake --version or
autolocal --version. The problem is that the autotools come packaged
for MSYS have version numbers
Hi David,
On Sat, 2007-12-29 at 15:38 -0500, David Bruce wrote:
I cross-build my native linux program for Windows using mingw. I recently
ran
autoscan to see if my configure.ac was lacking anything that ought to be in
there, and the recommendations included adding AC_FUNC_MALLOC and
On Tue, 2007-10-30 at 23:25 -0400, Andrej Prsa wrote:
I've long since deleted it, but IIRC, that's exactly what the
example was all about; it *didn't* wait for...
... rather than the building stage ...
...and I don't believe it cared tuppence for...
*if* maintainer mode is
On Tuesday 30 October 2007 15:13, Andrej Prsa wrote:
Here is an example project that illustrates this. It requires a
`mygen' program to build a source. If the program isn't available
but the source is available, the build will succeed. Otherwise the
user will get an error saying that a
On Mon, 2007-10-29 at 17:53 +0100, Laurence Finston wrote:
On Mon, 29 Oct 2007, Daniel Leidert wrote:
Am Montag, den 29.10.2007, 14:18 +0100 schrieb Laurence Finston:
gsl ships a program gsl-config, which very probably will give you the
necessary information.
Appendix C of the GSL
On Monday 17 September 2007 13:15, Eric Blake wrote:
For yourself, just get in the habit of using
.../configure -C CC=cc CXX=CC F77=f77 FC=f95
or write a config.site file that sets these as defaults once and
for all, for your system; see
Vincent Torri wrote, quoting me:
Yes. You can use the MSYS_AC_CANONICAL_PATH macro, published some time
ago on the MinGW/MSYS lists:
http://article.gmane.org/gmane.comp.gnu.mingw.msys/2785
I have a problem with that macro. First note, that I am using autoconf
2.61.
Here is how I use
Markus Duft wrote:
I found a comment in some macro i used to use some time ago (to define
directories). It seems that since autoconf 2.60 $datadir contains
$datarootdir, so either use $datarootdir directly, or change the
MSYS_... Macro to do an eval on that variable, so it gets resolved.
Markus Duft wrote:
I copied that macro from some autoconf macro archive or so, so i
didn't write it. Goolge for AC_DEFINE_DIR, it should be the first
match - that's where i got it from ;o)
That doesn't make it the right thing to do. IMO, the sort of
shennanigans performed in that macro
On Tuesday 04 September 2007 16:21, Vincent Torri wrote:
I'll try AC_DEFINE_DIR with the macro that Keith gave me.
If you do, then you should be aware that AC_DEFINE_DIR, which is not a
standard autoconf builtin macro, (in spite of its apparent assignment
to the AC namespace), depends on
On Tuesday 04 September 2007 22:25, Ralf Wildenhues wrote:
FWIW, just to set things a wee bit straighter: Autoconf chose to
add the datarootdir indirection exactly because the GNU Coding
Standards required this change.
Sure, I realise that; I don't have a problem with it. My point was
that,
On Monday 03 September 2007 18:31, Vincent Torri wrote:
With msys, it is defined as /usr/local/share. But I use that macro
with fopen, which returns an error (file not found)
I would like it to be c:/***/***/local/share
Is it possible ?
Yes. You can use the MSYS_AC_CANONICAL_PATH macro,
On Wednesday 15 August 2007 06:28, Ralf Wildenhues wrote:
Finally, I've compile autoconf (cvs). Remark that the documentation
fails on mingw. If you want the error, I can paste it somewhere.
I think it's merely due to the old texinfo version that comes with
MinGW.
That seems likely. Groff
On Saturday 11 August 2007 08:59, Vincent Torri wrote:
[Re: http://pastebin.ca/653279]
I forget to say that I installed m4 1.4.10 ...
I've seen this before. You can't use a native (MinGW) build of m4 with
autoconf, under MSYS. The problem appears to be the result of CRLF
line endings, which
On Tuesday 24 July 2007 10:44, Joao Miguel Ferreira wrote:
AC_CHECK_HEADER([libxml2/libxml/xpath.h],,
[AC_MSG_ERROR([cannot find xml headers])])
Well... I'm unable to get my system to work as yours... it seems to
me your system is not refusing to look into
/usr/include/libxml2/.
On Monday 23 July 2007 21:18, Joao Miguel Ferreira wrote:
AC_CHECK_HEADER(libxml2/libxml/xpath.h libxml/xpath.h
xpath.h,,AC_MSG_ERROR([cannot find headers for libxml2]))
but ./configure always tells me the same:
...
checking xpath.h usability... no
checking xpath.h presence... no
checking
On Monday 23 July 2007 21:18, Joao Miguel Ferreira wrote:
AC_CHECK_HEADER(libxml2/libxml/xpath.h libxml/xpath.h
xpath.h,,AC_MSG_ERROR([cannot find headers for libxml2]))
A further thought; should you not use AC_CHECK_HEADERS, rather than
AC_CHECK_HEADER, when you specify a list of candidates?
Benoit SIGOURE wrote, quoting me:
How do you run Bourne shell scripts on VMS, which has
a unique command language, all of its own?
Can't you compile a shell with the C compiler on this system?
Possibly, but I suspect that it would be far from a trivial exercise.
Nor would it end there;
Benoit SIGOURE wrote, quoting Joao Miguel Ferreira:
One more question: is there support for the VMS operating system ?
I think so. (never used it though)
Interesting. How do you run Bourne shell scripts on VMS, which has
a unique command language, all of its own?
For Windows I hope
Martin-Gilles Lavoie wrote:
At the strict minimum, I need to have the following flags set
in the generated makefile:
CFLAGS = -c $(CPPFLAGS) -O3 -isysroot \
/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc
LDFLAGS = -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk
The
On Friday 11 May 2007 03:43, haibin zhang wrote:
you can try :
http://sourceforge.net/projects/mingw-install
http://sourceforge.net/project/showfiles.php?group_id=148008
Or better still, use the OFFICIAL MinGW/MSYS distributions from:
https://sourceforge.net/project/showfiles.php?group_id=2435
Vincent Torri wrote:
I have installed autoconf 2.60 on windows with MSYS/MinGW in /usr.
I've been using autoconf 2.60, since almost as soon as it was released,
with both MSYS-1.0.10 and MSYS-1.0.11. I installed it in /usr/local,
and I've *never* seen anything like...
But it returns that error
Ralf Wildenhues wrote, quoting Vincent Torri:
I have installed autoconf 2.60 on windows with MSYS/MinGW in /usr.
The fact that you have installed software in MSYS /usr makes your
question one that is appropriate on the MSYS or MinGW mailing lists,
rather than on the list of the software you
As I read the background discussion, leading to introduction of this
extended test, it appears that it was introduced to appease one broken
compiler suite,
Wrong.
It was triggered by running standard autoconf-2.61 configure scripts on
MinGW and Cygwin.
I beg to differ. The extended test
Eric Blake wrote:
According to Ralf Corsepius on 4/12/2007 4:46 AM:
To me this reads as: MinGW and Cygwin's test -x are broken.
Give an example where cygwin's test -x is broken. MinGW has
problems, but in my experience, cygwin does not.
AFAIK, it has similar problems to those experienced by
Ralf Corsepius wrote:
On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
Stepan Kasal [EMAIL PROTECTED] writes:
* lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip
AS_TEST_X
when cross-compiling.
Thanks, I installed that.
Hmm, I am not convinced. If this check
Eric Blake wrote:
According to Ralf Corsepius on 4/12/2007 4:46 AM:
To me this reads as: MinGW and Cygwin's test -x are broken.
Give an example where cygwin's test -x is broken. MinGW has
problems, but in my experience, cygwin does not.
AFAIK, it has similar problems to those experienced by
Benoit Sigoure wrote:
However, you, as a maintainer of your package, are expected to
use tools that are up-to-date.
Sorry, but with respect, that's complete balderdash!
As maintainer of *my* package, I will use whatever tools are most
appropriate for my needs; that may not be the latest,
On Saturday 31 March 2007 06:02, Paul Eggert wrote:
Keith Marshall [EMAIL PROTECTED] writes:
While MSYS strives to provide a Unixy
shell, it has to work within the limitations of the underlying
Win32 OS, and that means the ability to identify a file as
executable must rely on the file
On Sunday 01 April 2007 18:23, Paul Eggert wrote:
For example, will this test work? If not, why not?
test -x / { { test -x /bin/sh test ! -f /bin/sh.exe; } ||
test ! -f /bin/sh; }
It might. I don't have a Win32 box here, so can't verify this until I
return to work in the morning, but
On Friday 30 March 2007 00:38, Ralf Wildenhues wrote:
I'm curious as to the rationale behind this decision to insist of
linker output files to pass `test -x';
Reading this again, I'm appalled by my sloppy English; of course I meant
to write `...insist on linker output files passing...'.
On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
* Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and
that has broken MinGW based cross-compilers using autoconf packages
in MSYS.
Not the one I'm using.
Andreas Schwab wrote, quoting Vincent Torri:
off topic : is it better to use ${have_ecore_con}
or $have_ecore_con ?
It does not really matter, but ...
Depending on context, it might: $foobar is the same as ${foobar},
but not ${foo}bar. In any context, where you need to append text
to the
Jules Colding wrote:
I'm wondering why I keep seeing the
if test xSTRING1 = xSTRING2 ...
The common idiom is `if test x$foo = xbar ...', and the `x' is
a placeholder, in case $foo happens to expand to nothing. When
quotes are added, the `x' seems redundant, until the test goes
through a
Stefano Sabatini wrote:
I'm working on a project when I have a Perl script, call it script,
which contains some installation dependant paths.
Since I don't want to hardcode them, I created a script.in file, which
contains a line with:
my $system_config_file= @SYSCONF_DIR@/script.conf;
and
Hi Ralf,
Ralf Wildenhues wrote:
* Keith MARSHALL wrote on Tue, Jan 23, 2007 at 05:50:24PM CET:
Ralf Wildenhues wrote:
defined (__OS2__)
# define HAVE_DOS_BASED_FILE_SYSTEM
# ifndef DIR_SEPARATOR_2
# define DIR_SEPARATOR_2 '\\'
# endif
# ifndef PATH_SEPARATOR_2
# define
Ralf Wildenhues wrote:
Keith's (very nice!) explanation about the relationship of the
different w32 shell environments (why don't you, after hashing out the
details, put up a page in the MinGW wiki like that?)
It occurred to me, as I was writing it, that this would be a good idea.
I'll
Brian Dessent wrote, quoting Bob Rossi:
For the simple minded like myself, does this boil down to the fact that
the PATH_SEPARATOR is different if an application is run from a cmd or
msys shell?
The way I would have worded it would have been much simpler.
If your app links against a POSIX
Ralf Wildenhues wrote:
most applications don't need
the notion of two possible path separators.
I wonder...
I first discovered the need for two distinct representations, when
I did the MinGW port for `groff', now officially incorporated into
the GNU sources. I also needed to distinguish them,
Bob Rossi wrote, quoting Ralf Wildenhues, quoting me:
http://article.gmane.org/gmane.comp.gnu.mingw.msys/3822
Thanks for the pointer, I was not fully aware of the limitation that
$PATH_SEPARATOR is useful for $build only, not for $host. OK to apply
the patch at the end to document this?
I
Ralf Wildenhues wrote:
most applications don't need
the notion of two possible path separators.
I wonder...
I first discovered the need for two distinct representations, when
I did the MinGW port for `groff', now officially incorporated into
the GNU sources. I also needed to distinguish them,
Matthew Woehlke wrote:
1) The environment that is passed to your app is again a *verbatim*
copy of
that which was defined in the bash shell.
2) When you access command line arguments in argv, they are again
*verbatim*
copies of what you typed on the command line.
So, what's the
Bob Rossi wrote:
Sure, I need to know what path separator to use in my application.
I also need to know what separator to use in environment variables. Do
you have any better ideas than testing for mingw or cygwin?
Does this help?
http://article.gmane.org/gmane.comp.gnu.mingw.msys/3822
1 - 100 of 219 matches
Mail list logo
