On 2021-11-07 11:40, Roumen Petrov wrote:
Hello Brian,
Brian Inglis wrote:
Hi folks,
I am trying to port:
[SNIP]
Should I run libtoolize with all defaults in the source package src
directory and/or the x11 subdirectory?
Run libtoolize in directory if exist configure.ac that uses libtool.
Yo
Hello Brian,
Brian Inglis wrote:
Hi folks,
I am trying to port:
[SNIP]
Should I run libtoolize with all defaults in the source package src directory
and/or the x11 subdirectory?
Run libtoolize in directory if exist configure.ac that uses libtool.
You may will to redirect project to use commo
Hi folks,
I am trying to port:
https://github.com/Bill-Gray/PDCursesMod/tree/master/x11
as Xcurses to build THE-X11 on Cygwin.
Has anyone got any (sources of) advice for adding recent libtool support
to a recent autotools package that does not use libtool (uses Linux
commands
Hi Mike,
> Is it possible use Cygwin to run an autotools 'configure' script but
> have the compiler be MSVC?
Yeah, sure, i have done this in the past.
"./configure CC=cl.exe" should get you going as far as i remember. Make
sure your MS tools are in your PATH.
There
On 3/26/2020 5:37 PM, Csaba Raduly via Cygwin wrote:
Hi Mike,
On Thu, Mar 26, 2020 at 9:31 PM Mike Gran via Cygwin
wrote:
Hi-
Is it possible use Cygwin to run an autotools 'configure' script but have
the compiler be MSVC?
I would be very surprised if this worked. 'configur
Hi Mike,
On Thu, Mar 26, 2020 at 9:31 PM Mike Gran via Cygwin
wrote:
> Hi-
> Is it possible use Cygwin to run an autotools 'configure' script but have
> the compiler be MSVC?
>
I would be very surprised if this worked. 'configure' is likely to run the
compile
Hi-
Is it possible use Cygwin to run an autotools 'configure' script but have the
compiler be MSVC?
Thanks,
Michael
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubs
On Thu, Sep 22, 2016 at 06:13:07PM -0400, HiTech HiTouch wrote:
> Please forgive the somewhat off topic, but people who use Autotools and
> Mingw hang here and may be able to point me.
>
> I'm looking for a central place where people ask questions about Autotools
> (autoconf
HiTech HiTouch writes:
> PPS: The Autotools anchor,
> https://www.gnu.org/software/autoconf/autoconf.html, has a bad pointer
> to its mailing list archive. Letting google do the work, there is
> nothing in that last several years for XP, Windows, or win32 save for
> spam.
Som
Please forgive the somewhat off topic, but people who use
Autotools and Mingw hang here and may be able to point me.
I'm looking for a central place where people ask questions about
Autotools (autoconf automake, etc.). My google-ing finds (in
addition to the manuals) only mailing lis
ving.
These messages come from Perl and are harmless (the new version of Perl is
more strict when checking a few things and has stepped up the deprecation
cycle for some regex stuff to emanate warnings). This is already fixed
upstream in autotools, but it hasn't filtered down to Cygwin y
Hi,
Gilberto Perez gmail.com> writes:
>
> I have never had this problem until I upgraded to Windows 10. When
> attempting to use 'autoreconf', I get the following messages:
>
> main::scan_file() called too early to check prototype at
> /usr/bin/aclocal-1.11 line 644.
> Unescaped left brace in
-Original Message-
From: Gilberto Perez
Sent: Tuesday, September 22, 2015 1:08 PM
To: cygwin@cygwin.com
Subject: Issue with Autotools and Perl on Windows 10
I have never had this problem until I upgraded to Windows 10. When
attempting to use 'autoreconf', I get the followin
I have never had this problem until I upgraded to Windows 10. When
attempting to use 'autoreconf', I get the following messages:
main::scan_file() called too early to check prototype at
/usr/bin/aclocal-1.11 line 644.
Unescaped left brace in regex is deprecated, passed through in regex;
marked by
that
> the 4.x set -e behaviour might be part of this problem, but there must have
> been a change in cygport that's exposing it when it was previously hidden.
I certainly can't think of one, and if cygport wasn't working with
autotools I would have noticed a long time ago. :-
On 20/01/2012 12:50, Andy Moreton wrote:
> On Thu 19 Jan 2012, Dave Korn wrote:
>
>> Commenting-out the "set -e;" line at the start of /usr/bin/cygport
>> has fixed this problem, and my builds now run just fine, but huh? I
>> checked in git; that line has been there since like forever, so why is
On Thu 19 Jan 2012, Dave Korn wrote:
> Commenting-out the "set -e;" line at the start of /usr/bin/cygport
> has fixed this problem, and my builds now run just fine, but huh? I
> checked in git; that line has been there since like forever, so why is
> it giving me trouble now? Is there something
On 1/20/2012 12:45 AM, Dave Korn wrote:
Hi list,
I just updated my Cygwin installation for the first time since Oct 26 last
year, and now I'm unable to successfully run cygport builds any more. The
builds fail because of the spontaneous exiting of one or other of the scripts
that cygpo
Hi list,
I just updated my Cygwin installation for the first time since Oct 26 last
year, and now I'm unable to successfully run cygport builds any more. The
builds fail because of the spontaneous exiting of one or other of the scripts
that cygport invokes - I've had autoconf-2.68 spontane
I really would have love to investigate why it is slow; but atm, i have no more
ideas ...
For the only remark done far from now, i don't have any duplicates in PATH but
cygcheck must be bugged or it finds informations setted elsewhere than in
environment and that i'm not aware of. The install is c
Maybe is there a bug in cygcheck ?
Maybe there are others ways that looking in env['PATH'] to construct your
"Pathes check" that i am not aware ?
Maybe PATH is not related to performance issues, afterall...
But for the moment, and my current knowledge, i don't see any duplicates in the
$PATH varia
mak...@apem3 ~
$ echo $PATH
/cygdrive/e/minitage2/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/e/Subversion/bin:/cygdrive/e/OpenLDAP/CD
SSilver/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/system32
/WindowsPowerShell/v1.0:/cygd
But there is no reason for that :
>> E:\cygwin2\bin
>> E:\cygwin2\bin
...
It's a default install ...
Peter Rosin a écrit :
> Den 2009-12-03 12:04 skrev kiorky:
>> Are there others ways i an investigate ?
>>
>
> As far as I can tell, you never did clear out the duplicates from your
> path
Den 2009-12-03 12:04 skrev kiorky:
Are there others ways i an investigate ?
As far as I can tell, you never did clear out the duplicates from your
path.
From 2nd instance of 2.out:
Path: E:\cygwin2\usr\local\bin
E:\cygwin2\bin
E:\cygwin2\bin
E:\cygwin2\usr\X11R6\bi
Are there others ways i an investigate ?
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
signature.asc
Description: OpenPGP digital signature
Dave Korn a écrit :
> kiorky wrote:
>
> Look, this is a completely wacky and random WAG, and it's not likely to
Not worth to try it ;)
> work, but... try turning off the shell icon overlays in the tortoisesvn
> explorer shell extension, if you happen to have them turned on.
Tried:
real21m
kiorky wrote:
> My related new 2.out, without improvments in term of performances (>20min of
> compilation).
Look, this is a completely wacky and random WAG, and it's not likely to
work, but... try turning off the shell icon overlays in the tortoisesvn
explorer shell extension, if you happen to
Larry Hall (Cygwin) a écrit :
> Thanks. Since cygcheck for 1.5 doesn't find gcc and you have tools from
> other sources installed,
This is legitimate, i understand.
> I have to ask, are you comparing Cygwin's 1.5
> build
> tools with Cygwin's 1.7 build tools?
I use only cygwin1 stuff in cygwi
On Tue, Dec 01, 2009 at 06:28:47PM -0500, Larry Hall (Cygwin) wrote:
>On 12/01/2009 05:31 PM, kiorky wrote:
>> Larry Hall (Cygwin) a ??crit :
>>
>>> Can we see *attached* cygcheck output for your 1.7 and 1.5 installs, as
>> 1.out -> cygwin
>> 2.out -> cygwin2
>
>Thanks. Since cygcheck for 1.5 do
On 12/01/2009 05:31 PM, kiorky wrote:
Larry Hall (Cygwin) a écrit :
Can we see *attached* cygcheck output for your 1.7 and 1.5 installs, as
1.out -> cygwin
2.out -> cygwin2
Thanks. Since cygcheck for 1.5 doesn't find gcc and you have tools from
other sources installed, I have to ask, are
On 12/01/2009 04:27 PM, kiorky wrote:
Hello,
While making effort to port minitage [1] to windows, i had in mind to test
cygwin2 (setup-1.7.exe as i understood) as it as improved support for some
things like getaddrinfo and posix threads.
Indeed the goal is to recompile a bunch of libraries from s
Hello,
While making effort to port minitage [1] to windows, i had in mind to test
cygwin2 (setup-1.7.exe as i understood) as it as improved support for some
things like getaddrinfo and posix threads.
Indeed the goal is to recompile a bunch of libraries from sources, then make
them link together, an
Charles Wilson wrote:
> /not/ update them at all;
> 1) The current and soon-to-be-released gcc's, based on gcc-3.4.5 and
> gcc-4.3.x, both still require autoconf-2.59 and automake-1.9.6
Good reasoning.
> So, as soon as I spin the "regular" cygwin autoconf-2.64 package, then
> our "standard" au
5 and
gcc-4.3.x, both still require autoconf-2.59 and automake-1.9.6
[actually, I'm not sure about that; gcc-3.x might still be stuck in
ac-2.13 land].
2) The only reason we needed separate versions of these autotools rather
than using the cygwin standard ones was because the cygwin standard
ver
On Apr 20 17:45, Eric Blake wrote:
> I did notice that flock only seems to protect processes spawned in the
> same cygwin process hierarchy - using strace to spawn my test program
> created a new hierarchy, and thus did not see the lock held by the old
> hierarchy. That does not affect the origina
Corinna Vinschen cygwin.com> writes:
> Because this testcase works fine. I hope it's not trying to do this:
>
> parent opens file
> fork
> child calls flock()
> exit
> fork
> second child relies on the lock.
>
> because this is exactly the scenario which doesn't work with flo
On Apr 20 17:34, Corinna Vinschen wrote:
> On Apr 20 15:14, Eric Blake wrote:
> > Corinna Vinschen cygwin.com> writes:
> >
> > > > > I'd prefer a testcase in C.
> > > >
> > > > So would I. I'm not even sure whether perl was using flock or
> > > > lockf/fcntl. Do you still need me to try and wr
On Apr 20 15:14, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > > > I'd prefer a testcase in C.
> > >
> > > So would I. I'm not even sure whether perl was using flock or
> > > lockf/fcntl. Do you still need me to try and write a STC, or at least
> > > test how perl behaves with
Corinna Vinschen cygwin.com> writes:
> > > I'd prefer a testcase in C.
> >
> > So would I. I'm not even sure whether perl was using flock or
> > lockf/fcntl. Do you still need me to try and write a STC, or at least
> > test how perl behaves with your first patch?
>
> I checked in a patch whic
On Apr 17 06:58, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Corinna Vinschen on 4/17/2009 4:01 AM:
> > Default question: Do you have a simple testcase to reproduce this
> > problem? I'm going to play with the lock.pl perl script from
> > http://lists.gnu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 4/17/2009 4:01 AM:
> Default question: Do you have a simple testcase to reproduce this
> problem? I'm going to play with the lock.pl perl script from
> http://lists.gnu.org/archive/html/bug-automake/2009-04/msg00053.h
On Apr 17 12:01, Corinna Vinschen wrote:
> On Apr 16 20:39, Eric Blake wrote:
> > This change in cygwin 1.7:
> >
> > - File locking is now advisory, not mandatory anymore. The fcntl(2) and
> > the new lockf(2) APIs create and maintain locks with POSIX semantics,
> > the flock(2) API creates a
On Apr 16 20:39, Eric Blake wrote:
> This change in cygwin 1.7:
>
> - File locking is now advisory, not mandatory anymore. The fcntl(2) and
> the new lockf(2) APIs create and maintain locks with POSIX semantics,
> the flock(2) API creates and maintains locks with BSD semantics.
> POSIX and
This change in cygwin 1.7:
- File locking is now advisory, not mandatory anymore. The fcntl(2) and
the new lockf(2) APIs create and maintain locks with POSIX semantics,
the flock(2) API creates and maintains locks with BSD semantics.
POSIX and BSD locks are independent of each other.
is ca
Chris Blanco wrote:
>
> I am setting up an automated build system for my company. In building some
> of our base libraries on Windows I am running into major issues. I am using
> the Visual Studio tools (cl.exe) to do the compilation which is working
> fine. I run into problems though when trying
I am setting up an automated build system for my company. In building some
of our base libraries on Windows I am running into major issues. I am using
the Visual Studio tools (cl.exe) to do the compilation which is working
fine. I run into problems though when trying to generate a library that
link
Liam Staskawicz makingthings.com> writes:
> "checking for readline in -lreadline... no"
> " configure: error: readline not found"
>
> A cygcheck -c shows that I have libreadline4, 5, and 6 all installed OK
That's all find and dandy, but those are only the runtime dlls. To compile
against lib
Hi - I'm trying to build an autotools-based package and can never get
past the ./configure stage, as readline is not found. It fails, saying
"checking for readline in -lreadline... no"
" configure: error: readline not found"
A cygcheck -c shows that I have libreadline
I've been looking at what kind of errors "Resource temporarily
unavailabe" users have had. Coding the Win32 api isn't a strongpoint
of mine. So I've gathered the errors here and some Microsoft Support
articles here on the topics. Some seem more relavant than others.
Hopefully someone smarter than
st in DELL.
The machine is now a cool 48 degrees no matter what it does or how
hard it works, but cygwin still wont compile gcc 4.0.1 or do too much
work using autotools (automake etc).
So I'm stumped.
/pspblizz
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Pro
On 9/23/05, PSP Blizz <[EMAIL PROTECTED]> wrote:
> On 9/23/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> > I think this is hardware trouble. Try some cooling spray on the CPU when
> > it's malfunctioning. I really don't think this is likely to be a cygwin
> > bug.
> The laptop was also places on
On 9/23/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> I think this is hardware trouble. Try some cooling spray on the CPU when
> it's malfunctioning. I really don't think this is likely to be a cygwin
> bug.
Okay, had a tool logging cpu fans and cpu temps while it was running now:
Max CPU load /
On 9/23/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> I think this is hardware trouble. Try some cooling spray on the CPU when
> it's malfunctioning. I really don't think this is likely to be a cygwin
> bug.
It could be, but I'm a software man ;) My temps in Celcius are on idle
(2% cpu load) and
Original Message
>From: PSP Blizz
>Sent: 23 September 2005 11:05
> Hi!
>
> On 9/22/05, Dave Korn <[EMAIL PROTECTED]> wrote:
>
>> Maybe it's whatever app uses XPCOM that is messing up your system,
>> rather than AV or firewall?
>
> Okay, I now booted with a clean system. And logged in
Hi!
On 9/22/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Maybe it's whatever app uses XPCOM that is messing up your system, rather
> than AV or firewall?
Okay, I now booted with a clean system. And logged in as a user with
minimal settings on the windows XP box. I then ran cygwin using
"runas" s
XPCOM is something used by FireFox it seems. I'll try to reboot and
not use FireFox once. But I'm doubtfull it'll help the situation as
XPCOM only hangs after cygwin has crashed with the "Resource" message.
Also, it's impossible to start any new application which needs to
access new unloaded DLLs.
Original Message
>From: PSP Blizz
>Sent: 22 September 2005 10:19
> After this it's not possible to do much in either windows or in
> cygwin. Also when trying to restart my computer after susch a crash,
> windows has to kill "XPCOM Event viewer" to be able to shut down.
Maybe it's whate
ump_sysinfo: GetVolumeInformation() failed: 1450
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 1450
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 1450
I've also incuded the last lines from the script that fails, please
remember that using autotools also crashes on any other code
This announcement comes somewhat late, but is provided so that there
exists some record of this change in the cygwin-announce mailing list
archive.
On July 1, 2005, the existing autotools on cygwin were all obsoleted by
new versions, where the newer releases were more consistent with
Okay this one is picking at gnits, but autoheader 1.9 will always issue a
warning message when you ask it to produce warning message because the
authoheader wrapper passes --warning= and -W as --warning=,blah,blah
and -W,blah,blah instead of --warning=blah,blah and -Wblah,blah.
Here's another p
I'm having trouble invoking the wrapper scripts for aclocal.
Here's my session log...
---
[EMAIL PROTECTED] ~/MyApp
$ aclocal --force
aclocal: invalid option --force
Try `aclocal --help' for more information.
[EMAIL PROTECTED] ~/MyApp
$ aclocal --version
aclocal
On Sat, 20 Nov 2004, Charles Wilson wrote:
> Eric Blake wrote:
> > The autotools wrappers (automake 1.7.9-1, autoconf 2.59-1, and libtool
> > 1.5b-1) all have argument parsing bugs. They are trying to parse every
> > option known to either -stable or -devel, but fail in
Charles Wilson schrieb:
Eric Blake wrote:
The autotools wrappers (automake 1.7.9-1, autoconf 2.59-1, and libtool
1.5b-1) all have argument parsing bugs. They are trying to parse every
option known to either -stable or -devel, but fail in
several respects.
I've been thinking for a long ti
Eric Blake wrote:
The autotools wrappers (automake 1.7.9-1, autoconf 2.59-1, and libtool
1.5b-1) all have argument parsing bugs. They are trying to parse every
option known to either -stable or -devel, but fail in
several respects.
True.
First, the wrappers are not robust to new options being
The autotools wrappers (automake 1.7.9-1, autoconf 2.59-1, and libtool
1.5b-1) all have argument parsing bugs. They are trying to parse every
option known to either -stable or -devel, but fail in
several respects.
First, the wrappers are not robust to new options being added. For example
On Sun, Nov 03, 2002 at 09:10:47AM -0800, amores perros wrote:
> That is, has anyone seen these three all work together ?
> i) installation & use as a normal user
> ii) ntsec
> iii) autotools
> I ran the cygwin setup as my normal user, and when prompted,
> gave
On Sun, Nov 03, 2002 at 09:10:47AM -0800, amores perros wrote:
>[I made a yahoo mail account, b/c the cygwin mail list bounces email
>from hotmail, at least sometimes.)
http://sources.redhat.com/lists.html#rbl-sucks
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:
--- Below this line is a copy of the message.
Subject :
Should ntsec & autotools work under XP prof ?
Date :
Sun, 03 Nov 2002 16:53:57 +
As I have stock default security token in my "limited" account,
and a stock cygwin distribution, AFAIK, and au
Since there were no objections, I am going to mark these packages
current -- with one caveat:
I've found a problem with autoconf-2.53a, but the same behavior is
exhibited by autoconf-2.53. So, I'm going to mark
autoconf-devel-2.53a-1 current, but remove a-d-2.53-1 so that a-d-2.52-4
remains
Charles Wilson wrote:
> I've uploaded test versions of:
>
> autoconf-devel-2.53a-1
> automake-devel-1.6.1-3
> libtool-devel-20020502-2
[snip]
> Ralf, Robert, Corinna, other interested parties, please give these a
> good workout. Notes on test results and my comments below.
Robert has
I've uploaded test versions of:
autoconf-devel-2.53a-1
automake-devel-1.6.1-3
libtool-devel-20020502-2
autoconf: updated to official '2.53a' release. Previous cygwin version
was 2.53.
automake: updated to official '1.6.1' release. Previous cygwin version
was 1.6. Also added a few fi
age-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Ralf Habacker
> Sent: 21 January 2002 23:41
> To: Cygwin
> Subject: RE: Autotools broken?
>
>
> > Possible bug:
> > The patched libtool.m4 that you pointed me to has a slight bug. It
> >
; > Sent: 20 January 2002 15:57
> > To: Cygwin
> > Cc: Stephano Mariani
> > Subject: RE: Autotools broken?
> >
> > Look in the thread "libtool-devel and kde2 - problem with
> > AC_PROG_CXX" -
> > there is a patched libtool.m4 which works for
ginal Message-
> From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
> Sent: 20 January 2002 15:57
> To: Cygwin
> Cc: Stephano Mariani
> Subject: RE: Autotools broken?
>
> Look in the thread "libtool-devel and kde2 - problem with
> AC_PROG_CXX" -
> there is a patched l
nday, January 20, 2002 2:11 PM
> To: [EMAIL PROTECTED]
> Subject: Autotools broken?
> Importance: High
>
>
> It appears in the latest cygwin (updated just hours ago) that the
> libtool is broken...
>
> I'm using the autotools on a very big build tree, that
It appears in the latest cygwin (updated just hours ago) that the
libtool is broken...
I'm using the autotools on a very big build tree, that has over 600 c
source files to be built, and some 50 assembler sources. When using
autoconf, automake and libtool, the configure script dies compla
t; <[EMAIL PROTECTED]>
To: "Stephano Mariani" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 07, 2001 8:42 PM
Subject: Re: Autotools
> Stephano Mariani wrote:
> >
> > With the release of the new autotools build system I was under the
> >
Stephano Mariani wrote:
>
> With the release of the new autotools build system I was under the
> impression that with libtool, automake supported building dlls under cygwin.
wrong impression. It isn't ready yet. Automake and autoconf are fine,
but I haven't finished the sys
With the release of the new autotools build system I was under the
impression that with libtool, automake supported building dlls under cygwin.
I seem not to be able to do this, no dlls are produced and
despite --disable-static, I get .a & .la. I am able to build dlls manually
perfectly, and
79 matches
Mail list logo
