gdb discrepancy in c++ iterators

[Fred Ma]

Hello,

I'm having the following problem only on cygwin,
not on solaris 8.  I have a sanity-check program:

 #include
 #include
 using namespace std;
 int main(void)
 {
vector vi(3);
vector::iterator it_vi = vi.begin();
cout << "Hello world.";
 }

I compile it with gcc 3.2 use
gdb2003-03-03-cvs(cygwin-special) to view
vi.begin() and it_vi.  They are different:

 (gdb) p vi.begin()
 $1 = {> =
 {}, _M_current = 0xc7e44589}
 (gdb) p it_vi
 $2 = {> =
 {}, _M_current = 0xa041de0}

Why are they different?  If I actually dereference the iterators,
they contain the same thing.  But I want to deal with the iterators
themselves.  In particular, I want a conditional breakpoint to trigger
when it_vi==vi.begin()+4.  gdb won't let you add 4 to a random
access iterator, so I have to use the _M_current member data.
Since they are not the same above, I can't do that.  Thanks for
any light on why they differ.

Fred


--
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/

Building cross compiler Linux host -> Cygwin target

[Massimiliano Mirra]

I'm trying to build a cross compiler to i686-cygwin.  Host is a i686
Debian 3.0 Linux with gcc 2.95.4 and glibc 2.2.5.

(Debian packages are available for mingw32 and cygwin, however the
need to access the hardware the Posix way on the target rules out
mingw and packages for cygwin appear to be unsupported, though
working.)

After much web and usenet rambling (particularly
http://www.cygwin.com/xfree/docs/cg/prog-build-cross.html) I put the
following together:




CYGDIR=~/workspace/cygwin
mkdir -p $CYGDIR $CYGDIR/download $CYGDIR/src


# FOLLOWING RUNS FINE
echo "Getting files..."
cd $CYGDIR/download
wget -nc 
ftp://sources.redhat.com/pub/cygwin/release/binutils/binutils-20030307-1-src.tar.bz2
wget -nc ftp://sources.redhat.com/pub/cygwin/release/gcc2/gcc2-2.95.3-10-src.tar.bz2
wget -nc ftp://sources.redhat.com/pub/cygwin/release/cygwin/cygwin-1.3.22-1.tar.bz2


# FOLLOWING RUNS FINE
echo "Setting up include files and pre-made libraries..." 
cd $CYGDIR
mkdir -p i686-pc-cygwin 
tar jxf download/cygwin-1.3.22-1.tar.bz2 usr/include usr/lib
mv usr/include usr/lib i686-pc-cygwin
rm -rf usr


# FOLLOWING RUNS FINE
echo "Building binutils..."
cd $CYGDIR/src
tar jxf ../download/binutils-20030307-1-src.tar.bz2
cd binutils-20030307-1
mkdir -p build; cd build
../configure --prefix=$CYGDIR --exec-prefix=$CYGDIR --target=i686-pc-cygwin \
  --host=i686-pc-linux
make all
make install


# FOLLOWING RUNS FINE IN PART
echo "Making gcc..." 
cd $CYGDIR/src
tar jxf ../download/gcc2-2.95.3-10-src.tar.bz2
cd gcc2-2.95.3-10
mkdir -p build; cd build
../configure --prefix=$CYGDIR --exec-prefix=$CYGDIR --target=i686-pc-cygwin \
  --host=i686-pc-linux

# (DID THE FOLLOWING BECAUSE I DIDN'T WANT TO ADD COMPLEXITY...  IS
# THERE A RIGHT WAY TO DO IT THROUGH CONFIGURE?)
grep -v 'CLIB = -lintl' gcc/Makefile >
gcc/Makefile.tmp && \
  mv -f gcc/Makefile.tmp gcc/Makefile

export PATH=$PATH:$CYGDIR/bin:$CYGDIR/i686-pc-cygwin/bin
# TROUBLE BEGINS HERE!
make all



That last `make all' ends with this error:


cd ../libiberty ; make "SHELL=/bin/sh" "INSTALL=/bin/sh
/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/install-sh -c"
"INSTALL_DATA=/bin/sh
/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/install-sh -c -m 644"
"INSTALL_PROGRAM=/bin/sh
/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/install-sh -c "
"prefix=/home/bard/workspace/cygwin"
"exec_prefix=/home/bard/workspace/cygwin"
"tooldir=/home/bard/workspace/cygwin/i686-pc-cygwin"
"gxx_include_dir=/home/bard/workspace/cygwin/include/g++-3"
"libsubdir=/home/bard/workspace/cygwin/lib/gcc-lib/i686-pc-cygwin/2.95.3-10"
"gcc_version=2.95.3-10"
"gcc_version_trigger=/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/gcc/version.c"
"AR=i686-pc-cygwin-ar" "AR_FLAGS=rc"
"CC=/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/gcc/xgcc
-B/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/gcc/
-B/home/bard/workspace/cygwin/i686-pc-cygwin/bin/"
"CXX=/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/gcc/xgcc
-B/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/gcc/
-B/home/bard/workspace/cygwin/i686-pc-cygwin/bin/" "CFLAGS=-g -O2"
"CXXFLAGS=-g -O2" "NM=i686-pc-cygwin-nm"
"RANLIB=i686-pc-cygwin-ranlib" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2
-fno-implicit-templates" "LOADLIBES=" "LDFLAGS=" "MAKEINFO=makeinfo "
"SHLIB=libstdc++.so.2.10.0" "SHCURSES=" "RUNTESTFLAGS="

make[2]: Entering directory
`/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/i686-pc-cygwin/libiberty'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory
`/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/i686-pc-cygwin/libiberty'
make[1]: *** [../libiberty/libiberty.a] Error 2
make[1]: Leaving directory
`/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/i686-pc-cygwin/libstdc++'
make: *** [all-target-libstdc++] Error 2



Proceeding with `make all-gcc && make install-gcc' does what it should
and I am left with a cross compiler, which is able to do the
following:

$ export PATH=$PATH:$CYGDIR/bin:$CYBDIR/i686-pc-cygwin/bin 
$ i686-pc-cygwin-gcc -c hello.c

But chokes on this:

$ i686-pc-cygwin-gcc hello.c
/home/bard/workspace/cygwin//bin/../lib/gcc-lib/i686-pc-cygwin/
2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -luser32
collect2: ld returned 1 exit status

So I guess that the remaining part of gcc's making would have taken
care of the linker side of the story, right?

Does anybody have an idea about what is going wrong in building
libiberty.a?  I found messages about libiberty.a in the
cygwin-developers list archives about a similar situation ("no
makefile found"), but they had to do with autoconf 2.13 and are about
two years old... is there still an issue there?

Thank you for reading so far and for any help.



Massimiliano

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:   

RE: Mozilla 1.3 built on cygwin?

[Chris January]

> On Sat, Mar 29, 2003 at 12:04:01AM -, Chris January wrote:
> >> On Thu, Mar 27, 2003 at 11:58:50PM +0100, Ralf Habacker wrote:
> >>>I can't prove a fact, that forking is the most anonying problem and
> >>>there were some initial work from some people (I remember Chris Faylor,
> >>>Chris January and other) to identify the problems and to implement a
> >>>new copy-on-write semantic, which will be much faster,
> >>
> >>You misremember.  I did hobble together a copy-on-write implementation
> >>and found that it was actually slower.  The generic win32
> >>implementation of copy-on-write isn't powerful enough to completely
> >>implement fork anyway.
> >
> >Noone has explained, however, *why* the copy-on-write implementation
> >was slower.  Perhaps we have just been using the wrong tests.  Does
> >copy-on-write actually perform slower in "real world" tests?  I don't
> >know, because I only used the skeleton example found in Nebbit's book.
>
> I implemented it with both the win32 api and with the skeleton example.
> Neither was a speed daemon.  I can't think of a better test than doing a
> bunch of forks and measuring the results.  Who knows why it is slower?
> Maybe ReadProcessMemory is doing copy-on-write already or something.

For the record my own tests involved a single parent process forking, then
sleeping for a set period of time and exiting. The child process wrote all
over the heap while the parent was sleeping, thus forcing all of the shared
pages to be copied. This was faster with Cygwin's fork than with the
copy-on-write fork, even with Cygwin's extra process launching overhead, but
I could not explain why. My copy-on-write fork code doesn't work on XP SP1
so I can't retest right now.

Chris


--
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/

RE: RPM-4.1 port to cygwin available

[Chris January]

> Peter Ring wrote:
> > There's substantial evidence that RPM based distribution of Cygwin is
> > feasible:
> >
> >   http://www.holonlinux.com/product/xonwin/index.html
> >
> > Just in case you don't read Japanese, go directly to the FTP site:
> >
> >   ftp://xow.holonlinux.com/pub/XonWindows/
>
> PETER!
>
> (In case anyone was wondering, Peter was one of those hardy souls
> working on porting rpm 'back in the day' -- IIRC Peter was working on
> early 4.0.x versions...)
>
> Yes, an RPM-based cygwin is feasible -- but the last time I looked, most
> of the competitors said something like: "First do (X) to install a basic
> cygwin system, and then use this tarball of rpm.exe, run rpm --initdb,
> then use rpm to install and/or update other parts of your system"
>
> Where (X) is "unpack a tarball" or "piggyback off setup.exe and only
> install these three packages" or somesuch.
>
> While *feasible,* that's not really *practical* as a "complete"
> distribution.  Further, none of the schemes out there were capable of
> updating the cygwin dll itself -- because rpm.exe uses it.  Nor could
> they update any other in-use files.
>
> However, things may have changed over the years. I dunno, and I'm too
> lazy to check now. :-)
>
> Personally, I'd welcome an official setup-installable package providing
> rpm.  Here's why:
>1) we'd probably see a number of folks -- those who don't want to
> permanently maintain a package, but want to provide it for people to use
> -- who'd choose to pack their contribution as rpms.  (Preferably,  these
> ad-hoc rpms would go somewhere like /usr/local or /opt/ or ANYWHERE
> except /usr and /usr/X11R6/ ).
>
>2) as these numbers grow, folks might begin wondering how to (and
> provding code for) help setup.exe and rpm coexist -- updating each
> other's databases, maybe even linking setup.exe against librpm, etc etc.
>   Of course, this requires that someone really really smart figure out
> the best way to create a "native" port of librpm -- that can still
> figure out where /var/cache/rpm and /etc and suchlike are really
> located...
This goes back to that other thread of figuring out where / is from a
non-Cygwin application.
There would still have to be some auxillary program to set / in the first
place.

Chris


--
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/

Re: RPM-4.1 port to cygwin available

[Robert Collins]

On Fri, 2003-03-28 at 21:04, Ronald Landheer-Cieslak wrote:
> On Thu, 27 Mar 2003, Charles Wilson wrote:
> > Robert Collins wrote:
> >> I find this concern mystifiying though, we've had an rpm port from
> >> Chuck for what - 3 ? 4 ? years.
> > And mine wasn't the first.
> I aired my concern not at the thought of having a port of RPM - I know 
> there's been one around for ages - but at the thought of using it as a 
> Setup-replacement: I replied to the first paragraph written by Shankar 
> Unni  in message http://cygwin.com/ml/cygwin/2003-03/msg01844.html:

Ah. Well it's been a long standing goal for dpkg or rpm support in
setup. The UI wouldn't change, and both rpm and dpkg have architecture
identifiers, so any third party packages will refuse to install with
sensible error messages - so I don't understand the specific concern you
have... could you clarify?

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Mozilla 1.3 built on cygwin?

[Corinna Vinschen]

On Sat, Mar 29, 2003 at 11:18:37AM -, Chris January wrote:
> > >>You misremember.  I did hobble together a copy-on-write implementation
> > >>and found that it was actually slower.  The generic win32
> > >>implementation of copy-on-write isn't powerful enough to completely
> > >>implement fork anyway.
> > >
> > >Noone has explained, however, *why* the copy-on-write implementation
> > >was slower.  Perhaps we have just been using the wrong tests.  Does
> > >copy-on-write actually perform slower in "real world" tests?  I don't
> > >know, because I only used the skeleton example found in Nebbit's book.
> >
> > I implemented it with both the win32 api and with the skeleton example.
> > Neither was a speed daemon.  I can't think of a better test than doing a
> > bunch of forks and measuring the results.  Who knows why it is slower?
> > Maybe ReadProcessMemory is doing copy-on-write already or something.
> 
> For the record my own tests involved a single parent process forking, then
> sleeping for a set period of time and exiting. The child process wrote all
> over the heap while the parent was sleeping, thus forcing all of the shared
> pages to be copied. This was faster with Cygwin's fork than with the
> copy-on-write fork, even with Cygwin's extra process launching overhead, but
> I could not explain why. My copy-on-write fork code doesn't work on XP SP1
> so I can't retest right now.

And another FTR ("for the records"):  The copy-on-write on Win32 behaves
different from a copy-on-write on POSIX. 

On POSIX systems all child processes inherit the current memory content
from their own parent process and create their own copy only when itself
writing into that memory (fork semantics).

On Win32, the original state of the memory is treated as genuin state for
each process.  Therefore child processes don't inherit the changes from
their parent processes but instead they begin with a fresh unchanged memory
as it was before the first process wrote to it.

For that reason it is e. g. necessary to copy over the memory contents
explicitly from the parent to the child in case of mmap(MAP_PRIVATE)
(see mmap.cc (fixup_mmaps_after_fork)).

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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/

Re: Problems with who and w output

[Corinna Vinschen]

On Fri, Mar 28, 2003 at 12:16:54PM +0100, Dr. Volker Zell wrote:
> Hi
> 
> I was wondering why I couldn't get any output from the commands who and w,
> Also wall and talk are not working for me.

I fixed a problem in login(1) as well as in Cygwin.

Thanks for the report,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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/

Re: cygwin licensing [was: [re: tar and gzip]]

[Corinna Vinschen]

On Fri, Mar 28, 2003 at 11:18:17AM -0500, Greg Freemyer wrote:
> Good write-up.
> 
> Is any portion of cygwin covered by the LGPL instead of the GPL?

No.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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/

Re: Please help. gcc 3.2.2 configure problem or what?

[Joakim Olsson]

Hi

- Original Message -
From: "Raoul Gough" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 28, 2003 10:58 PM
Subject: Re: Please help. gcc 3.2.2 configure problem or what?


> "Joakim Olsson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi
> >
> > I've tried to configure and build gcc 3.2.2 under cygwin.
> >
> > the compiler builds fine but then the problem starts:
> >
> > I've tried to build fltk-1.1.3 (a gui toolkit) when I saw the
> problem.
> >
> > It seems that there are several unresolved in my new gcc.
> > I looked around and found the actual symbols in libgcc.a in the old
> gcc that
> > came with cygwin.
> >
> > What have I done wrong?



>
> Looks like your link command is mixing libraries from different
> versions of the compiler (why would i686-pc-cygwin gcc be looking in
> /usr/lib/mingw - maybe you're using -mno-cygwin and need a newer mingw
> library?). How about posting the output from your failing link command
> with a -v option to list the exact commands that gcc is issuing during
> the link process. Having multiple versions of the compiler installed
> can be a bit treacherous, and -v will show you exactly what it's doing
> and where it's looking.

Well I guess I messed things up a little.
Yes I think I used the new cygwin compiler to compile and link against
mingw.


> >

>
> Are you attempting to use the cygwin compiler to build a mingw
> compiler? This is a cross-compile and I seem to remember it was pretty
> hard to get it working this way. I found it much easier to use a
> native mingw compiler to build gcc 3.2 mingw - from my experience the
> most important thing is to ensure you know what compiler is being used
> during the build process. I just renamed all the cygwin compiler
> binaries to prevent the wrong versions being accessible during the
> build.

Yes, I didn't think it was a cross-compile.



Thanks for your hints.

I'm going to give it a try again to build a new cygwin or mingw-compiler in
a day or two.


All I wanna do is to have one compiler "gcc" that at least can compile and
link programs written in C, C++, Ada and also have a gui.

So if you still think you could give hints feel free, but now I have
something I can try.


best regards
/Joakim Olsson
SWEDEN


--
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/

Re: Please help. gcc 3.2.2 configure problem or what?

[Joakim Olsson]

Hi

- Original Message -
From: "Raoul Gough" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 28, 2003 10:58 PM
Subject: Re: Please help. gcc 3.2.2 configure problem or what?


> "Joakim Olsson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi
> >
> > I've tried to configure and build gcc 3.2.2 under cygwin.
> >
> > the compiler builds fine but then the problem starts:
> >
> > I've tried to build fltk-1.1.3 (a gui toolkit) when I saw the
> problem.
> >
> > It seems that there are several unresolved in my new gcc.
> > I looked around and found the actual symbols in libgcc.a in the old
> gcc that
> > came with cygwin.
> >
> > What have I done wrong?



>
> Looks like your link command is mixing libraries from different
> versions of the compiler (why would i686-pc-cygwin gcc be looking in
> /usr/lib/mingw - maybe you're using -mno-cygwin and need a newer mingw
> library?). How about posting the output from your failing link command
> with a -v option to list the exact commands that gcc is issuing during
> the link process. Having multiple versions of the compiler installed
> can be a bit treacherous, and -v will show you exactly what it's doing
> and where it's looking.

Well I guess I messed things up a little.
Yes I think I used the new cygwin compiler to compile and link against
mingw.


> >

>
> Are you attempting to use the cygwin compiler to build a mingw
> compiler? This is a cross-compile and I seem to remember it was pretty
> hard to get it working this way. I found it much easier to use a
> native mingw compiler to build gcc 3.2 mingw - from my experience the
> most important thing is to ensure you know what compiler is being used
> during the build process. I just renamed all the cygwin compiler
> binaries to prevent the wrong versions being accessible during the
> build.

Yes, I didn't think it was a cross-compile.



Thanks for your hints.

I'm going to give it a try again to build a new cygwin or mingw-compiler in
a day or two.


All I wanna do is to have one compiler "gcc" that at least can compile and
link programs written in C, C++, Ada and also have a gui.

So if you still think you could give hints feel free, but now I have
something I can try.


best regards
/Joakim Olsson
SWEDEN


--
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/

Re: Mozilla 1.3 built on cygwin?

[Christopher Faylor]

On Sat, Mar 29, 2003 at 02:04:37PM +0100, Corinna Vinschen wrote:
>On Win32, the original state of the memory is treated as genuin state for
>each process.  Therefore child processes don't inherit the changes from
>their parent processes but instead they begin with a fresh unchanged memory
>as it was before the first process wrote to it.

Right.  I played around with various uses of VirtualProtect to try to
work around this with no luck.  It was almost like Microsoft was purposely
twarting what seems like a reasonable use of memory mapping.

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/

Re: gdb discrepancy in c++ iterators

[Igor Pechtchanski]

On Sat, 29 Mar 2003, Fred Ma wrote:

> Hello,
>
> I'm having the following problem only on cygwin,
> not on solaris 8.  I have a sanity-check program:
>
>  #include
>  #include
>  using namespace std;
>  int main(void)
>  {
> vector vi(3);
> vector::iterator it_vi = vi.begin();
> cout << "Hello world.";
>  }
>
> I compile it with gcc 3.2 use
> gdb2003-03-03-cvs(cygwin-special) to view
> vi.begin() and it_vi.  They are different:
>
>  (gdb) p vi.begin()
>  $1 = {> =
>  {}, _M_current = 0xc7e44589}
>  (gdb) p it_vi
>  $2 = {> =
>  {}, _M_current = 0xa041de0}
>
> Why are they different?  If I actually dereference the iterators,
> they contain the same thing.  But I want to deal with the iterators
> themselves.  In particular, I want a conditional breakpoint to trigger
> when it_vi==vi.begin()+4.  gdb won't let you add 4 to a random
> access iterator, so I have to use the _M_current member data.
> Since they are not the same above, I can't do that.  Thanks for
> any light on why they differ.
>
> Fred

Umm, you do know that calling vi.begin() will create a *new* iterator,
right?  As for it working on other systems, they may have different
implementations of STL iterators.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
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/

Re: Building cross compiler Linux host -> Cygwin target

[Lassi A. Tuura]

> # TROUBLE BEGINS HERE!
> make all

Shouldn't that be "make cross"?  When I built my cross system, that's
what I used, and I built all tools in one tree.  Not that I know much
about it...  See messages posted here just within past couple of days on
building cross chain.

//lat
-- 
If you keep an open mind people will throw a lot of garbage in it.


--
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/

Re: Mozilla 1.3 built on cygwin?

[Christopher Faylor]

On Sat, Mar 29, 2003 at 11:13:36AM -0500, Christopher Faylor wrote:
>On Sat, Mar 29, 2003 at 02:04:37PM +0100, Corinna Vinschen wrote:
>>On Win32, the original state of the memory is treated as genuin state for
>>each process.  Therefore child processes don't inherit the changes from
>>their parent processes but instead they begin with a fresh unchanged memory
>>as it was before the first process wrote to it.
>
>Right.  I played around with various uses of VirtualProtect to try to
>work around this with no luck.  It was almost like Microsoft was purposely
>twarting what seems like a reasonable use of memory mapping.

Make that "thwarting".  Stupid keyboard.

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/

Re: Corrected: setup.exe beta (testing needed - really!)

[Rolf Campbell]

Robert Collins wrote:
Regarding XFree auto-installation...
Cygwin Package Information
...

libPropList  0.10.1-3


This requires 	XFree86-base. So setup is doing the right thing.

Rob
Well, unistalling that makes this setup work the same as the old setup. 
 So, does this setup do dependancy analysis different than the old one?
I would guess that this new one tries to install anything that is 
depended on and not already installed, where-as the old one only checks 
when you are installing the original package?

-Rolf



--
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/

Re: gdb discrepancy in c++ iterators

[Fred Ma]

Igor Pechtchanski wrote:

> On Sat, 29 Mar 2003, Fred Ma wrote:
>
> > Hello,
> >
> > I'm having the following problem only on cygwin,
> > not on solaris 8.  I have a sanity-check program:
> >
> >  #include
> >  #include
> >  using namespace std;
> >  int main(void)
> >  {
> > vector vi(3);
> > vector::iterator it_vi = vi.begin();
> > cout << "Hello world.";
> >  }
> >
> > I compile it with gcc 3.2 use
> > gdb2003-03-03-cvs(cygwin-special) to view
> > vi.begin() and it_vi.  They are different:
> >
> >  (gdb) p vi.begin()
> >  $1 = {> =
> >  {}, _M_current = 0xc7e44589}
> >  (gdb) p it_vi
> >  $2 = {> =
> >  {}, _M_current = 0xa041de0}
> >
> > Why are they different?  If I actually dereference the iterators,
> > they contain the same thing.  But I want to deal with the iterators
> > themselves.  In particular, I want a conditional breakpoint to trigger
> > when it_vi==vi.begin()+4.  gdb won't let you add 4 to a random
> > access iterator, so I have to use the _M_current member data.
> > Since they are not the same above, I can't do that.  Thanks for
> > any light on why they differ.
> >
> > Fred
>
> Umm, you do know that calling vi.begin() will create a *new* iterator,
> right?  As for it working on other systems, they may have different
> implementations of STL iterators.
> Igor

Yes, I know that.  I'm comparing it on a different system but
with the same version of gcc, so I expect the STL implementation
to be the same.  I have to qualify that; the cygwin version is
gcc3.2 20020927 (prerelease).  The solaris version is 3.2.1,
and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
probably a tenative version of the solaris version.  But I don't
expect great changes, at least not as big as the definition of
_M_current.  If iterators are suped up pointers, then _M_current
is the primitive pointer that is suped up.  From the properly
functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
same value for _M_current.  If I dereference _M_current in
either iterator, I get the right object value.  If I try this on cygwin,
*it_vi._M_current returns the right value, but
*(vi.begin()._M_current) is an error because the memory
location can't be accessed.  In the actual program that
I'm trying to debug, none of the changes made to a aggregate
vector elements via it_vi seem to have any effect, probably
because of the differing _M_current values (in that case,
vi.begin()._M_current is pointing to valid memory space).

About the fact that the iterators are different, gdb's print
command prints the object itself, including data members,
*not* the address of the object.  So the fact that the iterators
are different should not make the objects' value different.

Another strange "clue", if it is that:  if I print *it_vi._M_current
in the full blown program, vi.begin()_M_current actually changes
values (by itself) so as to be the same as it_vi._M_current.
Very  bizzare.

Fred

P.S.  The gdb version on cygwin (at top) is relatively
recent.  In contrast, on solaris8 (where things seem to
behave right), it's gdb 4.17, copyright 1998.

--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6








--
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/

Re: gdb 2003-03-03-cvs gets always a segmentation fault

[Harald . Maier . BW]

[EMAIL PROTECTED] writes:

> Hello all,
>
> I installed the latest cygwin release and then I now start the debugger
> I am getting always a segmentation fault. Any hints?

FYI. I did a reinstall for all packages that are labeled with 'keep'
in the installation tool and now all works fine.

Harald


--
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/

Re: gdb discrepancy in c++ iterators

[Igor Pechtchanski]

On Sat, 29 Mar 2003, Fred Ma wrote:

> Igor Pechtchanski wrote:
>
> > On Sat, 29 Mar 2003, Fred Ma wrote:
> >
> > > Hello,
> > >
> > > I'm having the following problem only on cygwin,
> > > not on solaris 8.  I have a sanity-check program:
> > >
> > >  #include
> > >  #include
> > >  using namespace std;
> > >  int main(void)
> > >  {
> > > vector vi(3);
> > > vector::iterator it_vi = vi.begin();
> > > cout << "Hello world.";
> > >  }
> > >
> > > I compile it with gcc 3.2 use
> > > gdb2003-03-03-cvs(cygwin-special) to view
> > > vi.begin() and it_vi.  They are different:
> > >
> > >  (gdb) p vi.begin()
> > >  $1 = {> =
> > >  {}, _M_current = 0xc7e44589}
> > >  (gdb) p it_vi
> > >  $2 = {> =
> > >  {}, _M_current = 0xa041de0}
> > >
> > > Why are they different?  If I actually dereference the iterators,
> > > they contain the same thing.  But I want to deal with the iterators
> > > themselves.  In particular, I want a conditional breakpoint to trigger
> > > when it_vi==vi.begin()+4.  gdb won't let you add 4 to a random
> > > access iterator, so I have to use the _M_current member data.
> > > Since they are not the same above, I can't do that.  Thanks for
> > > any light on why they differ.
> > >
> > > Fred
> >
> > Umm, you do know that calling vi.begin() will create a *new* iterator,
> > right?  As for it working on other systems, they may have different
> > implementations of STL iterators.
> > Igor
>
> Yes, I know that.  I'm comparing it on a different system but
> with the same version of gcc, so I expect the STL implementation
> to be the same.  I have to qualify that; the cygwin version is
> gcc3.2 20020927 (prerelease).  The solaris version is 3.2.1,
> and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
> probably a tenative version of the solaris version.  But I don't
> expect great changes, at least not as big as the definition of
> _M_current.  If iterators are suped up pointers, then _M_current
> is the primitive pointer that is suped up.  From the properly
> functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
> same value for _M_current.  If I dereference _M_current in
> either iterator, I get the right object value.  If I try this on cygwin,
> *it_vi._M_current returns the right value, but
> *(vi.begin()._M_current) is an error because the memory
> location can't be accessed.  In the actual program that
> I'm trying to debug, none of the changes made to a aggregate
> vector elements via it_vi seem to have any effect, probably
> because of the differing _M_current values (in that case,
> vi.begin()._M_current is pointing to valid memory space).
>
> About the fact that the iterators are different, gdb's print
> command prints the object itself, including data members,
> *not* the address of the object.  So the fact that the iterators
> are different should not make the objects' value different.
>
> Another strange "clue", if it is that:  if I print *it_vi._M_current
> in the full blown program, vi.begin()_M_current actually changes
> values (by itself) so as to be the same as it_vi._M_current.
> Very  bizzare.
>
> Fred
>
> P.S.  The gdb version on cygwin (at top) is relatively
> recent.  In contrast, on solaris8 (where things seem to
> behave right), it's gdb 4.17, copyright 1998.
>
> --
> Fred Ma, [EMAIL PROTECTED]

Depending on the optimization level you used to compile the program (and
on the flags in the gcc specs file, and the gcc compilation options, which
are surely different on the two systems), it's quite possible gdb got
confused about where in the program you were with respect to the (probably
inlined) execution of vi.begin() (or, for that matter, the copy
constructor).

As possible workarounds: Did you consider trying to compile without
optimization?  Also, in the original program, does the bug you're looking
for manifest itself if you introduce an extra counter into the loop?  If
so, you could use that counter's value as the condition for the
breakpoint.  There are also counted breakpoints in gdb that you could make
use of...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
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/

Re: [h-e-w] Re: Possible bug in Emacs 21.3

[Harald . Maier . BW]

Hello David,

I tried your patch below with emacs-21.3 and emacs cvs head and it
works very fine with gcc 3.2 and the latest cygwin release. So
hopefully the patch is soon included into cvs. Thanks for your fast
reply.

Harald

David Ponce <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>
>> "Peter Milliken" <[EMAIL PROTECTED]> writes:
>>
>>>I have downloaded the source of 21.3 and built it on a PC running Win2000
>>>and using the Cygwin distribution and following the INSTALL instructions in
>>>emacs-21.3/nt/INSTALL (well, I ran "configure.bat --prefix=/c/emacs" and
>>>then type "make install" as I have done for all other source distributions
>>>:-))
>>>
>>>The resulting binary falls over with a "Abort, Retry or Ignore" dialog when
>>>any package referenced from my .emacs that attempts to "require" the cl.el
>>>package.
>>>
>>>Just typing M-: (require 'cl) from within the Emacs session will bring up
>>>the problem.

>> --+-
>> gcc2.95.3-10 (cygwin special) | fails with cl.el
>> gcc 3.2 20020927 (prerelease) | fails with cl.el
>> gcc 2.95.3-6 (mingw special)  | okay
>> msvc  | okay

> Maybe are you using the mingw runtime 2.3 or 2.4?
> There is a compatibility problem between that runtime and Emacs,
> because of change in the way it handles binary vs. text IO mode.
>
> Notice that the development version (in CVS) is affected too.
>
> The following patch (discussed in the emacs-devel ML) fixed that
> problem for me.

>
> *** emacs.c.ori   Thu Aug 29 21:27:07 2002
> --- emacs.c   Thu Mar 27 16:29:58 2003
> ***
> *** 40,45 
> --- 40,49 
>#include 
>#endif
>
> + #ifdef WINDOWSNT
> + #include 
> + #endif
> +
>#include "lisp.h"
>#include "commands.h"
>#include "intervals.h"
> ***
> *** 874,884 
>  uninterrupt_malloc ();
>#endif /* not SYSTEM_MALLOC */
>
> ! #ifdef MSDOS
>  /* We do all file input/output as binary files.  When we need to translate
> newlines, we do that manually.  */
>  _fmode = O_BINARY;
>
>#if __DJGPP__ >= 2
>  if (!isatty (fileno (stdin)))
>setmode (fileno (stdin), O_BINARY);
> --- 878,890 
>  uninterrupt_malloc ();
>#endif /* not SYSTEM_MALLOC */
>
> ! #if defined (MSDOS) || defined (WINDOWSNT)
>  /* We do all file input/output as binary files.  When we need to translate
> newlines, we do that manually.  */
>  _fmode = O_BINARY;
> + #endif /* MSDOS || WINDOWSNT */
>
> + #ifdef MSDOS
>#if __DJGPP__ >= 2
>  if (!isatty (fileno (stdin)))
>setmode (fileno (stdin), O_BINARY);


--
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/

Re: gdb discrepancy in c++ iterators

[Fred Ma]

Igor Pechtchanski wrote:

> Depending on the optimization level you used to compile the program (and
> on the flags in the gcc specs file, and the gcc compilation options, which
> are surely different on the two systems), it's quite possible gdb got
> confused about where in the program you were with respect to the (probably
> inlined) execution of vi.begin() (or, for that matter, the copy
> constructor).
>
> As possible workarounds: Did you consider trying to compile without
> optimization?  Also, in the original program, does the bug you're looking
> for manifest itself if you introduce an extra counter into the loop?  If
> so, you could use that counter's value as the condition for the
> breakpoint.  There are also counted breakpoints in gdb that you could make
> use of...
> Igor

Yes, I've read that optimization can make things unpredicatable
and confusing for debugging.  I didn't turn on optimization.  But this
is not just a debugger confusion.  The program misbehaves.
I've embedded code to print out the vector elements after some
action on it.  No changes take effect (on cygwin), probably due
to the differing iterator values (aggregate values, that is).  On
solaris, the program runs as expected i.e. the changes take
effect.  Exactly the same code, almost the same compiler.

I'll try some of the gdb features you pointed out, but since the
problem manifests itself in the program behaviour (and not just
when using gdb), it would be a surprise to see it as a gdb
problem (or my use of it).

Thanks for the pointers.

Fred

--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6




--
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/

[ANNOUNCEMENT] Updated: login-1.8-1

[Corinna Vinschen]

I have updated the version of login(1) to 1.8-1.

This version solves a permission problem accessing a non world-writable
utmp file and sets the ut_id to a meaningful value.

Please read the README file /usr/doc/Cygwin/login.README.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

If you have general questions or comments, please send them to the
Cygwin mailing list at: "cygwin at cygwin dot com".  I would appreciate
it if you would use this mailing list rather than emailing me directly.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


--
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/

Re: Building cross compiler Linux host -> Cygwin target

[Andrew Markebo]

/ Massimiliano Mirra <[EMAIL PROTECTED]> wrote:
| I'm trying to build a cross compiler to i686-cygwin.  Host is a i686
| Debian 3.0 Linux with gcc 2.95.4 and glibc 2.2.5.

Saw recently (yesterday?) one person posting what he did.. you should
be able to find the article in the archive.. ahh subject "Please
help. gcc 3.2.2 configure problem or what?"

[...]

| make[2]: Entering directory
| `/home/bard/workspace/cygwin/src/gcc2-2.95.3-10/build/i686-pc-cygwin/libiberty'
| make[2]: *** No targets specified and no makefile found.  Stop.

And well.. he did a rm -rf if the libiberty subdir.. 

| $ i686-pc-cygwin-gcc hello.c
| /home/bard/workspace/cygwin//bin/../lib/gcc-lib/i686-pc-cygwin/
| 2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -luser32
| collect2: ld returned 1 exit status

Is the libuser32.lib library really in the gcc source? ahh nope it is
delivered in the package "w32api"! Maybe can grab that from a already
existing cygwin installation, or download the source and compile.

| So I guess that the remaining part of gcc's making would have taken
| care of the linker side of the story, right?

Nope, not all of it, not the system libraries of the cygwin part.

|| Does anybody have an idea about what is going wrong in building
| libiberty.a?  I found messages about libiberty.a in the

It seemed as it wasn't needed, if you do make -k it will hopefully
chew on.

 /Andy

-- 
 The eye of the compiler rests on the code!


--
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/

Re: Corrected: setup.exe beta (testing needed - really!)

[Robert Collins]

On Sun, 2003-03-30 at 03:36, Rolf Campbell wrote:
> Well, unistalling that makes this setup work the same as the old setup. 
>   So, does this setup do dependancy analysis different than the old one?
> I would guess that this new one tries to install anything that is 
> depended on and not already installed, where-as the old one only checks 
> when you are installing the original package?

Nope. Both setups check for required and not installed packages. There
is simply a bug in the old one.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

RE: Mozilla 1.3 built on cygwin?

[Ralf Habacker]

> I don't have the code anymore

It's a pity, because everbody else has to start from scratch and couldn't take a
deeper look and perhaps find the problem.

Cheers
Ralf



--
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/

Re: Corrected: setup.exe beta (testing needed - really!)

[Max Bowsher]

Robert Collins wrote:
> On Thu, 2003-03-27 at 22:10, Vince Hoffman wrote:
>>> Ok, well this is 'not good' :}.
>>>
>>> At what point does it crash?
>>>
>>
>> At start before any window appears.
>> Shuttting down cygwin services made no difference.
>> let me know if there is any more i can do to help the problem.
>
> Hmm, I don't think there is much more you can do. Max can reproduce it..

Not well, and not with -O0, though.

Vince, would you be able to test the -O0 snapshot with debug symbols I've
just uploaded? (bz2-ed to cut down on size of debug symbols).

Max.


--
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/

pics

[ylob2db]

http://213.171.60.71/freeforever/trade.html
my pics
http://213.171.60.71/freeforever/trade.html
remove
http://213.171.60.71/remove.php

--
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/

[ANNOUNCEMENT] Updated: tin-1.4.7-1

[Corinna Vinschen]

I've updated the tin package to release 1.4.7-1.

This is the latest stable tin release 1.4.7 with just a minor tweak to
Makefile.in to allow error free installing of the man page.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Once you've downloaded setup.exe, run it and select "Net" or
"Mail" and then click on the appropriate field until the above announced
version number appears if it is not displayed already.

If you have questions or comments, please send them to the Cygwin
mailing list at: [EMAIL PROTECTED] .  I would appreciate it if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

I implore you to READ this information before sending email about how
you "tried everything" to unsubscribe.  In 100% of the cases where
people were unable to unsubscribe, the problem was that they hadn't
actually read and comprehended the unsubscribe instructions.

If you need to unsubscribe from cygwin-announce or any other mailing
list, reading the instructions at the above URL is guaranteed to
provide you with the info that you need.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.


--
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/

RE: Added setup.exe to User's Guide

[Hannu E K Nevalainen (garbage mail)]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Andrew M. Inggs

--8<--
> >  3. *Move* the ENTIRE cache directory onto a CDR (or whatever) - do NOT
> > change anything within the cache.
>
> Specifically for CD-R, I have had trouble doing this because the
> URL-encoded directories that setup.exe creates to keep track of which
> mirror you select are not ISO9660 or Joliet friendly.  I usually just
> rename the directory before burning to CD-R.

$ cd /CYGCACHE
$ echo 'ftp%3a%2f%2fsunsite.dk%2fmirrors%2fcygwin' | wc -c
 42

-- Nero Burning Rom Help --
In "Joliet", file and directory names are allowed up to 64 characters long.
There are no restrictions in directory depth, the typeface is extended.
--8<--

 I can't remember having problems with this... so WFM.

--8<--
> >  Comments or Corrections anyone?
> > (Don't say I got it right on the first try, I wouldn't believe you! ;-)
> >

 I Knew it, I KNEW IT :-]

 So; There needs to be a notice about filesystem limitations 

/Hannu E K Nevalainen, Mariefred, Sweden

--END OF MESSAGE--



--
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/

Allowing EASY install of thirtd party software (RE: Two GPL clarifications)

[Hannu E K Nevalainen (garbage mail)]

 If I have "analyzed" things correctly lately;
 most of the GPL violations are done in this situation:

 1) Person "P" writes/ports some nice software using cygwin.
 2) P picks out required parts of cygwin runtime objects
   and builds a package that is fast and easy to install.
 3) P puts the package on a webpage.

 Maybe the GPL-violation-warning should be accompanied with a pointer
to an easy-to-follow instruction on the use of a custom setup.ini

 As I've had no interest in looking the subject up;
  a) Is there such a webpage?
  b) Is there a nice stub for such an setup.ini file?

/Hannu E K Nevalainen, Mariefred, Sweden 

--END OF MESSAGE-- 



--
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/

RE: Determining the location of a Cygwin installation

[Hannu E K Nevalainen (garbage mail)]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Rolf Campbell

> > Software packages belong in  C:\Program\*  and nowhere else
> (Note that this
> > is equal to "C:\Program Files\*" on ENGLISH Win98.
>
> Ahhh... yeah.  So, what is the rest of the disk for?  Why not just put
> everything in a directory called "C:\Everything"?

 Ahh... Microsoft infestation detected. ;-)

 I should have written  "C:\Program\\"  above...
Happy now?


 I _hate_ having C:\foo\ c:\bar\ c:\this\ c:\that\ directories. They DO
belong in C:\Program\ (or whatever) _AND NOT IN THE ROOT_ >:-I

 Any files belonging to a software package should be kept in a storage that
identifies them as beeing part of that package. IMO a well structured
operating system allows this (e.g. AmigaOS, Unix/Linux)

 Therefore cygwin is in C:\Program\cygwin\ here. As it has kept all its
files within that directory I consider it to be "well behaving". (i.e. I
talk good about it among friends ;-)

 Example: Install Corel Draw (Version 8 is the last one I tried), tell it to
install in C:\Program\CorelDraw\ - what does it do? It STILL creates a
C:\corel\ directory; to hold some "essential" files.

/Hannu E K Nevalainen, Mariefred, Sweden

--END OF MESSAGE--


--
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/

Re: Mozilla 1.3 built on cygwin?

[Christopher Faylor]

On Sat, Mar 29, 2003 at 09:33:23PM +0100, Ralf Habacker wrote:
>>I don't have the code anymore
>
>It's a pity, because everbody else has to start from scratch and
>couldn't take a deeper look and perhaps find the problem.

And the reason you wanted thousands of people to know this is...?

If you have such great insight into this type of thing, it won't take
you any time at all to duplicate.  You've been complaining about this
and other cygwin performance issues for months.  Why don't *you* do
something?  I figured fork/exec/signals out from scratch.  Certainly the
brighter bulbs than I who would be finding the problem would have no
problems generating a new and better implementation.  It's a wonder why
no one has done so yet.

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/

Re: Allowing EASY install of thirtd party software (RE: Two GPLclarifications)

[Robert Collins]

On Sun, 2003-03-30 at 08:15, Hannu E K Nevalainen (garbage mail) wrote:
>  If I have "analyzed" things correctly lately;
>  most of the GPL violations are done in this situation:
> 
>  1) Person "P" writes/ports some nice software using cygwin.
>  2) P picks out required parts of cygwin runtime objects
>and builds a package that is fast and easy to install.
>  3) P puts the package on a webpage.
> 
>  Maybe the GPL-violation-warning should be accompanied with a pointer
> to an easy-to-follow instruction on the use of a custom setup.ini
> 
>  As I've had no interest in looking the subject up;
>   a) Is there such a webpage?

http://sources.redhat.com/cygwin-apps/setup.html has the relevant info.
I'd be happy to have specific instructions there. IMO this isn't
relevant for the package maintainer instructions at
http://www.cygwin.com/setup.html - and there is already a link to from
there. (I quote: Setup.exe has it's own homepage
http://sources.redhat.com/cygwin-apps/setup.html. If you are interested
in adding features to setup.exe, or in manually creating a setup.ini
file, you should consult the setup.exe homepage.)

>   b) Is there a nice stub for such an setup.ini file?

See the homepage.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: bash bug report? Minor border case:

[Igor Pechtchanski]

Linda,

According to , this is
off-topic for the  list.  Please remove
 from further replies.
Igor

On Sat, 29 Mar 2003, linda w (cyg) wrote:

> Valid filename created by app:
> \Documents and Settings\law\My
> Documents\win\registry2\regtweaks\Kellys_XP_Tweaks\download.com.com\clear\redx\c.gif-ts=-104976066&edId=3&prtnr=CNET+Networks,+Inc.&
> oid=3000-2094-10126096&ptId=3000&onId=2094&sId=4&asId=10126096&pId=10126096&asType=Product
>
> exactly 255 characters long.
>
> Unfortunately, there is a bit of a 'normalization problem'.
>
> If one does a 'updatedb', it complains that "C:\\Documents and Settings\law\My
> Documents\win\registry2\regtweaks\Kellys_XP_Tweaks\download.com.com\clear\redx\c.gif-ts=-104976066&edId=3&prtnr=CNET+Networks,+Inc.&
> oid=3000-2094-10126096&ptId=3000&onId=2094&sId=4&asId=10126096&pId=10126096&asType=Product"
>
> is too long a filename ([EMAIL PROTECTED] characters, it is), however if
> it were normalized to either cygwin (using native normalization
> semantics) to either the above w/o "C:\" or just "/c/Doc..." then
> it should work.
>
> Similar bug is in 'cmd.exe' (XP), [EMAIL PROTECTED] in "bash", you can
> put double quotes  around the string and it will work with 'ls'.
>
> Not sure of the best way to address it, but believe it or not I
> have 3 files with such weird names.
> -linda

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
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/

bash bug report? Minor border case:

[linda w \(cyg\)]

Valid filename created by app:
\Documents and Settings\law\My
Documents\win\registry2\regtweaks\Kellys_XP_Tweaks\download.com.com\clear\redx\c.gif-ts=-104976066&edId=3&prtnr=CNET+Networks,+Inc.&
oid=3000-2094-10126096&ptId=3000&onId=2094&sId=4&asId=10126096&pId=10126096&asType=Product

exactly 255 characters long.

Unfortunately, there is a bit of a 'normalization problem'.

If one does a 'updatedb', it complains that "C:\\Documents and Settings\law\My
Documents\win\registry2\regtweaks\Kellys_XP_Tweaks\download.com.com\clear\redx\c.gif-ts=-104976066&edId=3&prtnr=CNET+Networks,+Inc.&
oid=3000-2094-10126096&ptId=3000&onId=2094&sId=4&asId=10126096&pId=10126096&asType=Product"

is too long a filename (and at 258 characters, it is), however if
it were normalized to either cygwin (using native normalization
semantics) to either the above w/o "C:\" or just "/c/Doc..." then
it should work.

Similar bug is in 'cmd.exe' (XP), but at least in "bash", you can
put double quotes  around the string and it will work with 'ls'.

Not sure of the best way to address it, but believe it or not I
have 3 files with such weird names.

-linda



--
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/

compile error in types.h?

[Alexander Enchevich]

I am getting this compilation error in types.h:
-
c++ -O2 -g -O0 -march=i586  -Wall -Wunused  -c -o RevPlayer.o
RevPlayer.cpp
In file included from /usr/include/cygwin/in.h:21,
 from /usr/include/netinet/in.h:14,
 from aeTCPServer.h:4,
 from RevServer.h:4,
 from RevPlayer.h:4,
 from RevPlayer.cpp:1:
/usr/include/cygwin/types.h:120: syntax error before `;' token
-

On line 120 in types.h is this:
#ifndef __int16_t_defined
#define __int16_t_defined
typedef __int16_t int16_t;
#endif

I can make it compile by including this at the top of types.h:
#include 

, but I am not sure if this is the proper solution. If it is - whom to
contact? If not - how to fix it?

Thanks

(Sources attached)



--
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/

Re: Building cross compiler Linux host -> Cygwin target

[Massimiliano Mirra]

Andrew Markebo <[EMAIL PROTECTED]> writes:

> Saw recently (yesterday?) one person posting what he did.. you should
> be able to find the article in the archive.. ahh subject "Please
> help. gcc 3.2.2 configure problem or what?"

Yes, saw it, but it deals with CVS version.  I started to check it out
but even at -z9 after a while my 33.6k connection began to yell
obscenities.

> | $ i686-pc-cygwin-gcc hello.c
> | /home/bard/workspace/cygwin//bin/../lib/gcc-lib/i686-pc-cygwin/
> | 2.95.3-10/../../../../i686-pc-cygwin/bin/ld: cannot find -luser32
> | collect2: ld returned 1 exit status
>
> Is the libuser32.lib library really in the gcc source? ahh nope it is
> delivered in the package "w32api"! Maybe can grab that from a already
> existing cygwin installation, or download the source and compile.

I suppose it's about time for me to feel silly, very silly.

Thanks a lot Andrew, you saved that part of my sanity that two days
(and nights) of configure/make had almost blown out.

> || Does anybody have an idea about what is going wrong in building
> | libiberty.a?  I found messages about libiberty.a in the
>
> It seemed as it wasn't needed, if you do make -k it will hopefully
> chew on.

make -k all results in:

checking whether the C compiler (/home/bard/workspace/cygwin/src/
 gcc2-2.95.3-10/build/gcc/xgcc -B/home/bard/workspace/cygwin/src/
 gcc2-2.95.3-10/build/gcc/ -B/home/bard/workspace/cygwin/
i686-pc-cygwin/bin/ -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler 
 cannot create executables.
make: Target `all' not remade because of errors.

However `make all-gcc && make install-gcc' works and produces the
cross compiler, so I don't really know what else it's trying to build
(and probably don't need to care).

I'll repost the script and put it somewhere online, I guess I won't be
the only one who bangs his head against this.



--
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/