> Redirecting this, too.
>
> On Sun, Dec 15, 2002 at 03:18:00PM -0800, Paul G. wrote:
> >Well, if your Win32 system doesn't support links (NT4 shortcuts), this
> >isn't really surprising.
>
> Did you actually read this email or were you just scanning for keywords
> like the word "link"?
Heh, nice bait...but I won't bite...seems like you're not in a good mood right
now...
>
> >NT4 has a shortcut/link capabilities that Me/Win9x do not. The same
> >capability is built-in to Win2k and WinXP (ie. Pro -- can't speak for
> >Home version -- indications, however, are that XP Home also does not
> >support the shortcut/link capabilities that XP Pro does).
>
> For the record: 1) Cygwin handles symlinks just fine and 2) this has
> nothing to do with symlinks.
I know that, you know that. I am sure you have noticed that there are
shortcut files being
used in the nt4 environment sans .lnk, right? (absolute reference:
"d:\cygwin\usr\i686-pc-
mingw32").
Had it occurred to anyone that maybe the XP version of the NT4 .lnk files
("shortcuts")
might not be identical?
One thing is certain, the shortcut files for Win9x/Me are not the same as the
shortcut
files used for NT4. That might indicate a similar problem in terms of XP shortcuts
(Pro vs.
Home) when compared with NT4 shortcuts. Nope, not saying that there is a similar
problem
between NT4 and XP (Pro or Home). Only saying that it is a possibility.
Now, perhaps, someone else on this list will be able to determine if the
shortcut files for
XP Home, XP Pro and NT4 are in fact identical or not. I can not since I do not have
XP
(Home or Pro).
>
> >It sounds like you have come up with a work around, but it is not
> >recommended to hack cygwin like that as it tends to make it unreliable.
>
> He didn't actually have a workaround. It wasn't working.
I know that, you know that.
If it were working, he would not have reported a problem in the first place,
right? Clearly
he "thought" it was a workaround. You and I both know that it was not working...
For the record then, I was simply stating a fact, or, if you will, what is
typically "common
sense" to me...do not mess with specs or "path' related stuff, etc. unless you are
d*mn sure
you know what the h*ll you are doing. Correct?
>
> >Solution? Upgrade OS or download and install Msys (Cygwin-like,
> >actually a fork of Cygwin, which does not depend on the cygwin .dll).
> >Caveat, Mingw does not support a great deal of posix, niether does
> >Msys...yet.
>
> Suggesting that someone run something else to solve a cygwin
> installation problem is not appropriate. Since you clearly don't
> understand how cygwin's gcc works, please don't offer advice on solving
> problems. You're just going to end up confusing people.
Where did he ever say it was an installation problem?
From the original post that I saw from the person:
> Someone broke GCC somewhere....
>
> echo 'int main( void ) { return 1; }' >test.c
> gcc -mno-cygwin -c test.c
>
> results:
> gcc: installation problem, cannot exec `cc1': No such file or directory
meaning: gcc could not find cc1.exe.
Anyone who has any idea as to how Cygwin gcc works knows that under normal
installation, within the following directory:
mycygwinroot/lib/gcc-lib/i686-pc-cygwin/3.2
is where you will find cc1.exe.
cc1.exe does not exist under any other directory.
The same folks, ie. those who have any idea as to "how" Cygwin gcc works also
knows
that gcc.exe is defined within the "mycygwinroot/bin". gcc.exe does not exist
anywhere else
(possible exception: symlink).
(I really don't think I need to say, yet again, "you know this. I know this.")
Now, why else might the search for cc1.exe fail if specs is left alone and
nothing is done
to change the pathing sequence?
>
> there is definatly no cc1 with gcc 3.2 (not sure where it went, but...)
This is patently untrue, except possibly on his system.
Original poster of this rather noisome thread did not even note why he was
trying to use -
mno-cygwin in the first place. To paraphrase a certain illustrious comrade:
"provide.. useful details (cygcheck output would be nice)..."
doing so, on the part of the questioner (as OT and offlist as the posters
original email
was) would have at least narrowed the scope of the problem as well as provide details
to
determine if there was even a problem to begin with, right?
>
> It seems like neither you or Jim is approaching this from the direction
> of "It seems to be working for other people. I wonder what could be
> wrong with this installation".
My assumption is that some install is always working, and any problems that do
come up
are typically directly contributable to what that same illustrious comrade I
referenced earlier
also said in another post, "cockpit error".
> Instead, Jim is ripping his installation
> apart under the assumption that everything is broken and (apparently)
> he's the first person to notice it and you're misreading his email and
> suggesting that he run something else without clearly understanding what
> the problem could be.
>
> I'll say it again: Install the gcc-mingw package. It's really simple.
> It's so simple that it is the default for gcc installation.
You know that and I know that.
Does everyone know, however, what exactly is necessary for building c language
apps
that do not rely on Cygwin .dll? At least one person doesn't, otherwise this thread
wouldn't
even be here right now, would it?
People are niether as dumb or as smart as most people like to believe that
they are. It is
nice, however, if you can assume that someone is as smart as you are when it comes to
Cygwin, right?
Unfortunately, most people do not know anywhere near as much as my illustrious
comrade does when it comes to Cygwin.
>
> Anyway, if this discussion really needs to be continued. It should be
> continued in the cygwin mailing list.
Lo' and behold, here we are! ;-)
Paul G.
>
> cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
