On 2/7/2014 13:09, Warren Young wrote:
I want getpwent() and friends to remain available, but to switch to
AD/SAM as primary, like OS X does all the time,
I just realized that this means getpwent() turns into an AD database
linear scan at AD sites.
Hmmm...
I think I'm still in favor
On 2/6/2014 01:13, Andrey Repin wrote:
Greetings, Warren Young!
[C:\home\Daemon]$ bash -c ./foo.sh
That's not the same command I gave you. -c changes how bash.exe
interprets the following parameter.
According to `man bash', that's the correct command to execute scripts with
bash
On 2/6/2014 07:13, Corinna Vinschen wrote:
Btw., it would be a good idea to get rid of calls to getpwent/getgrent
in future. They *probably* won't do anymore what they were supposed to
do if you don't have passwd/group files.
There must be a way to list an executable's DLL imports, and
On 2/5/2014 11:30, Larry Hall (Cygwin) wrote:
On 2/5/2014 1:25 PM, Mike Rushton wrote:
does cygwin have a preferred extension for scripts ?
No, the extension can be whatever you like. By convention, bash/sh scripts
with extensions use .sh.
I'd bet there are more Bourne shell scripts in the
On 2/5/2014 14:17, Warren Young wrote:
I'd bet there are more Bourne shell scripts in the world with no
extension at all than .sh.
That said, if you're wanting to be able to double-click on a shell
script icon in Windows and associate that with Cygwin's bash.exe, you
*will* need to pick
On 2/5/2014 15:07, Andrey Repin wrote:
But if you associate .sh with bash.exe, then double-click that script
from Windows Explorer, it won't work right, since bash.exe will try to
run it as a shell script.
Have you actually tried that?
Yep.
Try it, you'll be surprised.
I did try it,
On 2/5/2014 18:00, Andrey Repin wrote:
[C:\home\Daemon]$ bash -c ./foo.sh
That's not the same command I gave you. -c changes how bash.exe
interprets the following parameter.
It matters, because when you right-click a *.sh file in Windows
Explorer, say Open With, then tell Explorer to use
On 1/24/2014 02:32, Corinna Vinschen wrote:
Nothing to worry about I guess.
I posted mainly for the maintainers, who may want to change their
setup.hint files before their next upload.
On 1/22/2014 18:13, Christopher Faylor wrote:
If you were actually volunteering to do something then it wasn't made
clear by your long email or in your lack of response to Larry's SHTDI.
I'm not going to volunteer until I have some concept of the scope of
work, and some idea of how you'd want
On 1/23/2014 08:18, Cliff Hones wrote:
One solution to this would be to reimplement it as two separate parts
Please don't hijack this thread. It is about adding a feature to
setup.exe. Replacing setup.exe isn't even on the table.
For what it's worth, though, there've been a bunch of
On 1/23/2014 10:57, Achim Gratz wrote:
Warren Young writes:
I've run into this after installing everything yesterday for my size
of Cygwin research project. Now I'm trying to remove most of that
piece by piece, but I keep getting tangled in dependency webs.
In that case (and unrelated
On 1/21/2014 23:02, Christopher Faylor wrote:
I think Corinna mentioned that she was going to get to this next
Thursday or possibly I'm misremembering and she was going to complete
work on an AI which passed the Turing Test. I can't, for the life of
me, remember which it was. Or maybe she was
While doing my how big is a full Cygwin installation research[*], I
came across some inconsistencies in package categorization:
perl_debuginfo: Not in the Debug category. It is also the only package
named *_debuginfo instead of *-debuginfo
cdrkit-doc, fftw33-doc, flac-docs, gsl-doc,
When attempting to uninstall packages with setup.exe, you can get
messages like this in the dependency resolution step:
gvfs (1.16.4-1)
GNOME virtual filesystem
Required by: dconf-service
So, you go back a screen, tell setup.exe to uninstall dconf-service,
too, but get the
Alternate idea:
If all of the changes requested on the previous screen are Uninstall
(i.e. everything else is Keep or Skip), invert the current
dependency tree walking logic. That is, have setup.exe find out which
packages must be removed to satisfy the changes requested on the
previous
Someone posted a question to Stack Overflow asking about the maximum
size of a Cygwin installation. It seems there is a dearth of hard data,
so I did the research: http://goo.gl/lu61sZ
Perhaps FAQ item 2.12 (http://goo.gl/3sl6vA) should be updated?
--
Problem reports:
On 1/17/2014 11:58, Aaron Humphrey wrote:
I had thought that cygwin 1.7 had IPv6 support,
It does, to the extent that the underlying Winsock APIs do. Basically,
you want to be on Vista or newer if you're going to depend on IPv6 under
Cygwin. IPv6 support for earlier versions of Windows was
On 1/17/2014 13:45, Aaron Humphrey wrote:
So why does it think it
requires ip6.h if it compiles fine without it?
It's probably an unwarranted Linuxism. As I read POSIX[*], it is legal
to have IPv6 definitions in the same old headers the IPv4 interface is
defined in, as Cygwin does.
So,
On 1/14/2014 05:44, Corinna Vinschen wrote:
Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of
puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora
is wrong, not following TEA? It's much easier to grok and doesn't
wrongly imply it only works on a specificx
On 1/13/2014 03:57, Jan Nijtmans wrote:
I assume someone (other than Warren Young)
uploaded it as part of the Cygwin64 bootstrap process.
Yep, not me. Probably Yaakov.
I'm not sure if a GTG is needed from another package maintainer,
If you've written a new .cygport file, I think you
On 1/14/2014 14:26, Thomas Wolff wrote:
After today's setup update, cygstart (e.g. cygstart .) fails with:
/usr/bin/cygstart.exe: error while loading shared libraries:
cygpopt-0.dll: cannot open shared object file: No such file or directory
(happened on two systems, both on Windows 7 64 bit,
On 1/14/2014 14:39, Yaakov (Cygwin/X) wrote:
On 2014-01-14 14:52, Corinna Vinschen wrote:
In how far does that affect the filename?
This is a loadable module, not a link library, and unlike other language
interpreters which load extensions directly based on file name, Tcl
package-type
On 8/9/2013 11:17, Steven Penny wrote:
Because of this dependency line
man
groff
perl
The groff package includes several helper programs written in Perl:
afmtodit, groffer, and grog.
Red Hat and Mandriva split these utilities out into a separate
package[*] but that would be something
On 1/13/2014 11:22, Christopher Faylor wrote:
In retrospect, it would have potentially made sense to use the same
versions and packaging for the 64-bit as for the 32-bit. That might
have minimized this type of problem.
An argument could be made that since these helper programs are not core
On 1/7/2014 08:53, Corinna Vinschen wrote:
On Jan 7 00:29, Jeremy Hetzler wrote:
I am getting errors when using bash redirect syntax to write to
/dev/clipboard. Reading works ok.
# this does not work
$ echo foo bar file.txt
$ cat file.txt /dev/clipboard
cat: write error: Permission denied
On 11/26/2013 02:27, Aleksander Panayotov wrote:
It was actually a typo - a missing 2. What I meant was that I tested
it with the 1.7.25 version (the latest one that was on your website
last week) and not with 1.7.5.
Okay, then.
The standard solution here is to set your installer to require
On 11/25/2013 01:57, Aleksander Panayotov wrote:
I have also tested this on Cygwin 1.7.5 and I
observe the same behaviour.
The only thing that matters on this list is whether it happens with the
*current* version. If not, the answer is simple: upgrade.
By the way, you probably lost 95% of
On 11/21/2013 15:50, Warren Young wrote:
On 11/21/2013 15:13, casem wrote:
$ procps -V
Unknown HZ value! (632) Assume 1024.
Does the warning go away if you run
$ HZ=1024 procps -V
instead?
By the way, I tried it here and didn't get the complaint.
It seems someone has set the HZ
On 11/21/2013 15:13, casem wrote:
$ procps -V
Unknown HZ value! (632) Assume 1024.
Does the warning go away if you run
$ HZ=1024 procps -V
instead?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On 11/19/2013 03:03, Corinna Vinschen wrote:
I'm also going
to look for a solution to differ between Windows 8 and 8.1 (also 2012
vs. 2012R2) in the cygcheck output.
GetVersionEx() should do it: http://goo.gl/DbhsRJ
If you follow the link to the OSVERSIONINFO structure, you will find a
On 11/19/2013 10:13, Corinna Vinschen wrote:
Why do they have to make such a mess out of a simple function like
GetVersionEx?
Backwards compatibility at all costs?
How dense is that?
Manifest Density.
(American joke.)
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 11/14/2013 12:27, Christopher Faylor wrote:
Jan, if you can send the information at the above link now, you'll be
GTG for uploading as soon as the package has been pronounced GTG by
Warrent.
Jan sent me a link to his proposed packages, which I looked at briefly,
but they've disappeared.
On 11/15/2013 06:38, Warren Young wrote:
On 11/14/2013 12:27, Christopher Faylor wrote:
Jan, if you can send the information at the above link now, you'll be
GTG for uploading as soon as the package has been pronounced GTG by
Warrent.
GTG.
I tested by unpacking the 3 main packages (exe, lib
On 11/13/2013 08:18, Christopher Faylor wrote:
On Wed, Nov 13, 2013 at 04:03:40PM +0100, Jan Nijtmans wrote:
I would like to adopt sqlite3. I've packaged the latest release.
I don't think the package is in need of adoption. Warren Young is still
around and active, AFAICT.
Jan has been
On 11/6/2013 15:31, Jean-Pierre Flori wrote:
Is there a canonical way to do so?
The canonical way is to name your import libraries so that the name of
the corresponding DLL is obvious.
Non-Cygwin import libraries are traditionally named after the DLL:
foo.lib is for foo.dll.
Cygwin's
On 11/6/2013 18:46, Warren Young wrote:
libfoo.a is for cygfoo.dll.
Sorry, that should be libfoo.dll.a is for cygfoo*.dll, where the
wildcard may be replaced by some extra version information. Use the
objtool command to narrow things down if there are multiple candidates.
--
Problem
On 11/4/2013 15:34, David Stacey wrote:
This sounds like Apache FOP [1]. This is probably a native executable;
Nope. FOP is written in Java.
Yaakov's fop package uses gcj rather than the native Windows JRE, so it
plays well with Cygwin.
--
Problem reports:
On 11/4/2013 16:05, David Stacey wrote:
I believe that Warren Young was looking at modernising the Cygwin
documentation.
That work is mostly done. There's just one thing on the 'round-tuit
list: the automatic dependency generator isn't as smart as it should be.
There are several ways
On 10/24/2013 11:33, Hardy Griech wrote:
On 24.10.2013 16:21, cygwin at kosowsky.org wrote:
:
2. Why is the start time Jan 1, 1970 (or in my case Dec 31 1969?) when
the process was only started today?
:
Timezone?
Yes. (time_t)0 is Jan 1 1970 *GMT*.
--
Problem reports:
Name: Warren Young
Package: sqlite3
SSHkey: ssh-rsa
B3NzaC1yc2EBIwAAAQEAqBYtYozG/QWEHiPmTjomT2Q6gTf5mqCxonE5JoG7HJljb4dGColaOhv1rgDjctARI5ESkXOHhhcAHt25S/gZM21+MrBYjqar9eUm3q6yXlc+XLQiNrMpfOduFuKQAWMm4d6wE0KH3iU8DUfSxXc3n8tHIYhdJc7/x3qEwS59PqhOe9hA6OV+8Sf
On 10/14/2013 01:47, Peter Rosin wrote:
On 2013-10-11 23:52, Warren Young wrote:
$ make libsqlite3.la
$ ./libtool --mode=install install libsqlite3.la /usr/local/lib
Works just fine for me.
Thanks for testing.
It turned out to be something screwed up in the local build system
libtool has long had a hack that causes it to install cyg*.dll into
bindir instead of libdir by appending /../bin to the end of the
installation directory. While trying to get SQLite 3.8.1 working on
Cygwin, I've found that this isn't working any more. (It did work in
SQLite 3.7.17.)
I've
On 10/10/2013 14:30, Christopher Faylor wrote:
On Thu, Oct 10, 2013 at 04:23:45PM -0400, cygwin AT kosowsky.org wrote:
Would it be possible to post an update of (still) missing 64 bit packages?
A list of missing packages is periodically posted to the apps list.
Isn't it just a copy of this
On 10/9/2013 01:05, Don Hatch wrote:
if I forget to set the variable, or set it wrong,
or someone else doesn't know about the variable and runs into the bug,
then corruption happens and work is irretrievably lost.
How is this more difficult than what you're already doing, manually
rolling
On 10/8/2013 04:22, Don Hatch wrote:
Checking in a text file of size = 256k
corrupts the rcs file, irretrievably losing most of the contents
It's documented in the rcs NEWS file:
- Env var RCS_MEM_LIMIT controls stdio threshold.
For speed, RCS uses memory-based routines for files
On 10/8/2013 18:30, Don Hatch wrote:
On Tue, Oct 08, 2013 at 05:48:53PM -0600, Warren Young wrote:
On 10/8/2013 04:22, Don Hatch wrote:
Checking in a text file of size = 256k
corrupts the rcs file, irretrievably losing most of the contents
It's documented in the rcs NEWS file:
That quote
On 10/8/2013 20:08, Gary Johnson wrote:
There was a discussion around March 27, 2012, about another change
in the behavior of RCS between 5.7 and 5.8. It appears that someone
decided to make some sweeping improvements to RCS and broke a few
things along the way.
GNU rcs 5.7 was released in
On 10/4/2013 09:07, Chris Olin wrote:
is there a process to have it brought into Cygwin so then all that I really
need to do is package tmux and send out an ITP?
You can adopt the libevent package yourself, which relieves Yaakov --
who maintains Cygwin Ports -- of the burden of maintaining
On 10/4/2013 10:12, Chris Olin wrote:
On 04/10/13 at 09:15am, Warren Young wrote:
libevent is in Cygwin Ports to satisfy cyphertite, ocaml-libevent,
and transmission. So, before adopting it, think about whether you
want to place yourself in a blocking position for those packages,
To clarify
On 10/1/2013 17:55, Diego Mesa wrote:
none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary 0 0
You should pound the first line out, or remove it from the file
entirely. You're trying to define two conflicting cygdrives here.
--
Problem reports:
On 9/29/2013 13:39, Angelo Graziosi wrote:
What is wrong with this command:
$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev
What happens if you modify it a bit:
$ CYGWIN_SQLITE_LOCKING=posix svn co svn://...
That forces the SQLite library that Cygwin's svn is linked
On 9/24/2013 15:43, Ulrich Pogson wrote:
I would like to run this script `for file in `find . -name *.po` ;
do msgfmt -o ${file/.po/.mo} $file ; done` in windows cmd.
What exactly do you mean by in windows cmd?
If you're trying to translate this script into cmd.exe's batch
language, it's
On 9/25/2013 00:33, Ulrich Pogson wrote:
after try everything I could not get it to work.
If my other post to this thread doesn't help, post the errors you get.
You're making us guess what is wrong with everything, and we don't
know what's wrong with everything. :)
--
Problem reports:
On 9/25/2013 02:24, wynfi...@gmail.com wrote:
Your vendor has not defined Fcntl macro O_EXLOCK,
O_EXLOCK is a BSD feature, and Cygwin tries to emulate Linux, not BSD.
Minimal testing tells me you can use Cygwin's nonstandard
F_LCK_MANDATORY feature from Perl. This script, foo.pl, doesn't
On 9/19/2013 19:15, Larry Hall (Cygwin) wrote:
On 9/19/2013 12:16 PM, Rob Siklos wrote:
My current solution is to just mount it in fstab with the following line:
c:/Users /home ntfs binary,posix=0,nouser
Alternatively, you can set HOME in your
Windows environment to point to the
On 9/17/2013 02:13, wynfi...@gmail.com wrote:
there is no gls-dev package on the cygwin site.
Run Cygwin's setup*.exe, then in the Search box on the Select Packages
screen, type gsl. That will narrow the list of top-level categories
to Debug, Devel, and Libs. Open Devel, and notice that
On 9/14/2013 15:48, Thomas Wolff wrote:
Am 14.09.2013 17:15, schrieb wynfi...@gmail.com:
checking for working ncurses... no
configure: error: Cannot find a curses library. Perhaps you failed to
install an ncurses development package?
You may be able to dig more details out of config.log.
On 9/12/2013 05:47, Ryan Johnson wrote:
I fired up a sqlite3 shell today and was dismayed to find that readline
support is AWOL...
It works here, under both MinTTY and cmd.exe.
By that I mean that I ran sqlite3, typed .help at it, then Up-Arrow
gives me .help again.
ldd reports that it is
On 9/11/2013 18:26, Yaakov (Cygwin/X) wrote:
the Fedora Cygwin repository.
That's the first I've heard of its existence. (It was apparently first
announced on Cygwin/X, which I don't subscribe to.)
Is there a getting started HOWTO somewhere?
I assume the primary advantage to using it is
On 9/12/2013 13:14, Ryan Johnson wrote:
$ ldd $(which sqlite3)
ntdll.dll = /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7772)
kernel32.dll = /cygdrive/c/Windows/system32/kernel32.dll
(0x7760)
KERNELBASE.dll = /cygdrive/c/Windows/system32/KERNELBASE.dll
On 9/11/2013 10:01, Yue Ren wrote:
$ cygport Singular-4-0-0.cygport compile
Why did you start with 'compile'? I mean, what documentation did you
read that lead you to believe that's the correct starting point? (I'm
assuming you *did* RTFM: /usr/share/doc/cygport/manual.html.)
The
On 9/4/2013 09:36, Jim Garrison wrote:
Am I missing something, or is there a reason one would want to run a
Linux emulator under a Windows emulator on Linux?
For myself, it is occasionally nice to have a Cygwin sandbox environment
to play with when I'm on one of my Macs, away from a Windows
On 9/4/2013 15:54, Earnie Boyd wrote:
On Wed, Sep 4, 2013 at 5:26 PM, Warren Young wrote:
Wine is
cheaper than a VM in terms of hardware requirements and licensing.
You must have some very expensive hardware.
I figure a VM costs me $25-50 in RAM and SSD space. Because it's not a
full OS
On 8/30/2013 08:15, Damien Doligez wrote:
I don't like RPN calculators
Infidel!
:)
I'm making good progress on porting OCaml to cygwin-64.
Would you care to summarize the problem? OCaml is already portable to
other x86_64 *ix targets, so a lot of the work has to have been done
On 8/22/2013 23:54, Michael DeByl wrote:
Sorry to be a pain
Well, here's your pain returned: This should be on the main Cygwin
mailing list, not the -apps list. :) (This list is for discussing the
*packaging* of the Cygwin apps you use, not for discussing the use of them.)
But since I
Corinna, would you please consider moving to .tar.xz for snapshots?
Two reasons:
- tar preserves the executable bit. I suspect this hasn't been a
problem in the past since unpacking with, say, the 7-Zip GUI *does* set
the executable bit, because of the archive flag hack. But now that I
On 8/23/2013 03:49, Corinna Vinschen wrote:
Since it neither makes sense to propagate the Cygwin-specific
child_info_spawn block to native processes, nor to Cygwin processes
with a different bitsize, I just disabled this, so you can now start
32 bit Cygwin processes from 64 bit Cygwin processes
On 8/23/2013 06:42, Andrew Schulman wrote:
Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't.
Hah! Another Orpie user!
I love Orpie, but sometimes I've wondered if I was the only one.
Everyone who appreciates HP RPN calculators should try Orpie.
A decent PC keyboard
On 8/23/2013 11:53, Achim Gratz wrote:
Warren Young writes:
Line 30 of main.ml is:
assert (cbreak ());
Soncurses isn't working correctly across the exec() boundary?
I don't think ncurses can work without a tty interface
Orpie runs in a cmd.exe window. ncurses must have some fall
On 8/23/2013 12:14, Corinna Vinschen wrote:
On Aug 23 14:09, Christopher Faylor wrote:
On Fri, Aug 23, 2013 at 12:00:58PM -0600, Keith Christian wrote:
Perhaps we should test to see whether we want to trade compression for time.
The only time that the end-user has to worry about is download
On 8/23/2013 13:16, Christopher Faylor wrote:
The original error message was certainly not clear but maybe we need
to have something like:
Can't run 32-bit Cygwin programs in a 64-bit Cygwin environment
and vice versa with a, as you say, (ugh) way to turn this on and off.
I don't want this
If you try something like this from a Cygwin 64 install:
$ /cygdrive/c/cygwin32/bin/ls
you get an error like this:
3 [main] ls (8168) C:\cygwin32\bin\ls.exe: *** fatal error -
cygheap base mismatch detected - 0x0/0x612A0950.
It goes on to explain that this is due to trying to load
On 8/22/2013 14:46, Earnie Boyd wrote:
On Thu, Aug 22, 2013 at 1:14 PM, Corinna Vinschen wrote:
When execveing a Cygwin process, a lot of data is submitted via shared
memory, via data copying...
Since you know that the DLL regions are different what about execing
the process as if it were a
On 8/9/2013 11:17, Steven Penny wrote:
A base 64-bit Cygwin install now requires Perl. Can this be changed? While Perl
is a fine language I hardly feel it is appropriate to add that bulk to a base
install.
Name a currently shipping Unixy system that does *not* have Perl
installed by default.
On 8/8/2013 05:08, Andrey Repin wrote:
Though, I fail to see, how Cygwin telnet is different from, say PuTTY. Or
native Windows telnet.
Windows 8 doesn't come with telnet.exe installed by default, and when
you install it from Programs and Features, it's invisible to Cygwin 32,
apparently
On 8/6/2013 16:50, Yuki Ishibashi wrote:
a) what are the standard permissions *supposed* to be on everything on
the cygwin terminal-side (i.e. 'ls -l /etc/*', etc),
Unless you existing Cygwin installation is complex, it's probably
simplest to just rename c:\cygwin to c:\oldcygwin, reinstall,
On 8/2/2013 11:15, Weston Turner wrote:
When I run a program from the shell,
...under what console/terminal? The Windows native console? MinTTY?
xterm under Cygwin/X11?
pressing the
arrow keys sends console input to the program and moves the cursor
around the terminal
Attach cygcheck
This release simply fixes the libexpat${abi}-devel naming problem
brought up by Yaakov, using the new PKG_OBSOLETES feature of cygport.
It includes no upstream release changes, because there haven't been any.
From within x86/release/expat:
wget -e robots=off --cut-dirs=3 -np -nH
On 7/30/2013 21:48, Yaakov (Cygwin/X) wrote:
* Implemented [PKG_]OBSOLETES.
It appears to function as expected for expat. Thanks!
Sorry for not getting around to testing it before release.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 7/31/2013 17:54, Linda Walsh wrote:
Warren Young wrote:
Just to emphasize: if both 32- and 64-bit Cygwin bin dirs are in your
PATH at the same time, you will get complaints in the terminal window
--
Ok, but would it be desirable (or wouldn't it be)
to have only 1 /etc, /var, /home
This release simply changes the libexpat1-devel package name to
libexpat-devel, so that it upgrades correctly if the Expat ABI ever changes.
This change should be transparent. It will happen for anyone with
libexpat1-devel installed on running setup.exe after your chosen mirror
updates.
--
This release simply changes the libexpat1-devel package name to
libexpat-devel, so that it upgrades correctly if the Expat ABI ever changes.
This change should be transparent. It will happen for anyone with
libexpat1-devel installed on running setup.exe after your chosen mirror
updates.
On 7/26/2013 23:44, marco atzeri wrote:
Il 7/27/2013 7:17 AM, Kenneth Wolcott ha scritto:
I guess I will somehow modify my PATH so that I have
/cygdrive/c/cygwin64/usr/bin and /cygdrive/c/cygwin32/usr/bin
mixing will not work as the dll's are called in the same way
Just to emphasize: if
On 7/25/2013 22:31, Warren Young wrote:
On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote:
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
$ git clone git://cygwin
On 7/26/2013 04:38, Peter Klotz wrote:
The build of Qt5Core.dll was done with Visual Studio, not with cygwin/gcc.
Qt is a C++ library. C++ compiler output is not cross-compiler
compatible. Unless I'm wrong, and this one DLL is pure C, you're not
going to be able to link it to a C++ program
On 7/25/2013 02:30, Corinna Vinschen wrote:
On Jul 24 14:38, Warren Young wrote:
On 7/24/2013 05:41, Corinna Vinschen wrote:
On Jul 24 05:12, Warren Young wrote:
You'd have to fake a -3 package set, with libexpat-devel-3 set to
obsolete libexpat1-devel-2, so that package developers would
On 7/25/2013 15:33, Ken Brown wrote:
could you provide a setup.hint for libexpat1-devel
(64 bit)? Without a setup.hint, it gets put into the Misc category and
is then installed by default.
I don't know what you're talking about. Here's the setup.hint I RFU'd:
category: Libs
requires:
On 7/25/2013 17:36, Ken Brown wrote:
Here's your RFU:
wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \
http://etr-usa.com/cygwin64/expat/
Oh, it's one of *those*. My more recent RFUs include -A'*.hint' in the
command. The *.hint files are all there on the server, if you want
On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote:
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
Cool. I will try to make use of this feature before your next release,
but don't hold
Leave 3.7.16.2-1 as curr.
From within release/sqlite3:
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.17-3*' -A'*.hint' \
-r http://etr-usa.com/cygwin64/sqlite3/
(These are the same as the 32-bit packages, released over a month ago.
I just forgot to do the 64-bit ones after I decided
I don't see any console programs on the BLODA. Shouldn't it include
programs that break under Cygwin due to things like the change from
Windows console to mintty, or the pty (?) work that improves Linux/POSIX
semantics?
Then there are the even older class of programs that didn't work right
On 7/25/2013 17:06, Larry Hall (Cygwin) wrote:
I might personally prefer to describe and list them differently.
DONOPWOL:
DOes
NOt
Play
Well with
Others
List
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On 7/25/2013 22:44, Andy Koppe wrote:
unfortunately that list would be very long anyway: basically anything
interactive that hasn't been explicitly adapted to Cygwin ptys,
Well, that gives me my example, anyway: c:\windows\system32\ftp.exe.
--
Problem reports:
On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote:
But libexpat1-devel is a BAD choice of name,
You're only having a problem with -devel, right, not the library package
proper?
Does this .cygport file solve the problem?
DESCRIPTION=Expat XML parser library
On 7/24/2013 04:06, Corinna Vinschen wrote:
Regardless of libexpat1-devel supposedly being a bad choice of names,
from the global distro perspective, it would be much easier to remove
the libexpat-devel package from the 64 bit distro and go over the hint
files manually for now.
Doesn't the
On 7/24/2013 05:41, Corinna Vinschen wrote:
On Jul 24 05:12, Warren Young wrote:
You'd have to fake a -3 package set, with libexpat-devel-3 set to
obsolete libexpat1-devel-2, so that package developers would
automatically get new packages on their next Cygwin update.
If you're willing to do
On 7/12/2013 12:49, fger...@gmx.de wrote:
But since 3.7.17-3 I cannot read my databases any more
unable to open datase file.
Without a test case, debugging this will amount to testing guesses.
My first guess: try setting the new CYGWIN_SQLITE_LOCKING environment
variable to posix. That can
On 7/17/2013 18:27, Christopher Faylor wrote:
Why was this thread redirected to cygwin-apps?
The thread started here, and I replied here. David Rothenberger tried
to redirect it to the main list.
On 7/17/2013 17:15, fger...@gmx.de wrote:
Von: Warren Young war...@etr-usa.com
try setting the new CYGWIN_SQLITE_LOCKING environment
variable to posix.
Why isn't it the default?
Because there are more native Windows programs based on SQLite than
there are Cygwin programs based on SQLite
On 6/20/2013 12:10, Corinna Vinschen wrote:
If every maintainer would use cygport, it would allow us to change
the build method to one along the lines of most Linux distros.
In Linux distros, the maintainer provides only the spec file and
the source archive. The actual build for all
401 - 500 of 1041 matches
Mail list logo
