[9fans] another type of static linking: send all the shared libraries with the program!

[9fans] another type of static linking: send all the shared libraries with the program!

[ron minnich]

I can't help it, this one struck me as quite funny, after all the
shared library discussions we've had on this list.

"A Stanford researcher, Philip Guo, has developed a tool called CDE to
automatically package up a Linux program and all its dependencies
(including system-level libraries, fonts, etc!) so that it can be run
out of the box on another Linux machine without a lot of complicated
work setting up libraries and program versions or dealing with
dependency version hell. "

OK, so this is better than static linking how? Oh yeah you get the
fonts. And all the incompatible programs across distros.

So they've made the whole shared library mess so incredibly complex
that you now have to bundle a program's shared libraries with the
program!

Un-beeeeee-lievable.

The standard rule is, when you're in a hole, stop digging; that seems
not to apply in software nowadays.

ron

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[erik quanstrom]

> So they've made the whole shared library mess so incredibly complex
> that you now have to bundle a program's shared libraries with the
> program!
>
> Un-beeeeee-lievable.
>
> The standard rule is, when you're in a hole, stop digging; that seems
> not to apply in software nowadays.

why does this sound like post-compile autoconf/autotools?

- erik

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[Don Bailey]

So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
a packaging of localities, terminal colours, etc? Sounds great.

On Sat, Nov 13, 2010 at 12:26 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> So they've made the whole shared library mess so incredibly complex
>> that you now have to bundle a program's shared libraries with the
>> program!
>>
>> Un-beeeeee-lievable.
>>
>> The standard rule is, when you're in a hole, stop digging; that seems
>> not to apply in software nowadays.
>
> why does this sound like post-compile autoconf/autotools?
>
> - erik
>
>

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[erik quanstrom]

On Sat Nov 13 02:34:14 EST 2010, don.bailey@gmail.com wrote:
> So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
> a packaging of localities, terminal colours, etc? Sounds great.

i can't wait.  in 200-odd megabytes you can have
(a) a plan 9 distribution, or
(b) linux /bin/ls

- erik

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[Federico G. Benavento]

cinap did years ago for linux emu

http://9hal.ath.cx/usr/cinap_lenrek/lbun/mklbun

which packages linuxemu, the linux exec you want and the
required libs all in an rc bundle that you can execute
as a regular program

in:
http://9hal.ath.cx/magic/webls?dir=/usr/cinap_lenrek/lbun

you have lbuns for svn, bash and others that just work on Plan 9

On Sat, Nov 13, 2010 at 4:21 AM, ron minnich <rminnich@gmail.com> wrote:
> I can't help it, this one struck me as quite funny, after all the
> shared library discussions we've had on this list.
>
> "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> automatically package up a Linux program and all its dependencies
> (including system-level libraries, fonts, etc!) so that it can be run
> out of the box on another Linux machine without a lot of complicated
> work setting up libraries and program versions or dealing with
> dependency version hell. "
>
> OK, so this is better than static linking how? Oh yeah you get the
> fonts. And all the incompatible programs across distros.
>
> So they've made the whole shared library mess so incredibly complex
> that you now have to bundle a program's shared libraries with the
> program!
>
> Un-beeeeee-lievable.
>
> The standard rule is, when you're in a hole, stop digging; that seems
> not to apply in software nowadays.
>
> ron
>
>



--
Federico G. Benavento

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[tlaronde]

On Fri, Nov 12, 2010 at 11:21:51PM -0800, ron minnich wrote:
> I can't help it, this one struck me as quite funny, after all the
> shared library discussions we've had on this list.
>
> "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> automatically package up a Linux program and all its dependencies
> (including system-level libraries, fonts, etc!) so that it can be run
> out of the box on another Linux machine without a lot of complicated
> work setting up libraries and program versions or dealing with
> dependency version hell. "
>
> OK, so this is better than static linking how? Oh yeah you get the
> fonts. And all the incompatible programs across distros.
>
> So they've made the whole shared library mess so incredibly complex
> that you now have to bundle a program's shared libraries with the
> program!
>
> Un-beeeeee-lievable.

So "un-beeeeee-lievable" that no one is able today to statically link
a program depending on X11. Hence, this "solution" needed to solve a
problem created (I tried to statically link an app depending
"only" on X11 and motif. Hell !...[and failure]).
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] another type of static linking: send all the shared

[blstuart]

> On Sat Nov 13 02:34:14 EST 2010, don.bailey@gmail.com wrote:
>> So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
>> a packaging of localities, terminal colours, etc? Sounds great.
>
> i can't wait.  in 200-odd megabytes you can have
> (a) a plan 9 distribution, or
> (b) linux /bin/ls

That's only fair.  GNU ls is probably about the same number of
lines of code as Plan 9 :)

BLS

Re: [9fans] another type of static linking: send all the shared

[ron minnich]

On Sat, Nov 13, 2010 at 8:58 AM,  <blstuart@bellsouth.net> wrote:

> That's only fair.  GNU ls is probably about the same number of
> lines of code as Plan 9 :)

actually, I'm pretty sure the configure script is as many lines as Plan 9 :-)

ron

Re: [9fans] another type of static linking: send all the shared

[Francisco J Ballesteros]

I wonder if, 10 years from now, someone using such "static" libraries
will come up with a way to dynamically link against them.

On Sat, Nov 13, 2010 at 5:05 PM, ron minnich <rminnich@gmail.com> wrote:
> On Sat, Nov 13, 2010 at 8:58 AM,  <blstuart@bellsouth.net> wrote:
>
>> That's only fair.  GNU ls is probably about the same number of
>> lines of code as Plan 9 :)
>
> actually, I'm pretty sure the configure script is as many lines as Plan 9 :-)
>
> ron
>
>

Re: [9fans] another type of static linking: send all the shared

[erik quanstrom]

On Sat Nov 13 12:09:46 EST 2010, rminnich@gmail.com wrote:
> On Sat, Nov 13, 2010 at 8:58 AM,  <blstuart@bellsouth.net> wrote:
>
> > That's only fair.  GNU ls is probably about the same number of
> > lines of code as Plan 9 :)
>
> actually, I'm pretty sure the configure script is as many lines as Plan 9 :-)

but the configure script successfully configures ls to run on
several flavors of gnu/linux.  that's totally worth the effort.

- erik

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Fri, Nov 12, 2010 at 11:21 PM, ron minnich <rminnich@gmail.com> wrote:

> I can't help it, this one struck me as quite funny, after all the
> shared library discussions we've had on this list.
>
> "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> automatically package up a Linux program and all its dependencies
> (including system-level libraries, fonts, etc!) so that it can be run
> out of the box on another Linux machine without a lot of complicated
> work setting up libraries and program versions or dealing with
> dependency version hell. "
>
> OK, so this is better than static linking how? Oh yeah you get the
> fonts. And all the incompatible programs across distros.
>
>
Isn't this what Apple does recommend you do with application bundles?  Ship
the whole directory (.app) with all requisite frameworks and libs?


> So they've made the whole shared library mess so incredibly complex
> that you now have to bundle a program's shared libraries with the
> program!
>
> Un-beeeeee-lievable.
>
> The standard rule is, when you're in a hole, stop digging; that seems
> not to apply in software nowadays.
>
> ron
>
>

[-- Attachment #2: Type: text/html, Size: 1677 bytes --]

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Fri, Nov 12, 2010 at 11:37 PM, Federico G. Benavento <benavento@gmail.com
> wrote:

> cinap did years ago for linux emu
>
> http://9hal.ath.cx/usr/cinap_lenrek/lbun/mklbun
>
> which packages linuxemu, the linux exec you want and the
> required libs all in an rc bundle that you can execute
> as a regular program
>
> in:
> http://9hal.ath.cx/magic/webls?dir=/usr/cinap_lenrek/lbun
>
> you have lbuns for svn, bash and others that just work on Plan 9
>

Sounds handy for those programs you just *must* have.  Sometimes I want a
reasonable web browser on Plan 9 (where no web browser is a reasonable
idea).


>
> On Sat, Nov 13, 2010 at 4:21 AM, ron minnich <rminnich@gmail.com> wrote:
> > I can't help it, this one struck me as quite funny, after all the
> > shared library discussions we've had on this list.
> >
> > "A Stanford researcher, Philip Guo, has developed a tool called CDE to
> > automatically package up a Linux program and all its dependencies
> > (including system-level libraries, fonts, etc!) so that it can be run
> > out of the box on another Linux machine without a lot of complicated
> > work setting up libraries and program versions or dealing with
> > dependency version hell. "
> >
> > OK, so this is better than static linking how? Oh yeah you get the
> > fonts. And all the incompatible programs across distros.
> >
> > So they've made the whole shared library mess so incredibly complex
> > that you now have to bundle a program's shared libraries with the
> > program!
> >
> > Un-beeeeee-lievable.
> >
> > The standard rule is, when you're in a hole, stop digging; that seems
> > not to apply in software nowadays.
> >
> > ron
> >
> >
>
>
>
> --
> Federico G. Benavento
>
>

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[Jeff Sickel]

On Nov 13, 2010, at 5:14 PM, David Leimbach wrote:

> Isn't this what Apple does recommend you do with application bundles?  Ship
> the whole directory (.app) with all requisite frameworks and libs?

That's the recommended approach for certain types of distributions.  The alternative approach is to not do shared/dynamic libraries in the code you ship.  That way the only dynamically linked code is that used in the system frameworks.  Many folks also find that their applications launch faster when not traversing all sorts of dyldhell.

There's still the open-ended question of bundles of loadable modules, if you need them.

-jas

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[Bruce Ellis]

and it will be an unaswered question. o fortuna, velut luna, statu variabilis.

brucee

On Mon, Nov 15, 2010 at 1:31 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
> On Nov 13, 2010, at 5:14 PM, David Leimbach wrote:
>
>> Isn't this what Apple does recommend you do with application bundles?  Ship
>> the whole directory (.app) with all requisite frameworks and libs?
>
> That's the recommended approach for certain types of distributions.  The alternative approach is to not do shared/dynamic libraries in the code you ship.  That way the only dynamically linked code is that used in the system frameworks.  Many folks also find that their applications launch faster when not traversing all sorts of dyldhell.
>
> There's still the open-ended question of bundles of loadable modules, if you need them.
>
> -jas
>
>
>

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[EBo]

> and it will be an unaswered question. o fortuna, velut luna, statu
> variabilis.

 infinita variabiles?

Re: [9fans] another type of static linking: send all the shared libraries with the program!

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Sun, Nov 14, 2010 at 6:31 PM, Jeff Sickel <jas@corpus-callosum.com>wrote:

>
> On Nov 13, 2010, at 5:14 PM, David Leimbach wrote:
>
> > Isn't this what Apple does recommend you do with application bundles?
>  Ship
> > the whole directory (.app) with all requisite frameworks and libs?
>
> That's the recommended approach for certain types of distributions.  The
> alternative approach is to not do shared/dynamic libraries in the code you
> ship.  That way the only dynamically linked code is that used in the system
> frameworks.  Many folks also find that their applications launch faster when
> not traversing all sorts of dyldhell.
>

2-level namespaces help with that too.  You can bind paths to particular
shared library instances that you're interested in.


>
> There's still the open-ended question of bundles of loadable modules, if
> you need them.
>

There's also this vague memory I have of being deeply concerned about a
direction I swear I read somewhere on an Apple developer mailing list about
static libraries not being supported going forward with Mac OS X.


>
> -jas
>
>
>

[-- Attachment #2: Type: text/html, Size: 1721 bytes --]