I have had problems with file permissions myself - in my case editing
a file that is part of a fairly large project may cause build errors
later on, when such a file is copied during the build process, because
the Windows permissions are translated into "---". It may very
well be that you are d
No, it's STATUS_ACCESS_DENIED, a permission problem. This could
happen, for instance, if the executable or one of the required DLLs
is not executable.
Corinna
Ah, yes, there is a zlib dll shipped with the source that didn't have
executable perms.
I'll let the TCL people know.
Thanks!
Jon
On Jul 22 09:19, Charles Wilson wrote:
> On 7/21/2013 1:08 AM, Jonathan Kelly wrote:
> >>On Jul 20 08:08, Jonathan Kelly wrote:
> >>>Not. Comes up with error "The application was unable to start
> >>>correctly (0xc022).
>
> >No, it's not - it compiles and runs as it should when I use the Mingw
On 7/21/2013 1:08 AM, Jonathan Kelly wrote:
On Jul 20 08:08, Jonathan Kelly wrote:
Not. Comes up with error "The application was unable to start
correctly (0xc022).
No, it's not - it compiles and runs as it should when I use the Mingw
directly. It's what I'm using now. I was just trying t
On 20/07/2013 9:00 PM, Corinna Vinschen wrote:
On Jul 20 08:08, Jonathan Kelly wrote:
On 19/07/2013 5:55 PM, Corinna Vinschen wrote:
On Jul 19 11:47, Jonathan Kelly wrote:
Hi,
sorry if this isn't the correct place. I have previously used the
mingw-* packages to create a Windows compile of tcl
On Jul 20 08:08, Jonathan Kelly wrote:
> On 19/07/2013 5:55 PM, Corinna Vinschen wrote:
> >On Jul 19 11:47, Jonathan Kelly wrote:
> >>Hi,
> >>
> >>sorry if this isn't the correct place. I have previously used the
> >>mingw-* packages to create a Windows compile of tcl8.6.0, but
> >>currently it doe
On 19/07/2013 5:55 PM, Corinna Vinschen wrote:
On Jul 19 11:47, Jonathan Kelly wrote:
Hi,
sorry if this isn't the correct place. I have previously used the
mingw-* packages to create a Windows compile of tcl8.6.0, but
currently it doesn't work. It compiles without error as far as I can
see, but
On Fri, Jul 19, 2013 at 3:55 AM, Corinna Vinschen wrote:
> On Jul 19 11:47, Jonathan Kelly wrote:
>> Hi,
>>
>> sorry if this isn't the correct place. I have previously used the
>> mingw-* packages to create a Windows compile of tcl8.6.0, but
>> currently it doesn't work. It compiles without error a
On Jul 19 11:47, Jonathan Kelly wrote:
> Hi,
>
> sorry if this isn't the correct place. I have previously used the
> mingw-* packages to create a Windows compile of tcl8.6.0, but
> currently it doesn't work. It compiles without error as far as I can
> see, but when you try to run the executable (t
Hi,
sorry if this isn't the correct place. I have previously used the
mingw-* packages to create a Windows compile of tcl8.6.0, but currently
it doesn't work. It compiles without error as far as I can see, but when
you try to run the executable (tclsh8.6.0.exe) it returns immediately
with cod
On Apr 12 14:26, michael_mo...@non.agilent.com wrote:
> Version is 1.7.12
>
> ssh-host-config -y was the command I apologize for pasting/posting
> misinformation.
>
> "* Warning: Creating the user 'cyg_server' failed! Reason:
> System error 5 has occurred.
>
> Access is denied.
This happens
On 4/11/2012 9:14 PM, michael_mo...@non.agilent.com wrote:
Several folk here use Cygwin with windows 7 enterprise as a tool to access
linux servers. They have Cygwin with X installed and use a combination of
terminal windows and X exports from the RH servers to manage items.
The most recent v
Several folk here use Cygwin with windows 7 enterprise as a tool to access
linux servers. They have Cygwin with X installed and use a combination of
terminal windows and X exports from the RH servers to manage items.
The most recent version of Cygwin, when upgraded, breaks in these uses. I hav
Pedro Izecksohn wrote:
--- Jacob Jacobson wrote:
Perhaps this went unnoticed. Reposting it. I am still having
problems building cygwin dll. Has anyone seen this error?
Getting close here. Apparently gets to the linking phase. Please help
with error below.
[build$:618] (../src/configure --pref
--- Jacob Jacobson wrote:
> Perhaps this went unnoticed. Reposting it. I am still having
> problems building cygwin dll. Has anyone seen this error?
>
>> > Getting close here. Apparently gets to the linking phase. Please help
>> > with error below.
>> >
>> > [build$:618] (../src/configure --prefix=
Perhaps this went unnoticed. Reposting it. I am still having
problems building cygwin dll. Has anyone seen this error?
Jacob Jacobson wrote:
> >
> > Getting close here. Apparently gets to the linking phase. Please help
> > with error below.
> >
> >
> > [build$:618] (../src/configure --prefix=/c/h
Angelo Graziosi schrieb:
> Have you build Emacs configuring with auto-image-base enabled:
> ...
> See the etc/PROBLEMS.
Thanx Angelo. It looks like this was the problem. I'm really mortified, not to
find it myself.
Steffen
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Prob
Steffen Sledz wrote:
> Nobody an idea what's wrong here? Or how to debug this?
Have you build Emacs configuring with auto-image-base enabled:
LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \
../configure --prefix=${prefix_dir}
and
make LD='$(CC)'
?
See the etc/PROBLE
Steffen Sledz schrieb:
> I've an odd problem building the emacs 22.1 binary without X11 support.
>
> The compiling works without any problems. But in a late stage of the
> build process the new emacs binary is called in batch mode to compile
> some of the lisp files of the distribution. There the
I've an odd problem building the emacs 22.1 binary without X11 support.
The compiling works without any problems. But in a late stage of the
build process the new emacs binary is called in batch mode to compile
some of the lisp files of the distribution. There the process hangs.
I checked the new
Marcus,
> That can't work. Makefile.am is the basis for the generated files
> Makefile.in and Makefile, the latter of which is actually used. These
> files are only automatically generated when in maintainer mode.
Yes, your right. I just read about the GNU build system last night and realized
At Mon, 04 Dec 2006 18:42:01 +0900,
"djh" <[EMAIL PROTECTED]> wrote:
>
> here are the results I get from using everthing in:
>
> * gpgme-1.0.3.tar.gz
>
> with the exceptipn of Makefile.am, which I used the new 1192 revision
> Makefile.am
> which was mv'd to Makefile.am for the following:
T
Marcus,
thanks for your efforts.
> Anyway, I have changed GPGME in SVN HEAD to not use a non-installed
> library at all. This should fix the problem as well. It would be
> good if someone tested out if that is indeed the case.
>
> Thanks,
> Marcus
here are the results I get from using ever
At Thu, 30 Nov 2006 22:17:23 -0600,
"Yaakov S (Cygwin Ports)" <[EMAIL PROTECTED]> wrote:
> > Then, GPGME builds the final library from the thread module, adding
> > the non-installed libgpgme-real.la to the bundle via LIBADD.
> >
> > Ok, that's not really clean. The problem is that now the order
At Fri, 01 Dec 2006 13:09:32 +0900,
"djh" <[EMAIL PROTECTED]> wrote:
>
>
> Thanks again for your response.
>
> > From: Marcus Brinkmann <[EMAIL PROTECTED]>
> > ...Shared library support various dramatically across platforms. Libtool
> > tries its best to patch it up and give a consistent pictur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcus Brinkmann wrote:
> I gave it another look, and it seems to me that the problem could be
> the following: GPGME tries to build versions of GPGME linking against
> pthread and pth. These versions are built from a version of the
> library without
Thanks again for your response.
> From: Marcus Brinkmann <[EMAIL PROTECTED]>
> ...Shared library support various dramatically across platforms. Libtool
> tries its best to patch it up and give a consistent picture, but it
> can not always provide.
>
>
> I gave it another look, and it seem
At Fri, 01 Dec 2006 11:32:35 +0900,
"djh" <[EMAIL PROTECTED]> wrote:
>
> libtool has been cygwin aware for several years and I've had no problems with
> it building many shared libraries. (Except for example, GMP in which they
> assumed possibly too much in libtool and was forced to explicity u
Thanks for your repsonse Marcus.
> From: Marcus Brinkmann (GPGME member)
> From: Henman: I have run into a build problem on cygwin system.
> >
> >
> > I am not an expert in the utilities used to build gpgme. But, wonder why a
> > library seems to be missing.
On 13 November 2006 22:23, Brian Dessent wrote:
> In file included from
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windef.h:246,
> from
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windows.h:48,
> from
>
C:/Eclipse_Workspace/A
"Patrick D. McAvoy" wrote:
> I am having a problem with BUILDing a fairly large C++ DLL using Cygwin
> under Eclipse. I am running Windows XP Media Edition. My Eclipse Project
> Name is: Analyzer_General
(Build is not an acronym, there's no need to shout.)
> My application source code seems to b
Dave Korn wrote:
On 03 October 2006 22:06, Michael Eager wrote:
You mentioned '%' signs in environment variables and VPATH. Bash and make
use a '$' to indicate a variable, and make uses '%' to indicate a
pattern-matching rule. You're always going to give make a hard time, because
if it se
On 03 October 2006 22:06, Michael Eager wrote:
> Dave Korn wrote:
> I looked for make-3.80. I didn't find it in a cygwin repo,
> but there was a link on mozilla.org to binaries. I installed
> these binaries for make-3.80.
>
> Building gcc using the mozilla version of make-3.80 fails
> as previ
Michael Eager wrote:
[snip]
Building gcc using the mozilla version of make-3.80 fails
as previously described. I assumed that this version of
make was the same as the one which I previously installed.
Apparently, it isn't or there is some other incompatibility.
Sounds like that might be a MinG
Dave Korn wrote:
On 03 October 2006 20:27, Michael Eager wrote:
Dave Korn wrote:
On 03 October 2006 03:10, Michael Eager wrote:
It looks like make is not recognizing VPATH correctly.
I'm using make-3.80-1.
This is unlikely. Gcc is known to build on cygwin. I do it all the time
and it has
On 03 October 2006 20:27, Michael Eager wrote:
> Dave Korn wrote:
>> On 03 October 2006 03:10, Michael Eager wrote:
>
>>> It looks like make is not recognizing VPATH correctly.
>>> I'm using make-3.80-1.
>>
>> This is unlikely. Gcc is known to build on cygwin. I do it all the time
>> and it
Michael Eager wrote:
Dave Korn wrote:
On 03 October 2006 03:10, Michael Eager wrote:
It looks like make is not recognizing VPATH correctly.
I'm using make-3.80-1.
This is unlikely. Gcc is known to build on cygwin. I do it all
the time and it has no problem for me. Perhaps something else is
Dave Korn wrote:
On 03 October 2006 03:10, Michael Eager wrote:
It looks like make is not recognizing VPATH correctly.
I'm using make-3.80-1.
This is unlikely. Gcc is known to build on cygwin. I do it all the time
and it has no problem for me. Perhaps something else is underlying.
I'v
On 03 October 2006 03:10, Michael Eager wrote:
> This might be the wrong mailing list (I couldn't find
> a list for make), but I hope that folks might have an
> answer/explanation.
>
> I'm getting an error building gcc on Cygwin.
> Specifically, the make in libcpp fails, saying
> that it cannot f
This might be the wrong mailing list (I couldn't find
a list for make), but I hope that folks might have an
answer/explanation.
I'm getting an error building gcc on Cygwin.
Specifically, the make in libcpp fails, saying
that it cannot find a rule to make po/be.gmo
which is needed by target 'all'.
> From: Brian Dessent
> Sent: Tuesday, August 22, 2006 6:30 PM
> Subject: Re: A build problem of C++ code on Cygwin
>
> Brian Dessent wrote:
>
> > I've seen this a million times. It's a makefile that doesn't know
> > about $EXEEXT and assumes th
Brian Dessent wrote
> Indeed. The attached patch (and then re-running automake at the
> top-level) causes the build to work correctly -- or at least get past
> the problem you reported, I don't feel like waiting for the full build.
Hi Brian,
many thanks for the patch, I have sent it to LiDIA
Brian Dessent wrote:
> I've seen this a million times. It's a makefile that doesn't know about
> $EXEEXT and assumes that executables have no extension. Because of this
> one of the stock built-in make rules gets invoked instead of the proper
> link command. Look in the Makefile for the rule th
Angelo Graziosi wrote:
> It tries to build C++ with gcc:
>
> gcc bytes_to_int_flag_generator.o -o bytes_to_int_flag_generator
>
> ...
> So the question is : what could be the cause of this different behaviour ?
>
I've seen this a million times. It's a makefile that doesn't know about
$E
I want to flag the following problem occurred on Cygwin BUT NOT on Linux.
===
I have tried to build LiDIA (A C++ Library For Computational Number
Theory, http://www.informatik.tu-darmstadt.de/TI/LiDIA/) library on
Cygwin.
After the
> It sounds more like memory corruption problem to me.
> It may be in cygwin
> itself or in cygwin's version of make. When you use
> longer paths, some
> static buffers or allocated memory seem to be
> overwritten which may
> cause such behaviour.
Ah, ok.
> It would be interesting to check if
Tero Niemela wrote:
Egor, hi,
I'm having a build problem of BusyBox-1.00 on Cygwin
and I think I've tracked the origin of it being
related to a change you've contributed to BusyBox (1).
Specifically, when building BusyBox, its top-level
Makefile include a huge amount of Makefile.in
hi,All
i have successfully build arm cross tool chain (gcc3.3.2 glibc 2.3.2
gdb6.0)on cygwin.but when i tried to build insight 6.0, in the make
procedure, i encounter some problems(please see attachment),anyone can help
me?
begin 666 make.log
M0V]N9FEG=7)I;F<@:6X@;&EB:6)E[EMAIL PROTECTED]'[EMAIL
Hi,
We are in the process of building a crossgcc for "i386-linux" on cygwin.
Following are ok:
- binutils-2.12
- gccbootstrap - 2.95.4
while compiling the glibc-2.2.5,with the following configuration, we are
getting the errors attached. If you have come across this issue, please let
us know
On Wed, Jan 29, 2003 at 01:45:20PM +0100, Eric de Jong wrote:
>I tried to compile the gdb-20030128-1 sources from cygwin for the
>arm-unknown-elf target:
>
>mkdir /usr/src/build/gdb-20030128
>cd /usr/src/build/gdb-20030128
>../../gdb-20030128-1/configure --target=arm-unknown-elf
>make
>
>Make fails
Hello,
I tried to compile the gdb-20030128-1 sources from cygwin for the
arm-unknown-elf target:
mkdir /usr/src/build/gdb-20030128
cd /usr/src/build/gdb-20030128
../../gdb-20030128-1/configure --target=arm-unknown-elf
make
Make fails when linking gdb.exe, the linker gives "undefined reference to
I'm running into a problem build ing the current cygwin source on my XP
SP1 machine. I have 1 gig of RAM (700 meg free when starting the build),
and 4 gigs of free HD space. When it first failed, I ran the Cygwin setup
and got updated packages. Same problem, even with the updated packages.
The fir
On Wed, Sep 18, 2002 at 03:22:05PM -0400, Jason Tishler wrote:
> Any suggestions on how to best fix this build problem will be greatly
> appreciated?
It appears that I can workaround the problem by executing:
$ aclocal
$ autoconf
before doing the normal GNU build pro
# define _nl_domain_bindings _nl_domain_bindings__
#endif
The above explains why Cygwin's libintl is exposing symbols with
trailing "__" characters.
Any suggestions on how to best fix this build problem will be greatly
appreciated?
Thanks,
Jason
--
Unsubscribe info: htt
54 matches
Mail list logo
