On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote:
For now, I think you'll have to add a wrapper script.
Which would cause issues (dos boxes, etc) when launching from a
shortcut, unless you use run.exe or run2.exe. With run2 (assuming the
upcoming(?) release fixes the known issues), you can set
On 8/1/2013 7:19 AM, Angelo Graziosi wrote:
Charles Wilson wrote:
Is there a way to test run-2.0? What is the syntax to replace:
C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
Sure:
and how to replace
C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit
On 7/31/2013 9:41 AM, Jim Reisert AD1C wrote:
[1] http://cygwin.com/ml/cygwin/2013-07/msg00532.html
Yeah, I need to add even more runtime-debugging in run-1.0 and put out a
test release, so we can figure out what's going wrong there.
Is there a way to test run-2.0? What is the syntax to
On 8/28/2012 4:26 AM, Yaakov (Cygwin/X) wrote:
Fontconfig is WJFFM (Win7 x64, 290 .ttf files in Windows fontdir, none
with spaces). I suspect you have a corrupt or otherwise incorrect font
file in your Windows fontdir. What happens if you remove that directory
from /etc/fonts/fonts.conf? Can
While trying to debug the problem with my new build of rxvt-unicode, I
find that I am getting a segfault way down deep in libfreetype. I
rebuilt libfreetype with the new cygport, so I could get those handy
debug symbols, and spent some time trudging thru that.
Then, since libfreetype is
On 11/10/2011 11:29 AM, Ryan Pavlik wrote:
On Wed, Nov 9, 2011 at 1:11 PM, Charles Wilson wrote:
You *think* you're safe in assuming that WIN32 == !__CYGWIN__,
but...#includejpeg.h breaks all your assumptions. But jpeg.h *did
nothing wrong*.
It's better to be explicit.
--
Chuck
OK, so
On 11/9/2011 1:46 PM, Jon TURNEY wrote:
On 07/11/2011 19:36, Charles Wilson wrote:
But this isn't true if you ever #include any of the w32api headers. Then
you get WIN32 defined, even on cygwin...
True. I guess what I meant to say is that there isn't any compiler which
defines both WIN32
On 11/7/2011 1:10 PM, Jon TURNEY wrote:
I see what you are trying to do here, but I'm not sure it actually adds
any clarity.
I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN
are mutually exclusive, so '#if defined(WIN32) !defined(__CYGWIN__)'
can just be written
On 2/16/2011 6:17 PM, Srikanth Katkam wrote:
I can do rsh/ssh onto other linux machines in the network and use
all the resources on those machines but I cannot do the reverse, i.e., rsh
on to my windows machine (i.e., Cygwin X server), why the other machines
not able to see my cygwin/windows
On 10/11/2010 1:21 PM, Christopher Faylor wrote:
You probably could try to figure out if the X server is working and then
see which display is being used from that but I really don't think it
makes sense to slow down mintty to perform this check. FWIW, this
wouldn't work with the linux
On 8/20/2010 10:48 AM, Jay Goldman wrote:
I have the following menu items in my .XWinrc:
Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e
/bin/bash -l -I
dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e
/bin/bash -l -I
Which have
Marco Atzeri wrote:
Today I start some experiments and I have found that
changing the menu target from
C:\cygwin2\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
to
C:\cygwin2\bin\run.exe -p /usr/bin /usr/bin/startxwin.exe
all the problems seem gone.
The Xserver is
Jon TURNEY wrote:
On 20/01/2010 09:13, Sylvain RICHARD wrote:
Charles Wilson wrote:
I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not
sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any
events. CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just
I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not
sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any
events. CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just not zero.
This came up as I was testing the new rxvt-unicode release; it has a
special
Yaakov (Cygwin/X) wrote:
IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER
SUPPORTED.
This release replaces those scripts with a startxwin executable.
facepalm!
Sounds like a good idea, but I wish I'd known this was coming before
wasting time on:
2009-12-29 run2-0.4.0
Yaakov (Cygwin/X) wrote:
On 29/12/2009 16:27, Charles Wilson wrote:
Sounds like a good idea, but I wish I'd known this was coming before
wasting time on:
* Improve checkX behavior when used as 'barrier' in startxwin.
Sorry about that, Chuck, but this was just the latest of a long
Feng Dai wrote:
The root cause is checkX doesn't work properly. It cause XWin failed on
initClipboard and exit itself. The work around is either comment out checkX or
have a sleep 3 to let XWin server startup before checkX runs.
It's actually not checkX's fault that the Xserver dies. All
Charles Wilson wrote:
So, the latest version of checkX
I guess I should be specific: that's checkX from the run2-0.4.0-1
package, which should begin hitting the mirrors soon.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com
Linda Walsh wrote:
C.UTF_8 doesn't exist.
You're wrong. Please read the whole of this thread -- and the last two
months' worth of cygwin-developers.
mintty is broken.
No, it isn't. It just doesn't work the way *you* expect it to.
Might want to try 'Console' nstead of using mintty. Not
Thomas Dickey wrote:
On Mon, 30 Nov 2009, Andy Koppe wrote:
The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.
ok... (I thought cygwin was using GNU termcap, which supposedly works
with longer entries - though I recall _that_ being fixed
Corinna Vinschen wrote:
Isn't xterm linked against ncurses?
The new 1.7 xterm is. The old 1.5 xterm is still termcap based.
Why does it break on a termcap
file at all?
1.5 only, and it breaks because the termcap file was NOT generated using
'-r' to limit the number of allowed ':tc='
Yaakov (Cygwin/X) wrote:
On 29/11/2009 21:28, Joe Java wrote:
Gone for Thanksgiving break, return and update cygwin, and now
xterm does not show anymore. I have not upgraded to the latest 1.7 (I
am waiting for the official release). I read the other messages and
nothing seems to work.
Lothar Brendel wrote:
Unfortunately the situatiuon with ``startxwin.bat'' is worse now:
* ``checkX -t 12'' still doesn't wait (?!?)
I can't reproduce this.
* After again inserting a sleep between checkXing and starting the
xterm, the latter is marginally successful: The process is shown as
Jon TURNEY wrote:
This is typical of the current issue we have where 'run xterm' blocks when
xterm tries to output 'Warning: Missing charsets in String to FontSet
conversion'
Any one of:
- installing the CJK fonts
- having 'tty' in the CYGWIN environment variable
- having the LANG
Lothar Brendel wrote:
checkX fails due to a missing cygustr-1.dll. That's contained in which
package?
From http://cygwin.com/packages/ and typing in 'cygustr-1.dll', I get:
libustr1
This *should* have been installed by setup automatically, as the run2
package now lists libustr1 as a
Lothar Brendel wrote:
It should list, but it doesn't:
$ grep -A9 '@ run2' setup-2.ini
^^^
This was the clue.
As it happens, the union mount stuff had an override for setup.hint, but
not the entire directory. So, the tarballs themselves
I've integrated Lothar's patch into run2/checkX (along with some other
internal changes), and published a test release. Please try run-0.3.1-1
and let me know if it fixes your problems with checkX.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Lothar Brendel wrote:
Ok, this can be cured by
if (pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then) ==
ETIMEDOUT) {
xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the mutex */
xopenTrying = 0; /* allow open_display() to give up */
+
Lothar Brendel wrote:
Charles Wilson already set up this kind of infrastructure, I just had to
introduce one more communication variable, cf. the patch below
(positively tested on my system).
Yep, there are really two different purposes for a setting a timeout [i)
Just check whether an X
Jon TURNEY wrote:
But why would you fix the timeout problem by doing some horrible
horrible iteration in the DOS batch script (horrible) (which would
probably have to busy-wait (also horrible) as there's no sleep command),
when you can fix checkX, which has the bonus of fixing other uses of
Thomas Dickey wrote:
On Wed, 28 Oct 2009, Ken Brown wrote:
X11R7.5 doesn't like the (default) locale C.UTF-8. If I start the server
technically speaking, there's no such locale as C.UTF-8,
so I'd not expect portable code to accept it (C and UTF-8 are
mutually exclusive).
No, actually
Angelo Graziosi wrote:
In 'startxwin.bat' I see:
%RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error
Shouldn't it be
%RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error ?
No, run implicitly puts the target in the background, unless you add
the '-w' (wait)
Angelo Graziosi wrote:
Charles Wilson wrote:
Unfortunately, I can't reproduce.
Ugh! I forgot to say that I start those scripts with links on desktop...
For example:
mkshortcut -AD \
-n ${urxvt} \
-a bash -l start_urxvt.sh \
-i /usr/bin/XWin.exe \
-d Console unicode
Charles Wilson wrote:
Angelo Graziosi wrote:
Charles Wilson wrote:
Unfortunately, I can't reproduce.
Ugh! I forgot to say that I start those scripts with links on desktop...
For example:
mkshortcut -AD \
-n ${urxvt} \
-a bash -l start_urxvt.sh \
-i /usr/bin/XWin.exe
Jon TURNEY wrote:
Is there a reason why we can't do 'checkx -d %DISPLAY% -t 30' rather
than counting up to 30 ourselves?
Well, -t with a number larger than 12 is not useful. Xlib itself will
timeout after 12 seconds if it can't contact the xserver. The -t option
for checkx (and run2) simply
[Redirecting to cygwin-xfree; Reply-To set]
Angelo Graziosi wrote:
/usr/bin/checkX || start_XWin
[...]
Now, it happens that, often (perhaps always), if the x-server is not
running, then checkX stackdumps, in the sense I find
checkX.exe.stackdump in HOME, but it is empty! 0 bytes.
What
[redirecting, AGAIN, to cygwin-xfree. This is OT for the main cygwin list]
Unfortunately, I can't reproduce. Try running checkX with (progressively):
--no-silent
--verbose
--debug
--debug=2
--debug=3
--debug=4
this should help to narrow down how far it gets (and perhaps why) before
Guenter Millahn wrote:
just now I tried an update of my CygWin. I realized
that checkx-0.2.1-1.tar.bz is broken on all mirrors.
The checkx-0.2.1-1 package is an empty upgrade helper. It is present
only to force an update to the new package, which is called run2 --
this should have happened
Thomas Wolff wrote:
Now that cygwin supports UTF-8 in a standard fashion, I think it's time
to also add Unicode fonts to the Cygwin/X distribution. Otherwise the
additional value of running xterm or rxvt in UTF-8 mode is quite limited.
I would be willing to provide the Unicode versions of
Christopher Faylor wrote:
On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote:
DRC wrote:
Is there a spec for which files go in which packages, etc.? Any other
advice to get started, or should I just start downloading and tinkering?
Given the new modular structure of the X.org
O. Olson wrote:
Is there any way of checking if the X Server is
currently running? Because if you try this again, it
gives you “A fatal error” … which does not crash your
computer – but is a bit annoying to me.
The checkX program is written specifically to do this.
#!/bin/sh
if
of Harold's ancient package still benefit from your
support.
Don't try to retcon this thread.
that remark reflects poorly on you.
For the casual reader, google suggests that Charles Wilson called me a
liar.
No, it looked to me like you were trying to redefine the terms used in
earlier
Thomas Dickey wrote:
On Sat, 5 May 2007, Charles Wilson wrote:
The fact is, rxvt upstream is dead, dead, dead. It has shuffled off
this mortal coil. Joined the choir invisible. It is an EX-terminal.
The terminal is terminal.
thanks for agreeing with me. It has no maintainer.
Not so fast
Jason Curl wrote:
Hello all,
I'm having compilation issues with RXVT-20050409-4, after following
instructions in the /usr/share/doc/Cygwin/rxvt-20050409.README file.
In particular I'm doing:
cygport ./rxvt-20050409-X.cygport all
and it appears to fail because the xpm.h libraries don't
The current version of glib2 on cygwin is 2.10.3-1.
The current version of gtk2 on cygwin is 2.6.10-1.
gtk2 (prior to 2.8.x) uses the GMemChunk interface. 2.8.x and later use
the slice allocator.
glib-2.10.x deprecates the GMemChunk interface:
#if !defined (G_DISABLE_DEPRECATED) || defined
Larry Hall (Cygwin X) wrote:
Without the benefit of all the info that http://cygwin.com/problems.html
recommends, I can hazard a guess that you have a copy of the MKS tools
installed. These tools will conflict with the like named tools in Cygwin.
Your best bet is to remove them. You'll likely
Alan Hourihane wrote:
But, yet more thoughts. Given that Chris Corinna want a more active
person to maintain Cygwin/X - I should stand down anyway.
Thanks for having me.
Please don't go away mad. :-) Better, please don't go away, even if you
do stand down.
Even beyond the be really
Igor Pechtchanski wrote:
I don't know of an easy way to dispatch to a font name based on whether
you're running X or native. You could try playing with window names and
using this as a selector in your .Xdefaults...
Igor
Here's what I do:
(1) ~/.Xdefaults has the following (if you
Yaakov S (Cygwin Ports) wrote:
What does Cygwin native mean? If Cygwin is meant to be a POSIX
environment, then X11 should be the standard for GUI apps.
Not gonna happen: it has been stated before on this list that 'insight'
*must* run without X -- which means that tk will remain Win32GUI.
Yaakov S (Cygwin Ports) wrote:
Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't
call building gtk2 daunting;
Daunting to build it in such a way that (a) the win32 version doesn't
interfere with the X version, (b) vice versa, and (c) you're SURE that
nothing win32-runtime
Angelo Graziosi wrote:
After the new release of rebase-2.4-1, the problem remains
BUT
this time reinstalling, with setup, ONLY the
package libncurses7 (whose current release is 5.3-4),
EMACS works again!
Rebasing all and then
Angelo Graziosi wrote:
as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started
from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after
rebasing all the system.
Fine, Emacs, XEmacs, whatever. That's not the point
The problem.
There are
Don't forget the Cygwin Time Machine:
http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
ftp://www.fruitbat.org/pub/cygwin/circa/index.html
--
Chuck
Markus Jung wrote:
I have a strange effect with my cygwin/x environment.
I've downloaded a Tcl/Tk application called secpanel. secpanel is a
application tho manage ssh connection with a x-window interface.
Now, my problem is if I start the secpanel application with wish, it won't
come up in my
Marc Daumas wrote:
...although X11/Xlib.h is needed.
You've stuck your finger right on a sore spot.
tcltk is a *native MS windowing* port of tk (tcl is GUI-agnostic; tk is
the important bit wrt display technology). The X11/Xlib.h file that
cygwin's tk wants is NOT the one distributed by
Brian Ford wrote:
Charles Wilson,
Could you look at the problem discovered in the thread below and give us a
comment? Thanks.
http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
There are a couple of problems.
1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support
Harold L Hunt II wrote:
2) Consolidate the packages into xfig-lib (graphic symbols library),
xfig (everything else).
When you remove packages completely, you need to provide a compatibility
package that has the same name but higher version number. That way,
setup.exe will Do The Right
Errm, this isn't going to change the public interface is it? That is,
if Harold releases another libXt with this change, would that break the
recently re-compiled and released lesstif, etc etc?
--
Chuck
Ralf Habacker wrote:
Not sure I understand. What should be changed in the current version
Harold L Hunt II wrote:
Original from http://www.freetype.org/
Questions for other maintainers
===
1) freetype2 is built as part of XFree86 right now as a shared library,
but configuring with --enable-shared and --disable-static doesn't
produce a .dll when building
Ralf Habacker wrote:
... if linked to the static ipc-library. Using the cygipc dll results in an
additional runtime dependency, which will produce windows runtime linking
errors if the cygipc package isn't installed, which will produce more
support noise dealing with this issue. Using the static
Ralf --
What happens when you run your cygipc-based build of X11, but do not
have the ipc-daemon running? You can't run KDE, of course, but does the
Xserver itself still work properly? Can non-KDE X apps work?
--
Chuck
Harold L Hunt II wrote:
Well, that makes it easy. SHM will not be
You have to re-libtoolize using the latest libtool. I posted a patch
(for 2.2.0) to the main cygwin list on Jan 03, 2003.
--Chuck
Chris Olive wrote:
I'm trying to build glib from source (from www.gtk.org FTP mirror), and I end up with the following error during make:
OUTPUT
make[2]: Entering
Alexander Gottwald wrote:
[some stuff about magic cookies]
cygutils contains the mcookie program from util-linux, if that helps.
(It may not; I don't know much about X)
NAME
mcookie - generate magic cookies for xauth
SYNOPSIS
mcookie [-v] [-f filename ]
DESCRIPTION
Alexander Gottwald wrote:
So I don't even know where _XtInherit is called and whats different with the
relocation.
gdb revealed:
Dll1 (libXt) defines void _XtInherit(). Dll2 (libXaw) uses _XtInherit and
passes it to a function in libXt which does
if (x == _XtInherit) { foo() };
Alexander Gottwald wrote:
Alan Hourihane wrote:
I'm about to commit a patch to the XFree86 CVS that uses the new relocation
code in cygwin 1.3.18. This allows us to create the last few libraries
as shared code.
How will this affect people with cygwin 1.3.18?
It won't affect them
Harold L Hunt II wrote:
I wouldn't say that PseudoColor support is sketchy. I mean, it works fine
either in fullscreen or if you are running Windows in 8 bit color mode.
Granted, PseudoColor is not available when you are running in windowed mode
with Windows set at higher than 8 bit color.
He's referring to a very old message on this list concerning 8bit
PseudoColor support in cygwin-xfree and Cadence. Cadence is a CAD
package that requires that feature -- and since PseudoColor support in
cygwin-xfree is sketchy at best, you can't really use it to xhost
cadence. (Which is the
Ralf Habacker wrote:
The naming was probably inherited from linux, where it is possible to
have both kde (1) and kde (2) and kde (3) all installed on the same
machine. Therefore, each needs different basename.
If the kde-cygwin folks want to maintain that package-name distinction,
then
Nicholas Wourms wrote:
So? Your point? I don't want to run linux on this machine. My question
above was partially a joke and partially a rhetorical one. I don't need
to be lectured on the joy and simplicity of the explorer interface (tho
neither seem to apply). Let's not turn this
Christopher Faylor wrote:
upset would probably do the right thing with the above but I really don't
see any reason to use it, regardless. I don't see any reason why a user
would need to know that these are kdelibs-2 when it is pretty obvious from
the version number.
The naming was
Nicholas Wourms wrote:
If I'm not mistaken, I believe WinCVS does tell them to put the dll in
system.
If so, then they should be vigorously insulted, and possibly shunned.
Think of the frenchmen in Monty Python's The Holy Grail. However, I
can't find anything prominent on their site that
Harold Hunt wrote:
I haven't had any comments on this program yet because, while it is a neat
exercise and will be useful for other work, it will not be distributed with
Cygwin/XFree86 until it is written in a language that can be compiled with a
free software compiler, preferrably gcc or
Harold Hunt wrote:
That's fine about Java... but that last I knew this xlauncher was a Delphi
app. What have you got to say about that :)
WTF? I don't follow the xfree list all that closely, but didn't this
thread start out as Success with Java prog in XFree? I just assumed
that
Harold Hunt wrote:
WTF? I don't follow the xfree list all that closely, but didn't this
thread start out as Success with Java prog in XFree? I just assumed
that 'xlauncher' WAS that Java prog. Sorry for the confusion.
You know... sometimes I'm just not paying any attention at all. What
Hey, Nicholas -- don't squish Rhialto that quickly. He's probably one
of our new users who knows nothing about the cygwin project except what
he read on slashdot this morning.
The fact is, Rhialto, we focus on cygwin -- as an environment all by
itself, *and* independent of any specific
[follow up to the cygwin list; this is getting off-topic for cygwin-xfree.]
Nicholas Wourms wrote:
Hey, Nicholas -- don't squish Rhialto that quickly. He's probably one
of our new users who knows nothing about the cygwin project except what
he read on slashdot this morning.
I am still
Nicholas Wourms wrote:
People,
For the love of God, bzip2 is there for a reason, please use it. Some of
us have high mail volume and low mailbox quotas.
actually, bzip2 would probably not do a very good job compressing a png.
(I said PROBABLY. No need to post 27 counterexamples).
Harold Hunt wrote:
2) In libiconv-1.7-2.sh, prefix is set to 'prefix=/usr/local'. That should
be changed to '/usr' before this package is released, right?
Yes.
I'm sorry Chuck. I just read the link that you sent to an email that you
wrote... with very detailed answers to both of my
Ton van Overbeek wrote:
Now it seems that there is a consensus that all X specific stuff should
go in /usr/X11R6/bin, /usr/X11R6/lib,
Well, if you call Chuck reversing his original position, and Harold
agreeing with Chuck's new position, and Earnie smugly thinking 'I was
right all along'
Christopher Faylor wrote:
Just to clarify, here's what I said:
*I don't think I ever gave an opinion on the /usr/bin vs.
*/usr/X11R6/bin. My preference is that all official X stuff goes in
*/usr/X11R6/bin but that seems to be counter to the way most modern
*distributions do things.
Christopher Faylor wrote:
I don't think I ever gave an opinion on the /usr/bin vs.
/usr/X11R6/bin. My preference is that all official X stuff goes in
/usr/X11R6/bin but that seems to be counter to the way most modern
distributions do things.
So, I don't know that we have an actual
Randall R Schulz wrote:
More problem
symptoms followed. When the boot process completed the hardware scan and
got to the point where the Welcome to Windows 2000 low-resolution
splash screen would be taken down and the monitor resolution switched, I
instead got a long period of disk
Robert Collins wrote:
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 07, 2002 7:41 AM
What about using a new type respective casts for cygdaemon.
This would not break key_t compatibility and allows to
migrate single application to cygdaemon,
Ralf Habacker wrote:
It is possible though to compile xfree86 for cygwin with that enabled,
but it haven't been tested, check the mailinglist.
It works, we have done so for the kde-cygwin port
Yeah, but it requires CygIPC, doesn't it?
BTW, has anybody tried to run kde-cygwin using the
Steven O'Brien wrote:
There was no circular dependency for glib-1.2.10. In fact when I ported
it I had never heard of pkg-config.
Oh, I misunderstood you. When you said you configured pkgconfig to
build against your installed version of glib, I thought your installed
version was 1.3.x,
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
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
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
Dawson, David W wrote:
Goodness!!
cygjpeg6b.dll is part of the jpeg package of Cygwin.
WindowMaker depends upon this package.
As noted in another post, WindowMaker also depends on the tiff package.
Now that it has become evident that WindowMaker also needs these
(non-default)
Robert Collins wrote:
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 21, 2002 8:33 AM
if you select the source for more than one of [bob|bobx|boby], then it
is downloaded only once (good) but is unpacked three times. This isn't
Robert Collins wrote:
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 20, 2002 12:59 PM
Also, setup must do the following (even without new 'views'
and whatnot)
Setup should already do that, why not make a test setup.ini and see what
.
Harold
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson
Sent: Tuesday, April 16, 2002 11:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: xfree packages
I can do this -- but what was the outcome of the package name
Robert Collins wrote:
They were simple changes to the script I wrote to repackage the
distributed archives. I'll try to write proper setup.hint
files for all
the packages.
Cool.
I'm unclear about how the -src packages (are/should be) handled, since
there are a great many binary
There's another slashdot article:
http://slashdot.org/article.pl?sid=01/12/04/13552388
Seems the debian-devel folks aren't too happy about this...
--Chuck
94 matches
Mail list logo
