Re: Minires truncates host names
"Pierre A. Humblet" wrote:
> To me it looks like the string was already truncated when it was passed to
> the function.
>
> You can test e.g. by using exim -d+resolver -bt dan...@cygwin.com
>
> It's wonderful that you got sendmail to work.
>
> Pierre
>
Thanks for the swift reply!
I looked at Sendmails' source code. Here's the snippet which produces the output
from my first email. It's taken from the file sendmail/domain.c:
sm_dprintf("dns_getcanonname: trying %s.%s (%s)\n",
host, *dp,
# if NETINET6
qtype == T_ ? "" :
# endif /* NETINET6 */
qtype == T_A ? "A" :
qtype == T_MX ? "MX" :
"???");
errno = 0;
ret = res_querydomain(host, *dp, C_IN, qtype,
answer.qb2, sizeof(answer.qb2));
As you can see, it first prints the host to be looked up, and then passes the
string
unaltered to res_querydomain.
I will create a source release, so it can be tested.
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall breaks some packages(?)
Hi Katsumi, Katsumi Yamaoka wrote: > However, those reinstallations cause some other programs to not > work. For those other programs, rebaseall does help. Though it > breaks bzr, emacs-w3m, etc. again. It's annoying. > > Thanks in advance for your help. > Regards, I agree. It's annoying. See this post also: http://cygwin.com/ml/cygwin/2009-11/msg00894.html I'm a developer of Windows software for 15 years now, and my clients never had to rebase my binaries. I'm also a Linux teacher and I use Cygwin in class. My students (100+) repeatedly got these errors, so I switched to an improved version of apt-cyg, which does not rebase. I'm a happy teacher now. What's the deal with this "rebasing" anyway? Every compiler has a built-in mechanism to create unique offsets. Windows itself also rebases binaries at load-time. On the other hand, why not rebase at compile-time? Rebasing should not be the responsibility of the user, but of the developer. See this article: http://harshdeep.wordpress.com/2007/05/14/thou-shalt-rebase-thy-dll/ Hmm.. This turned out to be a rant. I'm sorry for hijacking your thread. Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin64 problems after update: gcc 4.8.3-2, cygcheck -p
After some extended research and trials with a fresh OpenSSL master
clone openssl32_trial this seems to be a problem of the cygwin ports of GCC.
I've added some information about this - maybe one of the developers
listening in on the OpenSSL project could have a closer look.
Wrt OpenSSL development this is not a serious problem, merely annoying
as this requires separate 32-bit and 64-bit cygwin installations to
maintain.
The 'cygcheck -p' seg fault is also not serious, merely similarly
annoying as the 32-bit installation is required to find out which
package contains a specific binary.
Any useful advice will be greatly appreciated to get away from having to
maintain two separate development environments again.
Cheers Lakhsa
P.S.: Trial for the interested: OpenSSL build configs 'Cygwin' and
'debug-Cygwin' with gcc options '-m32 -march=i686' to build 32-bit code.
Problem is present in the cygwin64 packages for gcc-core 4.8.3-2 as well
as gcc-core 4.8.2-3. Error occurs very early in the build process when
building crypto/objects:
make[2]: Entering directory
'/cygdrive/d/dev/openssl/openssl32_trial/crypto/objects'
gcc [...] -c -o obj_dat.o obj_dat.c
obj_dat.c: In function ‘OBJ_create_objects’:
obj_dat.c:781:2: error: unrecognizable insn:
}
^
(insn 30 29 31 6 (set (reg/f:SI 122)
(symbol_ref:SI ("__ctype_ptr__") [flags 0x440] )) obj_dat.c:747 -1
(nil))
obj_dat.c:781:2: internal compiler error: in extract_insn, at recog.c:2154
This problem crops up on a regular basis in the gcc.gnu.org bug tracker,
e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57099. It is not
present in cygwin64 package gcc-core-4.9.0-1, but that version results
in a linker error very late in the build process when compiling/linking
apps code. That's may be due to inconsistent/incomplete installation, so
another problem.
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-cygwin/4.9.0//libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-cygwin/4.9.0/../../../libcygwin.a when searching
for -lcygwin
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-cygwin/4.9.0/../../../libcygwin.a when searching
for -lcygwin
/usr/bin/ld: cannot find -lcygwin
/usr/bin/ld: cannot find -ladvapi32
/usr/bin/ld: cannot find -lshell32
/usr/bin/ld: cannot find -luser32
/usr/bin/ld: cannot find -lkernel32
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-pc-cygwin/4.9.0//libgcc_s.dll.a when searching for
-lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
On 05/07/2014 22:15, Lakhsa wrote:
> G'Day,
>
> after having updated my cygwin64 installation (Win7-64) for OpenSSL
> development I have encountered 2 problems:
>
> * compiling for 32-bit with '-m32 -i686' now fails with internal
> compiler error: in extract_insn, at recog.c:2154
> * cygcheck -p [any_binary] produces a seg fault
>
> Both used to work until last update of the cygwin64-only setup end of
> June 2014 from FTP server at Uni Erlangen.Both problems seem to have
> occurred in the past and seem to have been fixed in due course, so I
> wonder how they could crop up again.
>
> I've installed a completely fresh copy of cygwin64 (using
> cygwin_setup-x86_64_2.850.exe) and also a new copy of cygwin32 (using
> setup-x86_2.850.exe) via FTP. The cygwin64 gcc is 4.8.3-2 whereas the
> cygwin32 version is 4.3.8-1, but the 32-bit problem for the cygwin64 gcc
> version persists.
>
> Any idea what could be the cause of this and how to track it down viz.
> correct it would be enormously appreciated.
>
> Thanx for your attention,
>
> --
> Lakhsa
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall breaks some packages(?)
Greetings, D. Boland! >> However, those reinstallations cause some other programs to not >> work. For those other programs, rebaseall does help. Though it >> breaks bzr, emacs-w3m, etc. again. It's annoying. >> >> Thanks in advance for your help. >> Regards, > I agree. It's annoying. See this post also: > http://cygwin.com/ml/cygwin/2009-11/msg00894.html 4.5, soon 5 years. There was a lot of work over rebase and it's cooperation with setup. Can you reproduce this issue today? > I'm a developer of Windows software for 15 years now, and my clients never > had to > rebase my binaries. > I'm also a Linux teacher and I use Cygwin in class. I suggest a Linux VM, since you are a teacher. Strongly suggest. > My students (100+) repeatedly got these errors, Which are "these errors"? And how long you are using Cygwin? If you are using it from before the setup/rebase changes, may be, it's time to do a fresh install and see, if that would improve the situation? Or switch to x86-64 cygwin, which have a bit better situation with memory layout. > so I switched to an improved > version of apt-cyg, which does not rebase. I'm a happy teacher now. Unlikely it's true. More likely, it automatically rebase, but you did not notice. > What's the deal with this "rebasing" anyway? Every compiler has a built-in > mechanism to create unique offsets. Windows itself also rebases binaries at > load-time. Windows and POSIX models require different load techniques. Cygwin provide POSIX compatibility layer. > On the other hand, why not rebase at compile-time? Because it's not possible for two reasons. First, packages are compiled in many different places, and second - there's just not enough memory to place every possible Cygwin library in 32-bit address space. Neither it's feasible, as noone need every cygwin package at once. > Rebasing should not be the responsibility of the user, but of the developer. Cygwin users are developers. That's the intended audience, anyway. > See this article: > http://harshdeep.wordpress.com/2007/05/14/thou-shalt-rebase-thy-dll/ > Hmm.. This turned out to be a rant. I'm sorry for hijacking your thread. It's a simple misunderstanding, overweighted with lack of information. If you do a search through the mailing list, you can find much better explanations for the reasons of rebase, than mine. -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.07.2014, <22:18> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall breaks some packages(?)
On 06/07/2014 20:34, Andrey Repin wrote: Greetings, D. Boland! My students (100+) repeatedly got these errors, than eventually they should ask help here.. What's the deal with this "rebasing" anyway? Every compiler has a built-in mechanism to create unique offsets. Windows itself also rebases binaries at load-time. Windows and POSIX models require different load techniques. Cygwin provide POSIX compatibility layer. On Posix the fork is a fundamental function. Fork requires that all dll's on children process are reloaded at the same address used in the father process. Windows make this very difficult and rebase align dll loading spaces in NOT overlapping ones making collision and fork failures more unlikely. On the other hand, why not rebase at compile-time? on 32 bit, we will not have enough space anyway. On both platform we should syncronize all the package maintainers at a certain point for all distributed shared library, titanic job and useless as the first upgrade of any shared library package will require likely a different address space. Rebasing should not be the responsibility of the user, but of the developer. It is currently done by setup. But sometime things go wrong and a you need a fresh restart. Think of it like car tires, usually you don't touch them but if the tire breaks you need to change it. Cygwin users are developers. That's the intended audience, anyway. That is clearly a wrong assumptions. If our user were all developers we will be very few. I expect very few users of my packages to be software developers -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.07.2014, <22:18> Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: TeX Live 2014
On 04/07/2014 03:34, Ken Brown wrote: On 7/3/2014 4:49 PM, Marco Atzeri wrote: On 02/07/2014 01:16, Ken Brown wrote: Cygwin's TeX Live packages have been updated to the latest upstream release, TeX Live 2014. Question: is python3 really a requirement ? I relied on cygport for the requirements, and it found python3 as a requirement for seven of the collections. I've taken a quick look at a couple of them, and I suspect that python3 shouldn't really be required. But I'm not sure it's worth the trouble to go carefully through all seven to be sure. Ken I suggest to review the requirements currently on cygwin64 texlive is pulling both python and python3 I have strong doubts about both, and I do't see why texlive should require numpy This is coming from my last setup run python-chardet (2.0.1-2) Python character encoding detection library Required by: python-pygments python-imaging (1.1.7-5) Python Imaging Library Required by: python-pygments python-pygments (1.5-2) Python syntax highlighting module Required by: texlive-collection-binextra python3 (3.2.5-3) Py3K language interpreter Required by: texlive-collection-binextra, texlive-collection-mathextra, texlive-collection-pictures, python3-numpy, python3-tkinter, python3-setuptools python3-numpy (1.7.2-1) Py3K scientific computing module Required by: texlive-collection-pictures python3-setuptools (0.6.34-1) Py3K package management tool Required by: python3-numpy python3-tkinter (3.2.5-3) Py3K Tkinter GUI module Required by: python3 Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: regina-rexx-3.8.2-1
Version 3.8.2-1 of "regina-rexx" has been uploaded. DESCRIPTION === regina-rexx is an implementation of ANSI Standard Rexx available on many platforms. HOMEPAGE http://regina-rexx.sourceforge.com -- * Mark Hessling, m...@rexx.org http://www.rexx.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygport bug on installl
Hi Yaakov,
just found a curious bug on cygport during install phase.
during the install phase the expected behavior is
Fixing symlinks:
Fixing libtool modules:
Stripping executables:
usr/bin/cygglpk-36.dll
usr/bin/glpsol.exe
Preparing debuginfo source files:
145 files
Preparing executables for UAC:
-
However if the first level directory is a symlink
$ ls -l /pub
lrwxrwxrwx 1 marco Administrators 19 Jun 26 19:07 /pub ->
/cygdrive/e/cyg_pub
the install phase never complete.
From debug I see a that the dlname test fails as
the left term expands the symlink but the left term does not.
+ '[' /cygdrive/e/cyg_pub/devel/glpk/32bit/prova '!='
/pub/devel/glpk/32bit/prova/glpk-4.54-1/inst/usr ']'
+ dlname=../../../../../bin/cygglpk-36.dll
++ readlink -f usr/lib/../../../../..
++ __host_prefix
++ local prefix sysroot
++ inherited cross
++ local class
++ local classname
++ for class in '"$@"'
++ classname=cross
++ defined _cross_CYGCLASS_
++ (( 1 != 1 ))
++ '[' -n '' ']'
++ return 1
++ return 1
++ sysroot=
++ case ${CHOST} in
++ prefix=/usr
++ echo -n /usr
+ '[' /cygdrive/e/cyg_pub/devel/glpk/32bit '!='
/pub/devel/glpk/32bit/prova/glpk-4.54-1/inst/usr ']'
+ dlname=../../../../../../bin/cygglpk-36.dll
++ readlink -f usr/lib/../../../../../..
and go on...
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin64 problems after update: gcc 4.8.3-2, cygcheck -p
On 7/6/2014 19:04, Lakhsa wrote: > After some extended research and trials with a fresh OpenSSL master > clone openssl32_trial this seems to be a problem of the cygwin ports of GCC. > I've added some information about this - maybe one of the developers > listening in on the OpenSSL project could have a closer look. > cygwin gcc has never been built with multilib support, I don't know how it is possible that "it used to work". signature.asc Description: OpenPGP digital signature
Re: Gold star Re: [ANNOUNCEMENT] Updated: rcs-5.9.2
I use RCS every work day, it's a small, fast, flexible productivity tool, sometimes with a timed loop to save rapid editing sessions when I'm brainstorming.maybe that edit a few hours ago was worth saving after all, and with RCS I can get it back. Thank you for updating it and becoming its new maintainer. On Fri, Jul 4, 2014 at 8:18 AM, Andrew Schulman wrote: >> On Thu, Jul 03, 2014 at 07:59:42PM +0200, Achim Gratz wrote: >> >This release brings RCS to version 5.9.2 for both architectures and >> >includes a patch for the RCS work file corruption problem that has been >> >discussed on the Cygwin mailing list and reported to rcs-bugs: >> >> Could we get a gold star for Achim here? He's fixed a long-standing >> problem in RCS and taken over maintainership. >> >> Thanks Achim. > > Awarded! http://cygwin.com/goldstars/#AG > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setting character set in mintty
The way I understand it, mintty sets the LANG variable according to user settings. Would it make sense for mintty to invoke "cmd /c chcp " (SetConsoleOutputCP)? In case of no. Would it make sense to place a hint in a .bashrc about it? --pawel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Severe performance degradation of writev
2008-07-27 Corinna Vinschen * fhandler_socket.cc (fhandler_socket::send_internal): Send never more then 64K bytes at once. For blocking sockets, loop until entire data has been sent or an error occurs. (fhandler_socket::sendto): Drop code which sends on 64K bytes. (fhandler_socket::sendmsg): Ditto. This commit added workaround for KB823764. but it has brought another performance issue when writev sends <64k of data. Execute following command shows the problem. svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion subversion cygwin does split writev request into many WSASendTo call and serf library sets TCP_NODELAY for socket it uses, a WSASendTo call corresponds to a tcp packet. You can see that http header is sent being splitted when you executed above command. Whereas win32 backend of apr library doesn't exhibit such behavior by using send call. -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Severe performance degradation of writev
On 2014-07-07 AM 7:28, jojelino wrote: svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion subversion Instead of above the wrong one, this svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion > /dev/null -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Minires truncates host names
> -Original Message-
> From: D. Boland
> Sent: Sunday, July 06, 2014 03:08
>
> Thanks for the swift reply!
>
> I looked at Sendmails' source code. Here's the snippet which produces
> the output from my first email. It's taken from the file
sendmail/domain.c:
>
> sm_dprintf("dns_getcanonname: trying %s.%s
(%s)\n",
> host, *dp, # if NETINET6
> qtype == T_ ? "" :
> # endif /* NETINET6 */
> qtype == T_A ? "A" :
> qtype == T_MX ? "MX" :
> "???");
> errno = 0;
> ret = res_querydomain(host, *dp, C_IN, qtype,
> answer.qb2, sizeof(answer.qb2));
>
>
> As you can see, it first prints the host to be looked up, and then
> passes the string unaltered to res_querydomain.
>
You are right, there is a bug in res_querydomain,
Line 737 *(ptr++ - 1) = '.'; should be
*ptr++ = '.';
I would also add a debug printf at the top of the function:
DPRINTF(statp->options & RES_DEBUG, "querydomain \"%s\" \"%s\" type %d\n",
Name, DomName, Type);
Unfortunately I am not setup to build Cygwin so I can't test the above nor
submit a proper patch.
Pierre
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Gold star Re: [ANNOUNCEMENT] Updated: rcs-5.9.2
Keith Christian wrote: > I use RCS every work day, it's a small, fast, flexible productivity > tool, sometimes with a timed loop to save rapid editing sessions when > I'm brainstorming.maybe that edit a few hours ago was worth saving > after all, and with RCS I can get it back. > > Thank you for updating it and becoming its new maintainer. Seconded. Sometimes RCS is looked down upon now-adays as being superseded by more modern revision control systems, but I, too, find it invaluable both on Cygwin and other platforms that I work on. Thanks for the continued maintenance. > On Fri, Jul 4, 2014 at 8:18 AM, Andrew Schulman > wrote: >>> On Thu, Jul 03, 2014 at 07:59:42PM +0200, Achim Gratz wrote: >>> >This release brings RCS to version 5.9.2 for both architectures and >>> >includes a patch for the RCS work file corruption problem that has been >>> >discussed on the Cygwin mailing list and reported to rcs-bugs: >>> >>> Could we get a gold star for Achim here? He's fixed a long-standing >>> problem in RCS and taken over maintainership. >>> >>> Thanks Achim. >> >> Awarded! http://cygwin.com/goldstars/#AG -- Will -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Observations about Cygwin's md5 checksums
Here are five observations about md5 checksums in Cygwin. I share it in case it may be of some small interest to a few people. Please note that I may be wrong; if so, I'm happy to be corrected. 1) For each package, Cygwin stores the md5sum for the components of the main parts of the package in the setup.ini file. The exception is the setup.hint file: its md5 sum is not recorded in setup.ini. 2) In each zip file for each package, an md5.sum file is almost always provided. But not always. (*) 3) These md5.sum files list all the components of the package (including setup.hint), but these md5 sums are not reliable: they often don't match the actual md5 checksum (of the file itself, or of course the md5 stored for it in setup.ini).(**) 4) The most common file to have the wrong md5 checksum is setup.hint 5) It's not rare for files to be mentioned in a package's md5.sum which are be absent from the package itself.(***) I'm curious about the purpose of having the md5.sum file in each package. Is it a relic of a previous system? The above observations are based on a few weeks of mirroring and automatically checking the md5 sums of what we downloaded. The main site we used was aarnet.edu.au (IIRC); recently we changed to mirrors.kernel.org, but from my ad hoc checks there wasn't much difference between the two). Regards, luke (*) For mirrors.kernel.org last night: Worrying: X11/khronos-opengl-registry has no md5.sum file Worrying: X11/xlaunch has no md5.sum file Worrying: cygwin64-gcc/cygwin64-gcc-debuginfo has no md5.sum file Worrying: git/git-oodiff has no md5.sum file Worrying: git/stgit has no md5.sum file Worrying: git/tig has no md5.sum file Worrying: man has no md5.sum file Worrying: python/python-paramiko has no md5.sum file (**) $ grep FAILED [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 55 1101463 $ grep "^setup.hint: FAILED" [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 28 56 560 (***) $ wc -l < [path-omitted]/x86/cygwin-archive-all-missing-files.txt 406 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Pierre, "Pierre A. Humblet" wrote: > > You are right, there is a bug in res_querydomain, > Line 737 *(ptr++ - 1) = '.'; should be > *ptr++ = '.'; > > I would also add a debug printf at the top of the function: > DPRINTF(statp->options & RES_DEBUG, "querydomain \"%s\" \"%s\" type %d\n", > Name, DomName, Type); > > Unfortunately I am not setup to build Cygwin so I can't test the above nor > submit a proper patch. I downloaded the source code from your site: ftp://ftp.franken.de/pub/support/win32/develop/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.5/minires-0.97-src.tar.gz After a 'make', I get multiple warnings and errors, for example: resolver.h:48:6: fout: conflicting types for `dprintf´ void dprintf(char * format, ...); ^ In file included from /usr/include/string.h:10:0, from resolver.h:16, from minires.c:14: /usr/include/stdio.h:337:5: note: previous declaration of `dprintf´ was here int _EXFUN(dprintf, (int, const char *__restrict, ...) ^ Looks like the dprintf function is already defined in stdio.h. Are you using gcc? Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Re: New package: regina-rexx-3.8.2-1
Correction to regina-rexx home page: http://regina-rexx.sourceforge.net Apologies, Mark On 07/07/14 06:59, Mark Hessling wrote: Version 3.8.2-1 of "regina-rexx" has been uploaded. DESCRIPTION === regina-rexx is an implementation of ANSI Standard Rexx available on many platforms. HOMEPAGE http://regina-rexx.sourceforge.com -- * Mark Hessling, m...@rexx.org http://www.rexx.org/ * Author of THE, a Free XEDIT/KEDIT editor and, Rexx/SQL, Rexx/CURL, etc. * Maintainer of Regina Rexx interpreter * Use Rexx? join the Rexx Language Association: http://www.rexxla.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
