Message-ID: <483B7138.2070100@cs.cmu.edu>
Date: Mon, 26 May 2008 19:26:00 -0700
From: Paul Newell <pnewell AT cs DOT cmu DOT edu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: pnewell AT cs DOT cmu DOT edu
Subject: Re: cygwin1.dll incluson in Cygwin makefile
References: <483A64DE DOT 3020607 AT cs DOT cmu DOT edu> <483A85DF DOT 1510038B AT dessent DOT net>
In-Reply-To: <483A85DF.1510038B@dessent.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Brian:

Thanks for the response. Why it didn't dawn on me that the PATH on the 
Windows box needed updating is beyond me, I think I got so lost in the 
details that I just plain stopped thinking. And, of course, that made a 
huge difference (once I learned that autoexec.bat is no longer used in 
XP ...).

Have to admit that I did have to spend alot of time trying to understand 
the POSIX vs. Windows stuff and not really certain if I truly understand 
the conversions back and forth, but that's my problem to go educate 
myself on.

My one question I do want to ask is I still can't cleanly issue a system 
call to "cmd" from my cygwin program that uses "C:\". It just seems to 
not understand that. I looked at mount, I looked at cygpath, I looked at 
cygdrive, I went through FAQs and old email postings via Googling the 
subject. I even found a 20sep04 posting from you about why cmd might not 
be properly flushing output.

The best I can see is that I can issue the following from my home 
directory in cygwin:

cmd /c dir "..\..\.."

but something like

cmd /c dir "c:\"

just generates a shell that I have to controlC out of (other variants 
caused me to find you 2004 posting when I had to hit enter a second time).

Using relative path upwards seems like a bad hack. Any clue as to what I 
am missing as I try to express Windows paths and cmds in a "system" call 
from a cygwin compiled program? If I missed it on the FAQ and user/API 
guide, my apologies. If this is an abuse of this mailing list to ask 
what might be very naive questions, let me know and I will gladly refrain.

As for distributing my code ... that isn't the intent at all. This is 
nothing more than trying to learn for myself how to make better use of 
cygwin for personal uses. I've been using cygwin since the Win98se days 
but always in a very limited form and always running a Borland compiler 
on the Win98 machine. I'm trying to teach myself what I need to know to 
just run cygwin on Windows and Fedora / RedHat on Linux ... skipping 
Windows compilers altogether.

And, yes, I did know it I was posting to a mailing list, but the line in 
the Welcome message of "Welcome to cygwin AT cygwin DOT com!" felt like I was 
sending it to a pretty global address within cygwin ... it was an 
attempt on my part to apologize in advance if it turned into an 
accidental spam if I was using the wrong link.

Thanks,
Paul


Brian Dessent wrote:
> Paul Newell wrote:
>
>   
>> Quite simply, I installed the current cygwin today, it did a wonder job
>> of running make on a c/c++ file and produce an *.exe. However, if I open
>> up a window to the directory and try to double click it, I get the "no
>> cygwin1.dll". If I try to run the program within cygwin's world, it
>> doesn't know anything more about the universe as it seems to only
>> understand its local space within "home". I tried to figure out how to
>> link in cygwin1.dll, but the compile says it can't find it even if I
>> give absolute path within the cygwin world.
>>     
>
> If you build a program with Cygwin's gcc, it is a Cygwin program,
> meaning it is linked with cygwin1.dll and is dependant on that library
> for POSIX emulation.  The library must be in the PATH or in the same
> directory as the .exe, the same as with any library.  There is nothing
> magical about the "cygwin world", simply the fact that /usr/bin (i.e.
> the location of cygwin1.dll) is added to PATH in the startup files that
> the shell executes.  There's no reason that you can't do that yourself.
>
> There is no way for a Cygwin program to not depend on cygwin1.dll; it
> cannot be statically linked.  This is explained in the FAQ.  
>
>   
>> Maybe I am trying to do something I shouldn't be doing. The program is
>> designed to scan the entire drive an give an html of the contents. So I
>> need to build an executable within Cgywin that I can run globally within
>> Windows universe.
>>     
>
> You can distribute the Cygwin library with your program, or you can use
> something else use such as MinGW.  You can't get POSIX compatibility
> without also depending on the Cygwin library, however.  And also
> remember that if you choose to distribute your code as a Cygwin app then
> you must obey the Cygwin licensing rules.
>
>   
>> Any advice / education is appreciated. Sorry if this is longer email
>> than it should be, but I'm a newbie and I have no idea where is email is
>> going (though I will probably find out soon enough)
>>     
>
> It's called a mailing list, read <http://cygwin.com/cygwin/lists.html>.
>
> Brian
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>
>   


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/