On 6/27/2012 9:58 AM, Charles Wilson wrote:
> Those three files are under slightly
> different licenses, but are MIT/X-ish.
Oops, I should have scrolled down farther. Looks like winpriv.c was
further modified by Jari Aalto, and actually sports a GPLv2+ license
(and re-reading the license
On 6/26/2012 8:18 PM, Eric Blake wrote:
> Broadening the question, does the cygwin community have advice on the
> best implementation of a function that returns true if the argument is a
> uid with full privileges (for example, if the uid is a member of the
> Administrator group, and can therefore
On 10/5/2011 8:10 AM, Bruno Haible wrote:
> Charles Wilson wrote:
>> The problem is, it can really cause issues for "the rest of cygwin" if
>> an app uses the Win32 API "behind cygwin's back".
>
> I understand all that. I'm only saying that
ary_fullname,
> find_shared_library_fullname, get_shared_library_fullname, relocate):
> Use it together with PIC && INSTALLDIR.
> Reported by
> via Charles Wilson .
Basically, this patch means that even if I **DO** configure with
--enable-relocation, I w
On 9/26/2011 6:00 PM, Bruno Haible wrote:
> It is normal that --enable-relocatable has a runtime cost. Certainly when
> you apply --enable-relocatable to small, fast programs like 'id' or 'pwd'
> the runtime cost will be more perceivable than with programs which run
> for longer than 1 second on av
On 9/23/2011 4:10 PM, jojelino wrote:
> It fixed the relocation problem. but led performance issue :(
>
> $ time id > /dev/null
>
> real0m0.141s
> user0m0.000s
> sys 0m0.000s
Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-reloc
On 8/18/2011 4:12 PM, Bruno Haible wrote:
> Charles Wilson writes:
>> On cygwin, we typically reautotool almost any package, as a routine part
>> of building it.
>
> You are on your own when doing this. This is not the recommended
> way to build, explained i
On 8/12/2011 1:00 PM, Bruno Haible wrote:
> [CCing bug-gettext and Charles Wilson]
> Eric Blake wrote in [1]:
>> At least cygwin still ships with
>> only gettext 0.17, because all versions of 0.18 are unbuildable on the
>> current cygwin.
>
> This is
On 2/28/2011 5:23 PM, Bruno Haible wrote:
> Thanks for the reminder. Three weeks ago, I concentrated on discussing the
> support of UCS-4 characters (still working on that). I've added minor tweaks
> (especially so as to avoid mixing the Win32 and the Cygwin approach), and
> committed this:
Thanks
On 1/28/2011 1:04 PM, Charles Wilson wrote:
> 2011-01-27 Corinna Vinschen <...>
> Charles Wilson <...>
>
> On Cygwin, use unix mechanisms instead of win32
> * progreloc.c: Prefer linux code throughout, rather than
> win32 implementat
On 2/2/2011 4:19 PM, Corinna Vinschen wrote:
> On Feb 2 19:58, Bruno Haible wrote:
>> charset.alias is requested on Linux, even though it normally does not exist,
>> so that packagers and users have a chance to modify the behaviour.
>
> I beg to keep this choice to Cygwin users as well. It will
this change might create on that platform. No
need to force code on the "real" cygwin to use outdated, and deprecated,
interfaces just to keep msys happy.
2011-01-27 Corinna Vinschen <...>
Charles Wilson <...>
On Cygwin, use unix mechanisms instead
On 9/2/2010 5:08 PM, Eric Blake wrote:
> On 09/02/2010 03:00 PM, Charles Wilson wrote:
>> Two people worked on a single patch, or someone submitted it, and then
>> one of the people with commit access modified the patch slightly. The
>> GCS says you should do t
ng the dependencies of lib${name}.
> Reported by Charles Wilson <...>.
Confirmed. I adapted this patch to the gettext-0.17 version of
lib-link.m4, and LIB*_PREFIX is now set correctly.
--
Chuck
Charles Wilson wrote:
I'll generate and
test an additional patch addressing Bruno's concerns.
Attached. Re-ran *all* of the tests described here:
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00073.html
with identical results.
I did not bump the argz.m4 serial agai
Charles Wilson wrote:
The file lib/progreloc.c has no module, and carries an embedded GPL
license. However, the intent for this file is that it is LGPL,
according to the check-in message for revision 1.5, here:
http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/lib/progreloc.c?rev=1.10&
adlink. However, to compile cleanly on mingw I also
needed a slight change to m4/readlink.m4 -- so that's included below, as
well.
Unfortunately, (1) can only be "fixed" by a license change on the
progname module. I'm going to propose that to RMS, but I'd like for
there
t we move this module from gettext
to gnulib, so I haven't worried about config/srclist.txt.
That's up to Bruno.
2006-11-03 Paul Eggert <[EMAIL PROTECTED]>
New module canonicalize-lgpl, proposed by Charles Wilson.
* MODULES.html.sh: Add canonicalize-lgpl.
[Sorry for the previous mail; I accidentally sent a reply before I was
finished writing it]
On Thu, 02 Nov 2006 09:11:46 -0800, "Paul Eggert" <[EMAIL PROTECTED]>
said:
> Charles Wilson <[EMAIL PROTECTED]> writes:
>
> > Precedent: the fts and fts-lgpl
On Thu, 02 Nov 2006 09:11:46 -0800, "Paul Eggert" <[EMAIL PROTECTED]>
said:
> Charles Wilson <[EMAIL PROTECTED]> writes:
>
> > Precedent: the fts and fts-lgpl modules each provide functionality
> > similar to the other, under different licenses -- where
The variable name is $makefile_name, the command-line option is
--makefile-name
--
Chuck
2006-11-02 Charles Wilson <...>
* gnulib-tool: fix typo
Index: gnulib-tool
===
RCS file: /sources/gnulib/gnulib/gnulib-
gpl.c
m4/canonicalize-lgpl.m4
Depends-on:
alloca-opt
allocsa
pathmax
readlink
configure.ac:
gl_CANONICALIZE_LGPL
Makefile.am:
Include:
"canonicalize-lgpl.h"
License:
LGPL
Maintainer:
Bruno Haible
%<----
2006-11-02 Charles Wilson <...>
Bruno Haible wrote:
If you got malloc/realloc #defined, it is certainly because you used
the modules 'malloc'/'realloc'.
Or I blindly accepted the recommendations of autoscan-2.60, which inserted
AC_FUNC_MALLOC
AC_FUNC_REALLOC
into configure.scan, and I didn't notice. D'oh!
And I don't un
The allocsa module includes eealloc.m4 in its filelist -- but it doesn't
"depend" on the eealloc module -- this allows the LGPL allocsa module to
avoid bringing in the GPL eealloc.h, so as not to run afoul of GPL.
If eealloc.m4's contributions to configure cause config.h to #define
malloc/real
On Fri, 20 Oct 2006 20:08:56 +0200, "Bruno Haible" said:
> Charles Wilson wrote:
> > When you call gnulib-tool --import/--update, it autogenerates a
> > Makefile.am for the library. Sometimes it is desirable to customize
> > that Makefile's behavior -- b
.
So, it this a good idea? Would a more complete patch along these lines
-- one which addressed the 'what's missing' stuff above, and any other
missing items this mailing list generates -- be an acceptable addition
to gnulib-tool? Is there a better way of handling the 'what
Doesn't seem to work properly without the following (obvious?) patch.
--
Chuck
2006-10-18 Charles Wilson
* gnulib-tool: trimming $local_gnulib_dir variable shouldn't
clobber $sourcebase.
Index: g
27 matches
Mail list logo
