Re: Entry point not found issues with cygwin DLLs

On 2018-07-02 14:36, Heavenly Avenger wrote: > On 7/2/2018 5:02 PM, Brian Inglis wrote: >> On 2018-07-02 13:35, Ken Brown wrote: >>> On 7/2/2018 3:08 PM, Heavenly Avenger wrote: I'm having hard times with cygwin here, random libraries stop working once I update or install new ones.

Re: Entry point not found issues with cygwin DLLs

On 2018-07-02 13:35, Ken Brown wrote: > On 7/2/2018 3:08 PM, Heavenly Avenger wrote: >> I'm having hard times with cygwin here, random libraries stop working once I >> update or install new ones. > This can happen if you update a package without updating its dependencies.  > For > example, the dep

Re: Entry point not found issues with cygwin DLLs

On 7/2/2018 3:08 PM, Heavenly Avenger wrote: I'm having hard times with cygwin here, random libraries stop working once I update or install new ones. This can happen if you update a package without updating its dependencies. For example, the dependency might have introduced a new API. If I

Fwd, Solved: Entry point not found issues with cygwin DLLs

Forwarded Message Subject: Entry point not found issues with cygwin DLLs Date: Mon, 2 Jul 2018 16:08:06 -0300 From: Heavenly Avenger To: cygwin@cygwin.com Hello! First post in the list, I hope I am not mistaken in the place to post the question, but let's give

Entry point not found issues with cygwin DLLs

Hello! First post in the list, I hope I am not mistaken in the place to post the question, but let's give it a try. I'm having hard times with cygwin here, random libraries stop working once I update or install new ones. Today I run 'rebaseall' and it detected a lot of completely missing DL

Re: Cygwin DLLs being modified somehow?

Greetings, Michael DePaulo! >> I have a counter-question. Any objection you have to distribute your >> application as part of Cygwin infrastructure? >> You can still keep your NSIS installer, assuming you change it to download >> appropriate setup.exe, and you could offer an option to make portabl

Re: Cygwin DLLs being modified somehow?

On Mon, Feb 23, 2015 at 1:21 PM, Andrey Repin wrote: > Greetings, Michael DePaulo! > >> I found this too: >> http://cygwin.wikia.com/wiki/Rebaseall > >> However, this leads to a another question. On the X2Go project, we >> compile nxproxy, a 3rd-party piece of software that we are now >> maintaini

Re: Cygwin DLLs being modified somehow?

Greetings, Michael DePaulo! > I found this too: > http://cygwin.wikia.com/wiki/Rebaseall > However, this leads to a another question. On the X2Go project, we > compile nxproxy, a 3rd-party piece of software that we are now > maintaining, against Cygwin. We also recompile Cygwin OpenSSH with an >

Re: Cygwin DLLs being modified somehow?

On Sun, Feb 22, 2015 at 10:31 PM, René Berber wrote: > On 2/22/2015 7:53 PM, Michael DePaulo wrote: > >> I am seeing very weird behavior and I am hoping that someone can explain it. >> >> This happens on 2 different machines. My personal Windows 10 64-bit >> machine, and a Windows 7 64-bit VM host

Re: Cygwin DLLs being modified somehow?

Greetings, Michael DePaulo! > I am seeing very weird behavior and I am hoping that someone can explain it. > This happens on 2 different machines. My personal Windows 10 64-bit > machine, and a Windows 7 64-bit VM hosted by the X2Go project on > another continent. > It seems to be happening to m

Re: Cygwin DLLs being modified somehow?

On 2/22/2015 7:53 PM, Michael DePaulo wrote: > I am seeing very weird behavior and I am hoping that someone can explain it. > > This happens on 2 different machines. My personal Windows 10 64-bit > machine, and a Windows 7 64-bit VM hosted by the X2Go project on > another continent. > > It seems

Cygwin DLLs being modified somehow?

I am seeing very weird behavior and I am hoping that someone can explain it. This happens on 2 different machines. My personal Windows 10 64-bit machine, and a Windows 7 64-bit VM hosted by the X2Go project on another continent. It seems to be happening to multiple DLLs, but I will list one examp

Re: Cygwin dlls for Windows XP SP3

On 11/20/2014 12:40 PM, Alexander Plotkin wrote: Hi! I'm searching for libraries cygblas.dll, cyglapack-0.dll, cyggfortran-3.dll compatible with Windows XP SP3 and so far I've failed - all versions seem to be for 64-bit OS only. Will greatly appreciate any help! Regards Alexander P. what do

Cygwin dlls for Windows XP SP3

Hi! I'm searching for libraries cygblas.dll, cyglapack-0.dll, cyggfortran-3.dll compatible with Windows XP SP3 and so far I've failed - all versions seem to be for 64-bit OS only. Will greatly appreciate any help! Regards Alexander P. -- Problem reports: http://cygwin.com/problems.html FA

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 11/28/2012 9:42 AM, Massi wrote: 2012/11/27 marco atzeri : it seems to build fine. Steps ./autogen.sh ./configure make -f GNUmakefile |& tee -a make.log not for me .. I always get the same error(s): 0 [main] sh 143568 child_info_fork::abort: can't commit memory for stack 0x289000(

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

2012/11/27 marco atzeri : > it seems to build fine. > Steps > ./autogen.sh > ./configure > make -f GNUmakefile |& tee -a make.log not for me .. I always get the same error(s): 0 [main] sh 143568 child_info_fork::abort: can't commit memory for stack 0x289000(94208), Win32 error 487 /home/al

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 11/27/2012 10:43 AM, Massi wrote: 2012/11/27 marco atzeri : As you have a problem building gdal, you should start a new thread, not reusing the previous one. well OK, I believe this is related to the fork problem, not the particular task one is performing. anyways: This gdal package look

Was: Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 27/11/2012 4:43 AM, Massi wrote: 2012/11/27 marco atzeri : As you have a problem building gdal, you should start a new thread, not reusing the previous one. well OK, I believe this is related to the fork problem, not the particular task one is performing. fork() problems in cygwin are like

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

2012/11/27 marco atzeri : > As you have a problem building gdal, you should start a new thread, > not reusing the previous one. well OK, I believe this is related to the fork problem, not the particular task one is performing. anyways: > This gdal package looks strange. After running configure I

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 11/27/2012 8:27 AM, Massi wrote: Hi all, let me post details about my problem while compiling gdal-1.9.2 under cygwin. here is my uname -a output: CYGWIN_NT-6.1-WOW64 ventress 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin I am using windows 7 pro on a lenovo T530 laptop. I removed (almost!

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 11/26/2012 5:33 PM, Piren wrote: Hi I've been using Cygwin for a while and everything was working fine. i've updated Cygwin to the latest version s 1.7.17-1. and even since i'm unable to use it anymore. I'm getting this message shown on every start of cygwin and it never becomes operational:

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

Hi all, let me post details about my problem while compiling gdal-1.9.2 under cygwin. here is my uname -a output: CYGWIN_NT-6.1-WOW64 ventress 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin I am using windows 7 pro on a lenovo T530 laptop. I removed (almost!) all unnecessary software from the pr

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

holy fuck... i was wondering about the address being like that myself, but thats what it did by default, so whenever i tried rebasing i kept it in the same address range this is the current address after i used your starting location /usr/bin/cygiconv-2.dll base 0x48bd size 0x0

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

Wow... double dose of TOFU On 26/11/2012 3:37 PM, Massi wrote: I have the very same problem, not at startup, but when compiling a few packages. Killing all the windows aplications and processes would help with some packages, but not all. Which makes cygwin completely useless. What does the out

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 26/11/2012 3:34 PM, Christopher Faylor wrote: On Mon, Nov 26, 2012 at 03:11:50PM -0500, Ryan Johnson wrote: On 26/11/2012 2:47 PM, Piren wrote: Thanks for the response Ryan I'm seeing the same issues no matter what runs on Windows, it does the same even in Safe Mode. Also, this issue only s

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

I have the very same problem, not at startup, but when compiling a few packages. Killing all the windows aplications and processes would help with some packages, but not all. Which makes cygwin completely useless. Massi 2012/11/26 Ryan Johnson : > On 26/11/2012 2:47 PM, Piren wrote: >> >> Thanks

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On Mon, Nov 26, 2012 at 03:34:36PM -0500, Christopher Faylor wrote: >On Mon, Nov 26, 2012 at 03:11:50PM -0500, Ryan Johnson wrote: >>On 26/11/2012 2:47 PM, Piren wrote: >>> Thanks for the response Ryan >>> >>> I'm seeing the same issues no matter what runs on Windows, it does the >>> same even in S

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On Mon, Nov 26, 2012 at 03:11:50PM -0500, Ryan Johnson wrote: >On 26/11/2012 2:47 PM, Piren wrote: >> Thanks for the response Ryan >> >> I'm seeing the same issues no matter what runs on Windows, it does the >> same even in Safe Mode. Also, this issue only started once i updated >> to the new Cygwi

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

On 26/11/2012 2:47 PM, Piren wrote: Thanks for the response Ryan I'm seeing the same issues no matter what runs on Windows, it does the same even in Safe Mode. Also, this issue only started once i updated to the new Cygwin version and my windows configuration/installed apps did not change. ATM

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

Thanks for the response Ryan I'm seeing the same issues no matter what runs on Windows, it does the same even in Safe Mode. Also, this issue only started once i updated to the new Cygwin version and my windows configuration/installed apps did not change. ATM Cygwin is completely non functional, i

Re: cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

Hi Uri, On 26/11/2012 11:33 AM, Piren wrote: Hi I've been using Cygwin for a while and everything was working fine. i've updated Cygwin to the latest version s 1.7.17-1. and even since i'm unable to use it anymore. I'm getting this message shown on every start of cygwin and it never becomes ope

Re: cygwin dlls needed to run binutils

On 24/11/2011 7:07 AM, Dave Korn wrote: On 23/11/2011 16:59, Ryan Johnson wrote: On 23/11/2011 11:47 AM, Surrounder wrote: Larry Hall (Cygwin) wrote: A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but per

Re: cygwin dlls needed to run binutils

On 23/11/2011 16:59, Ryan Johnson wrote: > On 23/11/2011 11:47 AM, Surrounder wrote: >> Larry Hall (Cygwin) wrote: >>> A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a >>> dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but >>> perhaps another tool from the p

Re: cygwin dlls needed to run binutils

On 23/11/2011 11:47 AM, Surrounder wrote: Larry Hall (Cygwin) wrote: A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but perhaps another tool from the package pulls that one in. I found out that the needed

Re: cygwin dlls needed to run binutils

ygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > > -- View this message in context: http://old.nabble.com/cygwin-dlls-needed-to-run-bin

Re: cygwin dlls needed to run binutils

On 11/23/2011 10:37 AM, Surrounder wrote: I compiled binutils within cygwin 1.7.9-1 and was wondering why I not only need the cygwin1.dll to run them under windows, I also need the cygz.dll and the cyggcc_s-1.dll Last time I compiled only cagwin1.dll was necessary. Anybody knows if I do sth. wr

cygwin dlls needed to run binutils

response. Surrounder -- View this message in context: http://old.nabble.com/cygwin-dlls-needed-to-run-binutils-tp32874201p32874201.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com

cygwin dlls needed to run binutils

response. Surrounder -- View this message in context: http://old.nabble.com/cygwin-dlls-needed-to-run-binutils-tp32874200p32874200.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com

Re: Updated cygwin dlls cause unnecessary reboot on NT

Eric Blake wrote: This part peaks my curiosity. Now I'm not a kernel guy however as you state fork currently knows which dlls to load for the child by name. While that makes sense on the outside what if it knew which dlls to load by number - by open file descriptor number that is? If only Windo

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Wed, Dec 27, 2006 at 10:18:37PM -0700, Eric Blake wrote: >> Another question, how is this not a problem for Unix's fork()? Does >> Unix's fork also do this by name? Or does it use another mechanism? > >Unix's fork is provided natively by the kernel, using copy-on-write >semantics. It is an enti

Re: Updated cygwin dlls cause unnecessary reboot on NT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andrew DeFaria on 12/27/2006 7:17 PM: > Eric Blake wrote: >> Actually, you are. The ONLY way to make renaming in-use .dlls work is >> to make fork() aware of the rename. The way fork() works is that it >> must reload the same .dll as the

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Wed, Dec 27, 2006 at 08:22:50PM -0600, Andrew DeFaria wrote: >Christopher Faylor wrote: >>On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote: >>>Igor Peshansky wrote: Open-source works by scratching your itch, not by getting someone else to scratch it for you. >>>Actually ge

Re: Updated cygwin dlls cause unnecessary reboot on NT

Andrew DeFaria wrote: Christopher Faylor wrote: On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote: Igor Peshansky wrote: Open-source works by scratching your itch, not by getting someone else to scratch it for you. Actually getting someone else to scratch that itch sometimes does

Re: Updated cygwin dlls cause unnecessary reboot on NT

Christopher Faylor wrote: On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote: Igor Peshansky wrote: Open-source works by scratching your itch, not by getting someone else to scratch it for you. Actually getting someone else to scratch that itch sometimes does work! Right! And, the

Re: Updated cygwin dlls cause unnecessary reboot on NT

Eric Blake wrote: Actually, you are. The ONLY way to make renaming in-use .dlls work is to make fork() aware of the rename. The way fork() works is that it must reload the same .dll as the parent process had loaded, and it currently does this BY NAME. In other words, changing the name of an i

Re: Updated cygwin dlls cause unnecessary reboot on NT

Christopher Faylor wrote: On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote: Igor Peshansky wrote: Open-source works by scratching your itch, not by getting someone else to scratch it for you. Actually getting someone else to scratch that itch sometimes does work! Right! And, th

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote: >Igor Peshansky wrote: >>Open-source works by scratching your itch, not by getting someone else >>to scratch it for you. > >Actually getting someone else to scratch that itch sometimes does work! Right! And, the perfect way to have th

Re: Updated cygwin dlls cause unnecessary reboot on NT

Igor Peshansky wrote: Open-source works by scratching your itch, not by getting someone else to scratch it for you. Actually getting someone else to scratch that itch sometimes does work! :-P -- Andrew DeFaria Never wrestle with a pig. You both get dirty and the pig likes i

Re: Updated cygwin dlls cause unnecessary reboot on NT

Linda Walsh tlinx.org> writes: > > Linda, I think we've reach this point here, unless you're willing to try > > to understand why "fork()" is important to Cygwin. > --- > I am aware of why "fork" is important. Apparently, there is > some impression that I am trying to change fork? I'm not >

Re: Updated cygwin dlls cause unnecessary reboot on NT

Larry Hall (Cygwin) wrote: This can be true. However, to do this effectively, one has to listen and learn as well. Simply restating a point you've made before, if it hasn't already been agreed to, does less to convince and more to polarize. If your points aren't agreed upon by the people you'r

Re: Updated cygwin dlls cause unnecessary reboot on NT

On 12/26/2006, Linda Walsh wrote: The excerpt below is a mere subset of the response but is the only one that raises a point that we haven't already been through at least once in this thread so I wanted to respond to it. Not everyone can be a developer on every piece of software they use. Y

Re: Updated cygwin dlls cause unnecessary reboot on NT

Igor Peshansky wrote: So you are saying Cygwin doesn't properly emulate the POSIX fork semantics. I don't know that this is "critically" important for consideration in this issue. It is. This is the principle of least surprise for the end user. --- Least surprise for "which" end u

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Tue, Dec 26, 2006 at 10:01:53AM -0800, Linda Walsh wrote: >Some people asked me for a "patch". I find that laughable -- I'm sure >it would go the way of the UTF-8 patch that was proposed with code >several months back. The patch would quietly (or noisily) be killed on >the cygwin-patches list

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Tue, 26 Dec 2006, Linda Walsh wrote: > Max Bowsher wrote: > > I believe there is a critical element you have missed. > > In order to perform the rather miraculous emulation of fork(), Cygwin > > needs to reload all the same DLLs that are operating in one process into > > another newly created p

Re: Updated cygwin dlls cause unnecessary reboot on NT

Max Bowsher wrote: I believe there is a critical element you have missed. In order to perform the rather miraculous emulation of fork(), Cygwin needs to reload all the same DLLs that are operating in one process into another newly created process. Updating the DLL files on disk whilst processes a

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Tue, Dec 26, 2006 at 02:38:03PM +, Max Bowsher wrote: >Linda Walsh wrote: >>The fix I proposed has nothing to do with the cygwin1.dll. As has >> been covered previously, since cygwin1.dll and a few other libs are >> part of the cygwin "kernel", special handling may be needed to upgrade

Re: Updated cygwin dlls cause unnecessary reboot on NT

Linda Walsh wrote: >The fix I proposed has nothing to do with the cygwin1.dll. As has > been covered previously, since cygwin1.dll and a few other libs are > part of the cygwin "kernel", special handling may be needed to upgrade > those dll's. What can be fixed is the installation of .exe and

Re: Updated cygwin dlls cause unnecessary reboot on NT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 12/26/2006 4:14 AM: > >Just because something hasn't been tested on unprotected-mode windows > (95, 98, ME) doesn't mean something might not work. Then I will tell you - renaming in-use files on Windows 9x _does not wo

Re: Updated cygwin dlls cause unnecessary reboot on NT

Larry Hall (Cygwin) wrote: On 12/25/2006, Linda Walsh wrote: FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll... and such while cygwin is running and not had a catastrophe as one might have trying to overwrite/update the memory image of a kernel dynamically, so I don't think

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Tue, Dec 26, 2006 at 01:12:30AM -0500, Larry Hall (Cygwin) wrote: >On 12/25/2006, Linda Walsh wrote: >>FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll... and >>such while cygwin is running and not had a catastrophe as one might >>have trying to overwrite/update the memory image of

Re: Updated cygwin dlls cause unnecessary reboot on NT

On 12/25/2006, Linda Walsh wrote: FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll... and such while cygwin is running and not had a catastrophe as one might have trying to overwrite/update the memory image of a kernel dynamically, so I don't think it's quite all the end of the w

Re: Updated cygwin dlls cause unnecessary reboot on NT

Igor Peshansky wrote: And that is exactly the problem -- not the .new suffixes. The way Cygwin is designed, you cannot have two versions of the Cygwin DLL (think of it as the kernel) in use at the same time, no matter what the name is. In Linux, you expect to reboot when upgrading the kernel --

Re: Updated cygwin dlls cause unnecessary reboot on NT

On Mon, 25 Dec 2006, Linda Walsh wrote: > Larry Hall (Cygwin) wrote: > > What the file is named is insignificant. When the file is already in > > use, you will run into the situation where the newly installed file is > > not moved into place for use immediately . > --- >That is current cygwin

Re: Updated cygwin dlls cause unnecessary reboot on NT

Larry Hall (Cygwin) wrote: What the file is named is insignificant. When the file is already in use, you will run into the situation where the newly installed file is not moved into place for use immediately . --- That is current cygwin behavior. It isn't required to be that way on NT.

Re: Updated cygwin dlls don't have the .dll extension; instead have .dll.new

Linda Walsh wrote: Eric Blake wrote: According to Charli Li on 12/24/2006 1:39 PM: Fishy enough, the new dlls had a filename extension of .dll.new Which means Windows is scheduled to rename it automatically at the next reboot, since it was in use at the time you ran setup.exe. Didn't

Re: Updated cygwin dlls don't have the .dll extension; instead have .dll.new

Eric Blake wrote: According to Charli Li on 12/24/2006 1:39 PM: Fishy enough, the new dlls had a filename extension of .dll.new Which means Windows is scheduled to rename it automatically at the next reboot, since it was in use at the time you ran setup.exe. Didn't you read the messag

Re: Updated cygwin dlls don't have the .dll extension; instead have .dll.new

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Charli Li on 12/24/2006 1:39 PM: > Fishy enough, the new dlls had a filename extension of .dll.new Which means Windows is scheduled to rename it automatically at the next reboot, since it was in use at the time you ran setup.exe. Didn't

Updated cygwin dlls don't have the .dll extension; instead have .dll.new

When using setup.exe to update packages that includes dlls (such as cygwin), it installs the dlls, but have a different file extension. When I tried to start up bash after updating packages with new dlls, bash briefly spits out an error saying that it couldn't find cygreadine6.dll. zsh and company

Re: Distributing Cygwin DLLs with my app

Igor Thanks very much for your reply. I appreciate your time and the points you raised. Regards Dave On Thu, 23 Feb 2006, Dave Bryan wrote: I have an application for Windows written in VC++ which spawns the GNU tools GCC, LD, etc. As the GNU programs use the Cygwin DLLs I need those

Re: Distributing Cygwin DLLs with my app

On Thu, 23 Feb 2006, Dave Bryan wrote: > I have an application for Windows written in VC++ which spawns the GNU > tools GCC, LD, etc. As the GNU programs use the Cygwin DLLs I need those > also. Is is possible to distribute just the needed Cygwin DLLs with my > app + GNU tools rat

Distributing Cygwin DLLs with my app

Hi, I have an application for Windows written in VC++ which spawns the GNU tools GCC, LD, etc. As the GNU programs use the Cygwin DLLs I need those also. Is is possible to distribute just the needed Cygwin DLLs with my app + GNU tools rather than the complete Cygwin installation ? There

Re: new cygwin dlls

On Thu, Jan 26, 2006 at 08:11:23AM +0100, Reini Urban wrote: >2006/1/26, Christopher Faylor <[EMAIL PROTECTED]>: >> On Thu, Jan 26, 2006 at 03:39:14AM +, Eric Blake wrote: >> >>Has a fix been found for building emacs on the new cygwin versions 5.19 >> >>and up yet? >> > >> >Yes - browse the lis

Re: new cygwin dlls

2006/1/26, Christopher Faylor <[EMAIL PROTECTED]>: > On Thu, Jan 26, 2006 at 03:39:14AM +, Eric Blake wrote: > >>Has a fix been found for building emacs on the new cygwin versions 5.19 > >>and up yet? > > > >Yes - browse the list archives - the idea is that anywhere that emacs > >uses a non-zer

Re: new cygwin dlls

On Thu, Jan 26, 2006 at 11:43:29AM +0900, djh wrote: > Has a fix been found for building emacs on the new cygwin versions > 5.19 and up yet? > > There is at least one problem with d_ino as you know. I thought you said you'd worked around that (though you didn't share what your actual changes). >

Re: new cygwin dlls

On Thu, Jan 26, 2006 at 03:39:14AM +, Eric Blake wrote: >>Has a fix been found for building emacs on the new cygwin versions 5.19 >>and up yet? > >Yes - browse the list archives - the idea is that anywhere that emacs >uses a non-zero d_ino to mean the entry returned from readdir is valid, >just

Re: new cygwin dlls

> Has a fix been found for building emacs on the new cygwin versions > 5.19 and up yet? Yes - browse the list archives - the idea is that anywhere that emacs uses a non-zero d_ino to mean the entry returned from readdir is valid, just add a small patch to that area of code that treats ALL director

new cygwin dlls

Has a fix been found for building emacs on the new cygwin versions 5.19 and up yet? There is at least one problem with d_ino as you know. An possibly another, since temacs crashes with a stack dump, during bootstrap. cygwin distribution has an early emacs in it. Will it still run on the newer 5

Re: Cygwin Dlls

Ravi Prasad wrote: >I am using cygwin for tinyos. I installed > Tinyos1.1.0 in directory C:\tinyos\ and later upgraded > to 1.1.7. I have installed arm-gcc from > http://www.gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe > > to the directory C:\tinyos\cygwin\arm-gcc\GNUARM > >

Cygwin Dlls

Hi group, I am using cygwin for tinyos. I installed Tinyos1.1.0 in directory C:\tinyos\ and later upgraded to 1.1.7. I have installed arm-gcc from http://www.gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe to the directory C:\tinyos\cygwin\arm-gcc\GNUARM Now the problem starts:

Re: Problems creating "-mno-cygwin" DLLs with libtool.

Charles Wilson wrote: > OTOH, I never have understood why tools insist on including such things as > "-lcygwin" or "-lc" on a linker command line. There's a good reason for libtool to do so, but it escapes me at the moment. Trust Me(tm). Since gcc already includes libcygwin and libgcc and su

Re: Visual Studio & Cygwin dlls

Sangita Mohan wrote: > > I am trying to use the OpenLDAP client library from my VC++ code. > > I downloaded the Cygwin OpenLDAP dlls and header files. I used a utility > called implib32 to generate lib files for the dlls. > > I linked the project to use the OpenLDAP lib files. However it doesn't

Visual Studio & Cygwin dlls

oceed from here. Can someone explain if there is something different to be done when linking cygwin dlls from VC++ code. TIA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.htm

Re: Problems creating "-mno-cygwin" DLLs with libtool.

On Tue, Feb 01, 2005 at 11:02:18PM -0500, Igor Pechtchanski wrote: >On Tue, 1 Feb 2005, Charles Wilson wrote: >>Christopher Faylor wrote: >>>OTOH, I never have understood why tools insist on including such things >>>as "-lcygwin" or "-lc" on a linker command line. >> >>There's a good reason for lib

Re: Problems creating "-mno-cygwin" DLLs with libtool.

On Tue, 1 Feb 2005, Charles Wilson wrote: > Christopher Faylor wrote: > > > OTOH, I never have understood why tools insist on including such things as > > "-lcygwin" or "-lc" on a linker command line. > > There's a good reason for libtool to do so, but it escapes me at the moment. > Trust Me(tm).

Re: Problems creating "-mno-cygwin" DLLs with libtool.

Christopher Faylor wrote: Has it been established that the cygwin version of libtool is *supposed* to handle mingw? I'd be rather surprised if that was a goal. DING! We HAVE a winner! The installed libtool has been configured -- by virtue of the fact that I ran the build in a cygwin environment -

Re: Problems creating "-mno-cygwin" DLLs with libtool HACK (Sorry, Wrong Patch attached : FIXED).

Dave Korn wrote: -Original Message- From: Vladius [mailto:[EMAIL PROTECTED] I have found a solution to hack this issue. 1.Goto usr/autotool/devel/bin/ 2.Open "libtool" file with a text editor(vim). 3.Search for "postdeps" initialisation. ("postdeps=" string) 4.Remove "-lcygwin"

Re: Problems creating "-mno-cygwin" DLLs with libtool HACK.

Dave Korn wrote: -Original Message- From: Vladius [mailto:[EMAIL PROTECTED] I have found a solution to hack this issue. 1.Goto usr/autotool/devel/bin/ 2.Open "libtool" file with a text editor(vim). 3.Search for "postdeps" initialisation. ("postdeps=" string) 4.Remove "-lcygwin"

Re: Problems creating "-mno-cygwin" DLLs with libtool.

On Tue, Feb 01, 2005 at 06:15:50PM -, Dave Korn wrote: >> -Original Message- >> From: cygwin-owner On Behalf Of Christopher Faylor >> Sent: 01 February 2005 17:27 > >> Has it been established that the cygwin version of libtool is *supposed* >> to handle mingw? I'd be rather surprised i

RE: Problems creating "-mno-cygwin" DLLs with libtool.

> -Original Message- > From: cygwin-owner On Behalf Of Christopher Faylor > Sent: 01 February 2005 17:27 > Has it been established that the cygwin version of libtool is *supposed* > to handle mingw? I'd be rather surprised if that was a goal. Nope, I just assumed that it could be made

RE: Problems creating "-mno-cygwin" DLLs with libtool HACK.

> -Original Message- > From: Vladius [mailto:[EMAIL PROTECTED] > I have found a solution to hack this issue. > 1.Goto usr/autotool/devel/bin/ > 2.Open "libtool" file with a text editor(vim). > 3.Search for "postdeps" initialisation. ("postdeps=" string) > 4.Remove "-lcygwin" initialis

Re: Problems creating "-mno-cygwin" DLLs with libtool.

On Tue, Feb 01, 2005 at 03:56:17PM -, Dave Korn wrote: >> -Original Message- >> From: cygwin-owner On Behalf Of Max Bowsher >> Sent: 01 February 2005 15:35 > >> Vladius wrote: > >> >As U can see... it automatically passes -lcygwin flag to the >> > linker(g++). When cygcheck'ing resu

Problems creating "-mno-cygwin" DLLs with libtool HACK.

Vladius wrote: I have problems compiling DLLs with -mno-cygwin flag, using libtool. Command is: libtool --mode=link --tag=CXX g++ -rpath /Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la common.lo Output: rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai g++ -share

RE: Problems creating "-mno-cygwin" DLLs with libtool.

> -Original Message- > From: cygwin-owner On Behalf Of Max Bowsher > Sent: 01 February 2005 15:35 > Vladius wrote: > >As U can see... it automatically passes -lcygwin flag to the > > linker(g++). When cygcheck'ing resulting DLL it lists > cygwin DLL as one > > of its dependencies. >

Re: Problems creating "-mno-cygwin" DLLs with libtool.

Vladius wrote: I have problems compiling DLLs with -mno-cygwin flag, using libtool. Command is: libtool --mode=link --tag=CXX g++ -rpath /Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la common.lo Output: rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai g++ -shared

Problems creating "-mno-cygwin" DLLs with libtool.

I have problems compiling DLLs with -mno-cygwin flag, using libtool. Command is: libtool --mode=link --tag=CXX g++ -rpath /Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la common.lo Output: rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai g++ -shared -nostdlib /usr/

Re: Renaming Cygwin DLLs

On Jan 6, 2005, at 12:09 PM, Mike Disbrow wrote: On Wed, Jan 05, 2005 at 03:58:39PM -0600, Mike Disbrow wrote: >I'd like to build the supporting Cygwin DLLs to be renamed to something >other than cyg*.dll (e.g. cygwin1.dll to foo.dll), what is the best >way to build the DLLs with d

Re: Renaming Cygwin DLLs

On Wed, Jan 05, 2005 at 03:58:39PM -0600, Mike Disbrow wrote: >I'd like to build the supporting Cygwin DLLs to be renamed to something >other than cyg*.dll (e.g. cygwin1.dll to foo.dll), what is the best >way to build the DLLs with different names? May I ask why you want to do

Re: Renaming Cygwin DLLs

On Wed, Jan 05, 2005 at 03:58:39PM -0600, Mike Disbrow wrote: >I'd like to build the supporting Cygwin DLLs to be renamed to something >other than cyg*.dll (e.g. cygwin1.dll to foo.dll), what is the best >way to build the DLLs with different names? May I ask why you want to do

Renaming Cygwin DLLs

I'd like to build the supporting Cygwin DLLs to be renamed to something other than cyg*.dll (e.g. cygwin1.dll to foo.dll), what is the best way to build the DLLs with different names? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwi

Re: Kannel & cygwin dlls

> > I've redirected this to the cygwin mailing list. > > Sorry YA I get made to look stupid...by myself that is :-) I sent my > reply to this to [EMAIL PROTECTED] . > > Is Cywgin a new project at Red Hat then, Chris? ;-) > > > Regards, > > Elfyn McBratney > [EMAIL PROTECTED] > www.exposure.org.

  1   2   >