On 29-Jul-05, 08:50 (CDT), GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Exercise: let's say I have an application that uses GSSAPI, and has to
> be able to be built statically. Requirements:
>
> - It should build with Heimdal's libgs
On Thu, Jul 28, 2005 at 02:18:29PM -0400, Jay Berkenbilt wrote:
> > FWIW, detecting a fixed libtool would be rather difficult, since it's the
> > libtool used by the depending application which does the recursion and
> > therefore needs to be fixed.
> I was thinking we'd be able to tell from the .
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
>> fact 3: libtool library libtool tries to implement a wrapper
>> around shared library and static library, so that both of them
>> can be uniformly processed, and allows specifying just: libtool
>> cc -lnewt a.c
St
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote:
> This is nice, but I think it's not really very autoconfish [tm] in
> spirit.
It is not meant to be autoconfish. It is meant to be run _before_
configure, so you can decide if you have to re-libtoolize the package or
not.
> Also, t
GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PAT
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
> I'd think we could come up with a way to detect the version of libtool
> in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh |
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote:
> We've had that discussion before. Last I recall there wasn't really a
> huge fight to keep them.
Well, Debian developers do not really need them. But there are people
who do not develop Debian but develop other software _using_ Deb
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Why is this better? I have to change my perfectly normal, standard Unix
> link command to use something that completely hides the actual link
> command and makes debugging problems nearly impossible?
Exercise: let's say I have an
Steve Langasek <[EMAIL PROTECTED]> writes:
> I think static libs have outlived their usefulness in Debian for the
> most part; but using this to justify creating whole *new* packages for
> static linking would just be insane. The dependencies of -dev packages
> are just not that big a deal to war
On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
> > > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > > packages except those whose headers you need. This gives optimal
> > > results
> > > for shared linking by pruning all unnecessary build-depen
Hi,
> > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > packages except those whose headers you need. This gives optimal results
> > for shared linking by pruning all unnecessary build-dependencies and
> > dependencies; but it also screws over anyone trying to
Steve Langasek <[EMAIL PROTECTED]> wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
Sounds good to me.
I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs. I
On 28-Jul-05, 03:02 (CDT), Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> fact 1: shared library
>
> gcc -lnewt a.c
Right. No problem.
> fact 2: static library
>
> gcc -lslang -lnewt a.c
Right, Just like it's always been on Unix systems.
> fact 3: libtool library
> libtool tries to impleme
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)
> FWIW, de
On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime dependencies that are also built
> > using libtool. This is the stat
Steve Langasek <[EMAIL PROTECTED]> wrote:
> - Leave the .la files in place; -dev packages need to depend on -dev
> packages corresponding to those runtime dependencies that are also built
> using libtool. This is the status quo.
If we do this (which I think we should for now), I would sugges
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > - Option 4 (requires volunteers): fix libtool
>
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why
> it is broken? Good working examples would
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > > libtool is broken in this regard and needs to be fixed to survive
Hi,
> > - Kill the .la files and .a files. Drop support for static linking. Not
> > something that should be done lightly and without prior project-wide
> > discussion.
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime depe
On Wed, Jul 27, 2005 at 10:16:54PM -0400, Josh Metzler wrote:
> On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> > But ok, yes, that is an option; let's spell the options out completely:
> >
> > - Don't ship .la files in the -dev package; don't depend on any other
> > -dev packages excep
On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> But ok, yes, that is an option; let's spell the options out completely:
>
> - Don't ship .la files in the -dev package; don't depend on any other
> -dev packages except those whose headers you need. This gives optimal
> results for shared
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > libtool is broken in this regard and needs to be fixed to survive
> > > missing files.
> > Then fix it instead of gi
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > libtool is broken in this regard and needs to be fixed to survive
> > missing files.
>
> Then fix it instead of giving people bad advice.
Do you actually have anything beyond "libtool
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > 4. -dev packages should depend on other -dev packages?
> > Yes.
> Whoah, whoah, whoah. This is just blatently false. There *certainly*
> wasn't a consensus that -dev packages should regularly depend on -dev
> pacakges. There'
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> 1. Conclusion:
> For the initial question of
> 'How does one decide which -dev package accompanies
> runtime library package'
> There is no answer, and we have not reached the consensus.
It would be possible to put forth a proposal to deal with
Hi,
Since I've started up this thread, I'd like to summarize what was
discussed in this thread.
1. Conclusion:
For the initial question of
'How does one decide which -dev package accompanies
runtime library package'
There is no answer, and we have not reached the consensus.
2. Methods to
26 matches
Mail list logo
