Hello,
* Robert Millan wrote on Wed, Feb 04, 2009 at 11:03:01PM CET:
> On Mon, Jan 19, 2009 at 12:01:04PM +0100, Robert Millan wrote:
> >
> > A triplet for GNU/kOpenSolaris has been assigned in GNU config now. Here's
> > the patch for gnulib to detect it. In addition to my previous patch, this
On Wednesday 11 February 2009 13:31:57 Karl Berry wrote:
> $ ls --version
> ls (GNU coreutils) 6.12
> Packaged by ... some distro string here ...
>
> That looks like the right place to me. I'd be tempted to put a blank
> line between "Packaged by ..." and "Copyright ...".
the attached
$ ls --version
ls (GNU coreutils) 6.12
Packaged by ... some distro string here ...
That looks like the right place to me. I'd be tempted to put a blank
line between "Packaged by ..." and "Copyright ...".
Please include a url to your downstream coreutils package in the distro string.
FYI, while looking at the problem with du -X vs. fuse and stat'ing
an excluded directory, I noticed a bogus conjunct. The patch below
removes it:
>From 66216f4811a8d82810e88371c64214191b31e244 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 11 Feb 2009 11:13:11 +0100
Subject: [PATCH] fts:
On Wednesday 11 February 2009 02:04:11 Jim Meyering wrote:
> Mike Frysinger wrote:
> ...
>
> >> > i was thinking a common change to the version-etc module to add a
> >> > "packager" field rather than having every package out there allow
> >> > people to tweak PACKAGE_NAME. what do you think of th
Paolo Bonzini wrote:
For programs' resources instead the resources should be found in a path
related to the program's path. You can also use the relocatable.c file
here. In general, this part is easier to do since most platforms
including Mac OS X have a way to find the executable.
_NSGetExec
>> For programs' resources instead the resources should be found in a path
>> related to the program's path. You can also use the relocatable.c file
>> here. In general, this part is easier to do since most platforms
>> including Mac OS X have a way to find the executable.
>>
> _NSGetExecutable
Paolo Bonzini wrote:
For programs' resources instead the resources should be found in a path
related to the program's path. You can also use the relocatable.c file
here. In general, this part is easier to do since most platforms
including Mac OS X have a way to find the executable.
_NSGetExec
Ivan Levashew wrote:
> Paolo Bonzini wrote:
>>
>> Properly fixing this would require hacking Apple's install_name_tool
>> into libtool.
>>
> Not a problem, I suppose. I have a proof of concept solution:
>
> http://mid.gmane.org/1224052823.48f5905744a99%40mail.bluebottle.com
>
> My problem is that
Paolo Bonzini wrote:
Properly fixing this would require hacking Apple's install_name_tool
into libtool.
Not a problem, I suppose. I have a proof of concept solution:
http://mid.gmane.org/1224052823.48f5905744a99%40mail.bluebottle.com
My problem is that --enable-relocatable is not present in
> I have noticed that discussions about relocatability occured in the far
> 2003. Why didn't relocatability maid its way into GTK+ and other
> autotools packages? Isn't it essential to make a "normal" program?
It is not easy. In GNU Smalltalk, for example, on Mac OS X I only make
the package rel
On Mac OS X, relocatability is a must.
Mac OS X has own means of making relocatable bundles, but they don't
fill well into gnu-lib relocatability model. It is indeed possible to
make relocatable bundle, but it's not always trivial. gnu-lib doesn't
support Mac OS X relocatability model at the m
12 matches
Mail list logo
