setup.exe and inuse files for X
I think I've got a handle on this... looks like read only (-r--r--r--) files don't delete properly, so setup fails to overwrite them. Patches gratefully accepted, it's going in the TODO for now. Rob
RE: upset stumper [cgf, Robert Collins, please comment]
> -Original Message- > From: Harold Hunt [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 01, 2002 12:25 AM > To: Robert Collins; cygx > Subject: RE: upset stumper [cgf, Robert Collins, please comment] > > > Robert, > > I forgot to reply last night that I had hand-fixed the > setup.ini file and setup.exe ran fine after that. Cool. Rob
Short-term personal status
Final exams are this week and I graduate from Michigan State University on Saturday with my Computational Mathematics B.S. Actually, I receive my degree at the end of the summer because I am taking one more summer class, but that's just so I get charged the undergraduate rate instead of the graduate rate. In the fall I start my Computer Science Master's program at MSU. My fiancé keeps putting me in trouble when she catches me working on Cygwin/XFree86 instead of studying for my exams that are on Wednesday and Thursday. Thus, I must take a couple days off of replying to emails and working on the project. I'll be back on Sunday or Monday. Note: my huntharo-4.user.msu.edu machine will be going offline Thursday afternoon. That shouldn't make a difference to anyone, except that archives of links to that machine will be dead. (This is because I am moving out of the dorm... I'll go from 10BaseT to a cable modem.) That's all for now, Harold
RE: mkdll.sh
Chuck, Excellent. You know that your write-up won't be a wasted effort on me. :) I'll be looking at this next week. Harold > -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 11:48 AM > To: Harold Hunt > Cc: cygx > Subject: Re: mkdll.sh > > > Harold Hunt wrote: > > > Chuck, > > > > Could you give a few more notes on "relibtoolize"? A pointer to some > good > > documentation would be helpful... > > > Well, there's the goat book http://sources.redhat.com/autobook/ but it's > a bit out of date, now... > > Here's the procedure I used to "relibtoolize" libiconv. Libiconv is a > worst-case example: they distribute their own fork of autoconf itself, > they redistribute system m4 macros, ... they're just plain evil. But, > if you can understand *this*, then "relibtoolizing" anything else should > be a piece of cake... > > Short version: remove autogenerated files. Replace "standard" files > with the newest versions (install-sh, mkinstalldirs, config.guess, > config.sub) -- you can also just remove these and let the autotools copy > in what they need (use the --force --c -a switches, or their analog: not > every tool has exactly the same syntax). Rerun the the autotools in the > proper order (more later). > > #1) libiconv actually ships its OWN VERSION of autoconf. This is dumb. > > rm autoconf/acgeneral.m4 > rm autoconf/acspecific.m4 > rm autoconf/aclocal.m4 > rm autoconf/autoconf > rm autoconf/autoconf.m4 > rm autoconf/mbstate_t.m4 > > #2) remove the "normal" distribution files that are created by autoconf. > > rm autoconf/install-sh > rm autoconf/config.guess > rm autoconf/config.sub > rm configure > > #3) remove the obsolete libtool files (libtool no longer uses "ltmain.sh") > > rm autoconf/ltmain.sh > > #4) I don't like hiding the autofiles, so I removed the subdir and will > change configure.in appropriately, but you don't have to do that. > > rmdir autoconf > > #5) libiconv doesn't use automake, but it does distribute some scripts > from automake. Replace them with the current versions. (Actually, > libiconv only distributed install-sh; it used the mkinstalldirs from the > libcharset subdirectory, "proper" auto* usage requires that each > separately configure project have its own copy...and of course, I put > install-sh in the top directory, libiconv had it in the autoconf subdir) > > cp /usr/autotool/devel/share/automake/mkinstalldirs . > cp /usr/autotool/devel/share/automake/install-sh . > > #6) repeat steps 1-4 for the libcharset subdirectory. Normally, this is > unnecessary, but libiconv actually treats libcharset as a separate > project, with it's own configure script and suchlike... > > rm libcharset/autoconf/aclocal.m4 > rm libcharset/autoconf/mkinstalldirs > rm libcharset/autoconf/install-sh > rm libcharset/autoconf/config.guess > rm libcharset/autoconf/config.sub > rm libcharset/autoconf/ltmain.sh > rm libcharset/configure > rmdir libcharset/autoconf > > #7) libcharset also includes its own copies of some .m4 scripts that are > part of gettext. Use the system ones. > > rm libcharset/m4/codeset.m4 > rm libcharset/m4/glibc21.m4 > > #8) AND we're going to use the system libtool...and cleanup. > > rm libcharset/m4/libtool.m4 > rm libcharset/m4/ChangeLog > rmdir libcharset/m4 > > #9) Similar to step #5, replace the "automake" files with the latest > version (even though libcharset doesn't use automake...). Both > mkinstalldirs and install-sh WERE in the autoconf subdir of libcharset; > I put them in the top level (of libcharset). Each separately configured > project needs its own copy... > > cp /usr/autotool/devel/share/automake/mkinstalldirs libcharset/ > cp /usr/autotool/devel/share/automake/install-sh libcharset/ > > #10) As promised, I need to change a few items in configure.in (e.g. > don't use the "autoconf" subdir (or libcharset/autoconf or > libcharset/m4). Also, since the "special" versions of the autoconf > files that libiconv distributes were slightly modified -- okay, they > were distributing a fork -- I parsed out the differences they had, and > put those macros into acinclude.m4... > > The patch is attached. > > The patch also AC_PREREQ's 2.52 instead of 2.13 (I want to use the > -devel tree), but that required a few other changes due to > incompatibilities (AC_OUTPUT_SUBDIRS ---> AC_CONFIG_SUBDIRS, etc) > > Normally, you'd also re-run autoheader at some point, but that didn't > work (thanks to the fact that libiconv uses a forked autoconf dist...) > So I patched libcharset/config.h.in by hand... > > #11) Okay, here's the meat: First, we relibtoolize libcharset: > > cd libcharset > aclocal > libtoolize -c -f > aclocal # (again) > autoconf > > cd > aclocal > libtoolize -c -f > aclocal # (again) > autoconf > > Why the second aclocal step? Because libtoolize adds additional stuff > in configure.in, which require additional macros to be pulled into > aclocal.m4. Why not run libtoolize first, and then aclocal?
Re: By the way...
Steven O'Brien wrote: >> 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like > > I'll add that to the list of jobs ... When I started work on > gnome-vfs pkg-config was not in the "official" cygwin distribution > and 0.8.0 was the latest version. I patched it to remove the > included glib, so that it uses my glib port. When pkgconfig was > added to cygwin I tried it, but gnome-vfs would not build, so I > just ignored it. My focus was, and still is, on gnome so doing more > work on pkgconfig was of no interest. But I'll certainly try the > new one. What was the rationale for removing the included glib? It was put into pkgconfig in order to break the recursive dependence: glib requires pkgconfig which requires glib which ... Granted, the version of glib included in pkgconfig is old (but it's capable enough for what pkgconfig needs) and has a one-line bug when compiling on cygwin; I just patch that and move on... Anyway, if your version of pkgconfig (0.8.0 + local glib) compiled gnome-vfs (on a particular date), yet the "official" cygwin version of pkgconfig (0.10.0) failed to do so: I would think the problem is either: something broke in the real pkgconfig sources between 0.8.0 and 0.10.0 or gnome-vfs (on the particular date) was either exploiting a bug in pkgconfig-0.8.0, or was otherwise broken. I don't think the answer is to use (and recommend) that cygwinners who want gnome use a old version of pkgconfig with a circular dependency... Thanks for offering to try with "real" pkgconfig-0.12.0. You'll probably need to apply this patch (if you keep the included static glib): --- pkgconfig-0.10.0-orig/glib-1.2.8/gstrfuncs.cMon Apr 17 11:05:16 2000 +++ pkgconfig-0.10.0/glib-1.2.8/gstrfuncs.c Sat Feb 23 01:38:15 2002 @@ -671,7 +671,7 @@ char *msg; #ifdef HAVE_STRSIGNAL - extern char *strsignal (int sig); + extern const char *strsignal (int sig); return strsignal (signum); #elif NO_SYS_SIGLIST switch (signum) I look forward to seeing the results of your experiment. >> If you must use a patched version of 0.12.0, then I'd consider incorporating >> that patch into the official cygwin dist; also, in that case, >> we could submit your patch upstream for incorporation into the "real" >> 0.13.0... >> > > As the patch just removes the embedded glib, I think its of no use > to the "real" pkgconfig. Yep, you're right. >> 3) cygextras: why not submit these as patches to the cygwin DLL? > > cygextras contains strptime and getdelim. I understand the strptime > is "coming soon" to cygwin anyway, so I'll just drop mine then. > getdelim came from the gnu C library. Again its just a distraction > from working on gnome, and I'll leave it to others to add it to > cygwin. Understood. >> 4) berkeley db: folks have been asking for this for a long time. > > No. I don't have any free time to support cygwin packages, although > I do have great respect for those, such as yourself, who do. I > think that gnome no longer requires version 2.7.7, but has moved on > to version 3.x.x. This patched version did actually pass its test > suite when I first did it, but I no longer have access to the > cygwin tcl port I used, so I cannot reproduce the result. 'Kay. Looks like there's a volunteer on the case... --Chuck
Display CDE through ssh?
Hello there! I am totaly new to this project. Installed cygwin/XFree86 like told in the documentation. Also managed to connect to my university through ssh and started some x-applications like mozill etc. by following the documentation. Beautifull! The machines at the university run HPUX with CDE. Is it possible to get the CDE-userinterface shown remoteley (like realy sitting infront of one). Greetings, Nils
Re: By the way...
On Tue, 30 Apr 2002 10:57:46 -0400
Charles Wilson <[EMAIL PROTECTED]> wrote:
> Harold Hunt wrote:
>
> > ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported
> > Software page:
> > http://xfree86.cygwin.com/ported-software.html
> >
> > I'm very impressed with your work to compile Gnome with DLLs. Keep it up!
>
>
> A couple of things:
>
> 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like to
> insure that you can use the "official" version in your port. You are
> using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0
> is now available. Could you try 0.12.0 (unpatched and/or patched) and
> see if that works for you?
I'll add that to the list of jobs ...
When I started work on gnome-vfs pkg-config was not in the "official" cygwin
distribution and 0.8.0 was the latest version. I patched it to remove the included
glib, so that it uses my glib port. When pkgconfig was added to cygwin I tried it, but
gnome-vfs would not build, so I just ignored it. My focus was, and still is, on gnome
so doing more work on pkgconfig was of no interest. But I'll certainly try the new one.
> If you must use a patched version of 0.12.0, then I'd consider
> incorporating that patch into the official cygwin dist; also, in that
> case, we could submit your patch upstream for incorporation into the
> "real" 0.13.0...
As the patch just removes the embedded glib, I think its of no use to the "real"
pkgconfig.
> 3) cygextras: why not submit these as patches to the cygwin DLL? If it
> is because the code is from gnu libc, then you could in partnership with
> someone else, reimplement them and submit the result: your partner would
> actually write the code to the specifications you develop; you would
> verify that the result operates the same as the current version.
> ("Chinese Firewall"). Then, assign copyright on the reimplementations
> to Red Hat/Cygwin, and submit!
cygextras contains strptime and getdelim. I understand the strptime is "coming soon"
to cygwin anyway, so I'll just drop mine then. getdelim came from the gnu C library.
Again its just a distraction from working on gnome, and I'll leave it to others to add
it to cygwin.
>
> 4) berkeley db: folks have been asking for this for a long time. Would
> you consider packaging it up and submitting it as an official package?
> (Don't worry about the tcl thing; you needn't be able to run the test
> suite on an "official ports only" system). side note: any idea why
> Gnome doesn't use the GNU database instead? gdbm?
No. I don't have any free time to support cygwin packages, although I do have great
respect for those, such as yourself, who do. I think that gnome no longer requires
version 2.7.7, but has moved on to version 3.x.x. This patched version did actually
pass its test suite when I first did it, but I no longer have access to the cygwin tcl
port I used, so I cannot reproduce the result.
Steven
Re: mkdll.sh
On Tue, 30 Apr 2002 02:48:20 -0400 Charles Wilson <[EMAIL PROTECTED]> wrote: > You could probably do the following: > > get rid of mkdll.sh > relibtoolize/autoconf using the "-devel" tools (e.g. make sure that > configure.in has "AC_PREREQ(2.52)") > > ./configure; make; > > It oughta work. > > --chuck > > > Harold Hunt wrote: > > > Steve, > > > > I'm working on creating Cygwin setup.exe packages for Gnome... I know, it's > > buggy but I'd like to get a start. One problem I'm having with your patches > > is that they use mkdll.sh but they don't cause configure to copy the file to > > a build directory. > > Eventually I always reach a point where mkdll.sh can't be found because > > configure didn't copy it to the out-of-the-tree build directory. > > > > Got any ideas on how to fix this? > > > > Harold This port is really an experiment. It was started before the cygwin libtool was available, and before the auto-import function of ld was available, and it's showing that age. Chuck is right, mkdll is not at all suitable for a general distribution. There are in fact several different incarnations of the mkdll script in the various gnome patches. glib was one of the first packages I played with, so it was done with the least knowledge and experience, and hence is one of the most inflexible. You could try making the path to mkdll relative to the source tree rather than the current working directory, for example by using $(top_srcdir)/mkdll.sh instead of ../mkdll.sh in Makefile.in Actually the next phase of my plan was to understand the use of autotools, and apply them to the gnome 2 packages. It should be easier there because gnome 2 has standardised on autoconf 2.5.x, whereas the gnome 1.4 packages use various old autoconf/automake versions. I have not been in any hurry though because gnome 2 is still changing much too quickly for me to have a hope of keeping up. Steven
Re: cut and paste from MS windows app to xfree (xfce) app
Hi Peter, What about using xwinclip ? It's definitly a GREAT improuvement in cygwin users everyday's life. You'll find it in the xfree page... François "The Happy xwinclip User..." Perrot - Original Message - From: "Peter W. Colovas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 30, 2002 5:43 PM Subject: cut and paste from MS windows app to xfree (xfce) app > How do I cut and paste from MS windows app to xfree (xfce) app? I can't > find anything about it in the docs or archives. Is it specific to each > WM? > Thanks, > -Pete
Re: mkdll.sh
Harold Hunt wrote:
> Chuck,
>
> Could you give a few more notes on "relibtoolize"? A pointer to some
good
> documentation would be helpful...
Well, there's the goat book http://sources.redhat.com/autobook/ but it's
a bit out of date, now...
Here's the procedure I used to "relibtoolize" libiconv. Libiconv is a
worst-case example: they distribute their own fork of autoconf itself,
they redistribute system m4 macros, ... they're just plain evil. But,
if you can understand *this*, then "relibtoolizing" anything else should
be a piece of cake...
Short version: remove autogenerated files. Replace "standard" files
with the newest versions (install-sh, mkinstalldirs, config.guess,
config.sub) -- you can also just remove these and let the autotools copy
in what they need (use the --force --c -a switches, or their analog: not
every tool has exactly the same syntax). Rerun the the autotools in the
proper order (more later).
#1) libiconv actually ships its OWN VERSION of autoconf. This is dumb.
rm autoconf/acgeneral.m4
rm autoconf/acspecific.m4
rm autoconf/aclocal.m4
rm autoconf/autoconf
rm autoconf/autoconf.m4
rm autoconf/mbstate_t.m4
#2) remove the "normal" distribution files that are created by autoconf.
rm autoconf/install-sh
rm autoconf/config.guess
rm autoconf/config.sub
rm configure
#3) remove the obsolete libtool files (libtool no longer uses "ltmain.sh")
rm autoconf/ltmain.sh
#4) I don't like hiding the autofiles, so I removed the subdir and will
change configure.in appropriately, but you don't have to do that.
rmdir autoconf
#5) libiconv doesn't use automake, but it does distribute some scripts
from automake. Replace them with the current versions. (Actually,
libiconv only distributed install-sh; it used the mkinstalldirs from the
libcharset subdirectory, "proper" auto* usage requires that each
separately configure project have its own copy...and of course, I put
install-sh in the top directory, libiconv had it in the autoconf subdir)
cp /usr/autotool/devel/share/automake/mkinstalldirs .
cp /usr/autotool/devel/share/automake/install-sh .
#6) repeat steps 1-4 for the libcharset subdirectory. Normally, this is
unnecessary, but libiconv actually treats libcharset as a separate
project, with it's own configure script and suchlike...
rm libcharset/autoconf/aclocal.m4
rm libcharset/autoconf/mkinstalldirs
rm libcharset/autoconf/install-sh
rm libcharset/autoconf/config.guess
rm libcharset/autoconf/config.sub
rm libcharset/autoconf/ltmain.sh
rm libcharset/configure
rmdir libcharset/autoconf
#7) libcharset also includes its own copies of some .m4 scripts that are
part of gettext. Use the system ones.
rm libcharset/m4/codeset.m4
rm libcharset/m4/glibc21.m4
#8) AND we're going to use the system libtool...and cleanup.
rm libcharset/m4/libtool.m4
rm libcharset/m4/ChangeLog
rmdir libcharset/m4
#9) Similar to step #5, replace the "automake" files with the latest
version (even though libcharset doesn't use automake...). Both
mkinstalldirs and install-sh WERE in the autoconf subdir of libcharset;
I put them in the top level (of libcharset). Each separately configured
project needs its own copy...
cp /usr/autotool/devel/share/automake/mkinstalldirs libcharset/
cp /usr/autotool/devel/share/automake/install-sh libcharset/
#10) As promised, I need to change a few items in configure.in (e.g.
don't use the "autoconf" subdir (or libcharset/autoconf or
libcharset/m4). Also, since the "special" versions of the autoconf
files that libiconv distributes were slightly modified -- okay, they
were distributing a fork -- I parsed out the differences they had, and
put those macros into acinclude.m4...
The patch is attached.
The patch also AC_PREREQ's 2.52 instead of 2.13 (I want to use the
-devel tree), but that required a few other changes due to
incompatibilities (AC_OUTPUT_SUBDIRS ---> AC_CONFIG_SUBDIRS, etc)
Normally, you'd also re-run autoheader at some point, but that didn't
work (thanks to the fact that libiconv uses a forked autoconf dist...)
So I patched libcharset/config.h.in by hand...
#11) Okay, here's the meat: First, we relibtoolize libcharset:
cd libcharset
aclocal
libtoolize -c -f
aclocal # (again)
autoconf
cd
aclocal
libtoolize -c -f
aclocal # (again)
autoconf
Why the second aclocal step? Because libtoolize adds additional stuff
in configure.in, which require additional macros to be pulled into
aclocal.m4. Why not run libtoolize first, and then aclocal? Because
libtoolize needs a pre-existing aclocal.m4...
Normally, you'd run "automake -a -c" between the second aclocal and
autoconf, but libiconv doesn't use automake. Also, you'd normally run
autoheader after the second aclocal -- but we can't because libiconv sucks.
Finally, you should be able to configure and make as "normal":
conf() {
(cd ${objdir} && \
${srcdir}/configure --build=${host} --target=${target} \
--srcdir=${srcdir} --prefix=${prefix} \
--exec-prefix=${pre
cut and paste from MS windows app to xfree (xfce) app
How do I cut and paste from MS windows app to xfree (xfce) app? I can't find anything about it in the docs or archives. Is it specific to each WM? Thanks, -Pete begin:vcard n:Colovas;Peter tel;work:+1 630 224 2181 x-mozilla-html:FALSE org:SPEED Platform Development;SPEED Hardware and Software Development version:2.1 email;internet:[EMAIL PROTECTED] title:Member of Technical Staff adr;quoted-printable:;;2000 N. Naperville Rd.=0D=0AP.O. Box 3033;Naperville;Illinois;60566; x-mozilla-cpt:;-22928 fn:Peter W. Colovas end:vcard
problems with kde 1.1.2 kcontrol solved
Hi, some month ago I've encountered a problem with kde 1.1.2 kcontol. The problem was, that a once called kcontrol page was hidden for further calls. Currently I have checked this with the xfree 4.2.0 release and recognizes that it this problem is gone away. Thanks for this good work. Ralf Habacker
Re: Best place for WindowMaker, Openbox, etc.?
On Tue, Apr 30, 2002 at 03:39:40PM +0100, Sam Edge wrote: >Christopher Faylor wrote in <[EMAIL PROTECTED]> >in gmane.os.cygwin.xfree on Tue, 30 Apr 2002 10:12:15 -0400: Other things that can use X such as rxvt and WindowMaker aren't part of XFree86 itself. In my opinion they should have their own directories and perhaps a new category such as "Xapps." >>> >>>I think a category of Xmanagers for WindowMaker and Openbox etc. would >>>be better. >> >>We are not talking about categories. The question was where to >>physically put the actual tar balls. > >The categories could be discussed as well. ;-) So start another thread rather than confuse the issue by responding as if you are actually answering a question that was never asked. cgf
Re: By the way...
Harold Hunt wrote:
> ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported
> Software page:
> http://xfree86.cygwin.com/ported-software.html
>
> I'm very impressed with your work to compile Gnome with DLLs. Keep it up!
A couple of things:
1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like to
insure that you can use the "official" version in your port. You are
using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0
is now available. Could you try 0.12.0 (unpatched and/or patched) and
see if that works for you?
If you must use a patched version of 0.12.0, then I'd consider
incorporating that patch into the official cygwin dist; also, in that
case, we could submit your patch upstream for incorporation into the
"real" 0.13.0...
2) libiconv/gettext: If someone 'adopts' my setup-compatible package for
libiconv -- see thes3 messages:
http://cygwin.com/ml/cygwin/2002-04/msg01558.html
http://cygwin.com/ml/cygwin/2002-02/msg00467.html
and it is included in the official cygwin dist, then I would rebuild the
official gettext package to use it. (Yes, I'm also the cygwin gettext
maintainer).
3) cygextras: why not submit these as patches to the cygwin DLL? If it
is because the code is from gnu libc, then you could in partnership with
someone else, reimplement them and submit the result: your partner would
actually write the code to the specifications you develop; you would
verify that the result operates the same as the current version.
("Chinese Firewall"). Then, assign copyright on the reimplementations
to Red Hat/Cygwin, and submit!
4) berkeley db: folks have been asking for this for a long time. Would
you consider packaging it up and submitting it as an official package?
(Don't worry about the tcl thing; you needn't be able to run the test
suite on an "official ports only" system). side note: any idea why
Gnome doesn't use the GNU database instead? gdbm?
5) libungif: just like libiconv, I have a setup-compatible package for
this. If someone wants to adopt it and submit it for official
inclusion, contact me offline.
--Chuck
RE: Installation Problems
Gregor, Thanks, I updated the setup.hint file to list this dependencies for XFree86-base. Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Gregor Herbort > Sent: Tuesday, April 30, 2002 3:40 AM > To: [EMAIL PROTECTED] > Subject: RE: Installation Problems > > > Hello, > > here what i got from Aaron Newcomb as an answer for the problem i > described > on 25. April. I tried it and it works. > > > Gregor, > > I happend to read your post on the cygwin/XFree mailing list > archive. I ran > into the same problem and was able to fix it. It seems that the new cygwin > install program does not install all the necessary libraries that > are needed > to run the XFree86 install. Here is what I had to do. > > INSTALLATION: > > 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. Save it and run setup, answer the questions and pick > up 'gettext' from the 'Libs' category. You may need to > click the "Full" (or "View") button if it doesn't show up. You might want > to make sure you update/install ALL of the following three packages: > gettext-0.10.40-1 > libintl1-0.10.40-1 > libintl-0.10.38-3 > > I also had to install pcre to get the script to run properly. I hope this > helps. You might want to pass this info back to the mailing list > if you are > still subscribed since I do not plan on subscribing right now. > > Thanks, > Aaron Newcomb > http://www.newcombnet.com > [EMAIL PROTECTED] > > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]Im Auftrag von Gregor Herbort > Gesendet: Donnerstag, 25. April 2002 11:41 > An: [EMAIL PROTECTED] > Betreff: Installation Problems > > > Hello, > > i downloaded Cygwin/XFree86. When i try to install with ./Xinstall i get a > Windows Error Message that the cygintl-1.dll is missing. > Nevertheless the Xinstall script starts and examined the file extract.exe > and comes to the conclusion that this file si not correct renamed it and > then the script stops. > Any tips? > > greetings > Gregor > > Herbort und Rottschäfer - IT-Konzeptionen > http://www.herbort-rottschaefer.de > Antoniuskirchplatz 16 > 48151 Münster > tel:0251-1367594 fax:0251-1367595 >
[ANNOUNCEMENT] New Cygwin setup.exe package: lesstif
Lesstif, http://www.lesstif.org/, is now available via setup.exe. Enjoy, Harold
RE: mkdll.sh
Chuck, Could you give a few more notes on "relibtoolize"? A pointer to some good documentation would be helpful... Is the general idea here that I would just be working on the config files and makefiles, rather than having to make extensive internal changes to the way that libraries are loaded? Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson > Sent: Tuesday, April 30, 2002 2:48 AM > To: [EMAIL PROTECTED] > Cc: cygx > Subject: Re: mkdll.sh > > > You could probably do the following: > > get rid of mkdll.sh > relibtoolize/autoconf using the "-devel" tools (e.g. make sure that > configure.in has "AC_PREREQ(2.52)") > > ./configure; make; > > It oughta work. > > --chuck > > > Harold Hunt wrote: > > > Steve, > > > > I'm working on creating Cygwin setup.exe packages for Gnome... > I know, it's > > buggy but I'd like to get a start. One problem I'm having with > your patches > > is that they use mkdll.sh but they don't cause configure to > copy the file to > > a build directory. > > > > For example: > > > > tar xzf glib-1.2.10.tar.gz > > cd glib-1.2.10 > > patch -p1 < ../glib-1.2.10-cygwin.patch > > mkdir build > > cd build > > ../configure > > [yada yada yada] > > make > > [yada yada yada] > > mkdir .libs > > ar cru .libs/libglib.a garray.o gcache.o gcompletion.o > gdataset.o gdate.o > > gerro > > r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o > > gmessages.o gm > > utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o > gstring.o > > gtimer > > .o gtree.o gutils.o > > ranlib .libs/libglib.a > > creating libglib.la > > (cd .libs && rm -f libglib.la && ln -s ../libglib.la libglib.la) > > cd .libs && PREFIX=/usr sh ../mkdll.sh libglib.la > > ../mkdll.sh: Can't open ../mkdll.sh: No such file or directory > > make[2]: *** [libglib.la] Error 2 > > make[2]: Leaving directory > > `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2. > > 10/.build' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > > `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2. > > 10/.build' > > make: *** [all-recursive-am] Error 2 > > > > > > Eventually I always reach a point where mkdll.sh can't be found because > > configure didn't copy it to the out-of-the-tree build directory. > > > > Got any ideas on how to fix this? > > > > Harold > > > > > > > > >
Re: Best place for WindowMaker, Openbox, etc.?
Christopher Faylor wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin.xfree on Tue, 30 Apr 2002 10:12:15 -0400: > >>Other things that can use X such as rxvt and WindowMaker aren't part of > >>XFree86 itself. In my opinion they should have their own directories > >>and perhaps a new category such as "Xapps." > > > >I think a category of Xmanagers for WindowMaker and Openbox etc. would > >be better. > > We are not talking about categories. The question was where to physically > put the actual tar balls. The categories could be discussed as well. ;-) I'm not sure we need a distinction between window managers and other applications in terms of categories. They all just need an X server - pretty much any X server - although some do rely on certain parts of the XFree86 distribution on the machine where they're executing. (Where this is the case they should have dependencies in setup.hint/setup.ini of course.) -- Sam Edge
RE: newbie
That all depends. Your chances are pretty good. Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of arun > Sent: Tuesday, April 30, 2002 8:42 AM > To: [EMAIL PROTECTED] > Subject: newbie > > > hello, > > I have an x windows application compiled for linux.This application > extensively uses graphics Can I directly port it to windows using > Cygwin/xfree86 ?? > > thanx
RE: Failed assertion bug using OpenOffice.org
Peter, Yes, we are aware of that bug. We're slowly getting around to working on it. Several other cases produce that same failed assertation message. Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Magnusson > Sent: Wednesday, April 24, 2002 5:21 PM > To: [EMAIL PROTECTED] > Subject: Failed assertion bug using OpenOffice.org > > > I have a setup with cygwin 1.3.9-1 and 4.2.0 of cygwin-xfree. > I have a little problem when using openoffice.org (641c) both with and > without a windowmanager. I use SuSE 7.3 Pro Linux distribution with > KDE. I use Windows 2000 Pro, SP2 (english). > > When accessing any of the menuitems a Windows(ms) dialog box pops up > saying ... > - > Faild assertion >fds_on_hold !NULL > at line 601 of /cygnus/netrel/src/cygwin-1.3.9-1/winsup/cygwin/dtable.cc > - > This seems to be a similar bug that has been reported when using KDE3 > but I am not sertain. > I get the same results using the T55 version of XWin.exe. > > I use openoffice.org a lot and it would be a lot simpler if I could use > the same environment (XWindows) when using my Windows box as well. > > > == > Peter Magnusson > mailto:[EMAIL PROTECTED] > ==
Re: newbie
/ "arun" <[EMAIL PROTECTED]> wrote: | hello, | | I have an x windows application compiled for linux.This application | extensively uses graphics Can I directly port it to windows using | Cygwin/xfree86 ?? If it is clean portable c/c++ code - yep. If you do a bunch os-specific stuff and so on, you have to put some work on it. /Andy -- The eye of the beholder rests on the beauty!
RE: upset stumper [cgf, Robert Collins, please comment]
Chris, Much better, thanks. Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor > Sent: Tuesday, April 30, 2002 10:20 AM > To: [EMAIL PROTECTED] > Subject: Re: upset stumper [cgf, Robert Collins, please comment] > > > On Tue, Apr 30, 2002 at 02:09:56AM -0400, Harold Hunt wrote: > >version: -1.2.10-1 > >install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 > >source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 > > > > > >Notice that the version is thought to be "-1.2.10-1", rather than > >"1.2.10-1". > > > >Robert, can setup.exe handle a '+' in the package name? > > upset was confused by the fact that '+' is a regex meta character. > I've checked in a fix so it should work better now. > > cgf
RE: upset stumper [cgf, Robert Collins, please comment]
Robert, I forgot to reply last night that I had hand-fixed the setup.ini file and setup.exe ran fine after that. Thanks, Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins > Sent: Tuesday, April 30, 2002 5:08 AM > To: Harold Hunt; cygx > Subject: RE: upset stumper [cgf, Robert Collins, please comment] > > > > > > -Original Message- > > From: Harold Hunt [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 30, 2002 4:10 PM > > > install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 > > source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 > > > > > > Notice that the version is thought to be "-1.2.10-1", rather > > than "1.2.10-1". > > > > Robert, can setup.exe handle a '+' in the package name? > > It should be able to. What do you see in the chooser if you point setup > at your setup.ini file (after correcting the version entry). > > Rob
Re: upset stumper [cgf, Robert Collins, please comment]
On Tue, Apr 30, 2002 at 02:09:56AM -0400, Harold Hunt wrote: >version: -1.2.10-1 >install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 >source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 > > >Notice that the version is thought to be "-1.2.10-1", rather than >"1.2.10-1". > >Robert, can setup.exe handle a '+' in the package name? upset was confused by the fact that '+' is a regex meta character. I've checked in a fix so it should work better now. cgf
Re: Best place for WindowMaker, Openbox, etc.?
On Tue, Apr 30, 2002 at 03:53:13PM +0200, Franz Wolfhagen wrote: >>Other things that can use X such as rxvt and WindowMaker aren't part of >>XFree86 itself. In my opinion they should have their own directories >>and perhaps a new category such as "Xapps." > >I think a category of Xmanagers for WindowMaker and Openbox etc. would >be better. We are not talking about categories. The question was where to physically put the actual tar balls. cgf
Re: Best place for WindowMaker, Openbox, etc.?
>Other things that can use X such as rxvt and WindowMaker aren't part >of XFree86 itself. In my opinion they should have their own >directories and perhaps a new category such as "Xapps." I think a category of Xmanagers for WindowMaker and Openbox etc. would be better. Xapps should be applications ported such as GIMP, lynx etc. Med venlig hilsen / Regards Franz Wolfhagen
Re: Best place for WindowMaker, Openbox, etc.?
Christopher Faylor wrote in <[EMAIL PROTECTED]> in gmane.os.cygwin.xfree on Mon, 29 Apr 2002 17:39:20 -0400: > If they run under it, they belong in the XFree86 hierarchy. That's > why I created it. I didn't mean to tread on any toes. I was expressing an opinion. Perhaps I should have made that clearer. Sorry. Most packages "run under" Cygwin itself, but they're not all sub-directories of release/cygwin. XFree86 is a distinct entity in its own right. Everything currently under that folder is part of the XFree86 project. Other things that can use X such as rxvt and WindowMaker aren't part of XFree86 itself. In my opinion they should have their own directories and perhaps a new category such as "Xapps." * shrug * It's a minor detail. -- Sam Edge
newbie
hello, I have an x windows application compiled for linux.This application extensively uses graphics Can I directly port it to windows using Cygwin/xfree86 ?? thanx
RE: upset stumper [cgf, Robert Collins, please comment]
> -Original Message- > From: Harold Hunt [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 4:10 PM > install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 > source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 > > > Notice that the version is thought to be "-1.2.10-1", rather > than "1.2.10-1". > > Robert, can setup.exe handle a '+' in the package name? It should be able to. What do you see in the chooser if you point setup at your setup.ini file (after correcting the version entry). Rob
RE: Installation Problems
Hello, here what i got from Aaron Newcomb as an answer for the problem i described on 25. April. I tried it and it works. Gregor, I happend to read your post on the cygwin/XFree mailing list archive. I ran into the same problem and was able to fix it. It seems that the new cygwin install program does not install all the necessary libraries that are needed to run the XFree86 install. Here is what I had to do. INSTALLATION: 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. Save it and run setup, answer the questions and pick up 'gettext' from the 'Libs' category. You may need to click the "Full" (or "View") button if it doesn't show up. You might want to make sure you update/install ALL of the following three packages: gettext-0.10.40-1 libintl1-0.10.40-1 libintl-0.10.38-3 I also had to install pcre to get the script to run properly. I hope this helps. You might want to pass this info back to the mailing list if you are still subscribed since I do not plan on subscribing right now. Thanks, Aaron Newcomb http://www.newcombnet.com [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Gregor Herbort Gesendet: Donnerstag, 25. April 2002 11:41 An: [EMAIL PROTECTED] Betreff: Installation Problems Hello, i downloaded Cygwin/XFree86. When i try to install with ./Xinstall i get a Windows Error Message that the cygintl-1.dll is missing. Nevertheless the Xinstall script starts and examined the file extract.exe and comes to the conclusion that this file si not correct renamed it and then the script stops. Any tips? greetings Gregor Herbort und Rottschäfer - IT-Konzeptionen http://www.herbort-rottschaefer.de Antoniuskirchplatz 16 48151 Münster tel:0251-1367594 fax:0251-1367595
