On Thu, 19 Jul 2012 18:57:24 +0100, Orchid Win7 v1 wrote:

> By default, GHC statically links all *Haskell* libraries. However, it
> usually does not statically link *external* libraries, as far as I can
> tell. Perhaps there's a switch somewhere to make it do that...

Maybe, I don't know. :)
 
> (And then, of course, we get into the fun of deciding which libraries
> should or should not be statically linked. E.g., apparently statically
> linking glibc is a bad idea.)

Well, glibc is a big library, but if the library you compile against has 
what you need, then it's not really any worse an idea than any other 
library.

Jim

Post a reply to this message

>> By default, GHC statically links all *Haskell* libraries. However, it
>> usually does not statically link *external* libraries, as far as I can
>> tell. Perhaps there's a switch somewhere to make it do that...
>
> Maybe, I don't know. :)

Neither do I. But I know who to ask...

>> (And then, of course, we get into the fun of deciding which libraries
>> should or should not be statically linked. E.g., apparently statically
>> linking glibc is a bad idea.)
>
> Well, glibc is a big library, but if the library you compile against has
> what you need, then it's not really any worse an idea than any other
> library.

According to the research I've done, you really don't want to statically 
link glibc, because it intimately depends on half the low-level stuff in 
the entire system. Just taking one version of glibc and trying to run it 
against the support files for another version tends to break spectacularly.

Similarly, you wouldn't want to statically link the OpenGL libraries, 
because they are specific to your GPU. Similar remarks apply to ALSA, 
apparently. And X11. And a few other things.

Let me see if I can figure out where I read all this... Ah yes, here we go:

http://freegamedev.net/wiki/Portable_binaries

Basically, it seems this stuff is pretty complicated. I suppose package 
managers were invented for a reason, eh? Pity I can't use one to solve 
my problem...

Post a reply to this message

On a related note, back in grad school in the early 90's, I once spent 2 or 
3 days tracking down a technical paper from 1985 that I needed to read. I 
had the reference and everything, and I just had to find where it was in the 
library.

The other day, I ran across someone mentioning "it makes error recovery in 
distributed systems easier" and remembered this paper. All I remembered was 
one author's name and the name of the programming language (NIL) in which it 
was being tested.

It took me about 10 minutes to find the complete text through google search, 
just by following through half a dozen references, tracking down the full 
title that way, and then googling for the full title.

I thought that was pretty cool.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On Thu, 19 Jul 2012 19:39:44 +0100, Orchid Win7 v1 wrote:

> Let me see if I can figure out where I read all this... Ah yes, here we
> go:
> 
> http://freegamedev.net/wiki/Portable_binaries
> 
> Basically, it seems this stuff is pretty complicated. I suppose package
> managers were invented for a reason, eh? Pity I can't use one to solve
> my problem...

Well, on the flip side, glibc is common to Linux systems, so it shouldn't 
be necessary to link to it.

But the simplest solution is to create a VM that has what the hosting 
provider has in it - same distro and everything - and use that as the 
development base for what you're working on.

Jim

Post a reply to this message

>> Let me see if I can figure out where I read all this... Ah yes, here we
>> go:
>>
>> http://freegamedev.net/wiki/Portable_binaries
>>
>> Basically, it seems this stuff is pretty complicated. I suppose package
>> managers were invented for a reason, eh? Pity I can't use one to solve
>> my problem...
>
> Well, on the flip side, glibc is common to Linux systems, so it shouldn't
> be necessary to link to it.

Indeed. It seems you want to /not/ link anything that's ubiquitous to 
all Linux systems, and to only link unusual stuff that probably won't be 
there.

> But the simplest solution is to create a VM that has what the hosting
> provider has in it - same distro and everything - and use that as the
> development base for what you're working on.

Yep, that would be the simplest.

I mean, if I knew what distro they're using, what packages they've 
installed, and so forth...

Post a reply to this message

On 17/07/2012 09:03 AM, Invisible wrote:
> - Finding a web hosting company that allows arbitrary CGI /binaries/ is
> seemingly impossible.

The other possibility is to use Amazon's EC2. But it's *really* expensive!

And then I stumble on this:

http://www.heroku.com/

I've never heard of it before, but it sounds interesting. (I rather 
suspect it too will end up being far too expensive...)

Post a reply to this message

>>    System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>> GNU/Linux
>
> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
> 2.6 is more mainstream, and kernel has now entered the 3.2 serie

According to some of the stuff I've read, the build system needs to be 
running the same kernel as the target system (or older).

What are my chances of finding a Linux distro that still works and 
offers the 2.4 kernel?

Post a reply to this message

Le 20/07/2012 12:14, Invisible a écrit :
>>>    System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>>> GNU/Linux
>>
>> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
>> 2.6 is more mainstream, and kernel has now entered the 3.2 serie
> 
> According to some of the stuff I've read, the build system needs to be
> running the same kernel as the target system (or older).

Not really. As an application (unless you dive into kernel structure
with root access), you practically have to have the same libc major version.
Now the itchy part: they moved from libc-5 to libc-6 during the 2.6
series (and there is a major glitch around 2.6.19 for some aspects I
just cannot remember)

It's just that compatibility of libraries is usually ascending: features
get added, so compiling against version 1.3 allows to still run on
version 1.44

Yet, major revision are allowed to break everything... sort of.
For instance, there is a certain gap between libxerces-c.2.8 and
libxerces-c.3.0 (not sure about the exact name). Some features get
dropped and some functions are gone, for real: the dynamic linker at
runtime will never find them if the new system is only installed with 3.0;

> 
> What are my chances of finding a Linux distro that still works and
> offers the 2.4 kernel?

An old CD-set of slackware ?

Post a reply to this message

>>>>     System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>>>> GNU/Linux
>>>
>>> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
>>> 2.6 is more mainstream, and kernel has now entered the 3.2 serie
>>
>> According to some of the stuff I've read, the build system needs to be
>> running the same kernel as the target system (or older).
>
> Not really. As an application (unless you dive into kernel structure
> with root access), you practically have to have the same libc major version.
> Now the itchy part: they moved from libc-5 to libc-6 during the 2.6
> series (and there is a major glitch around 2.6.19 for some aspects I
> just cannot remember)

It's all Greek to me.

> It's just that compatibility of libraries is usually ascending: features
> get added, so compiling against version 1.3 allows to still run on
> version 1.44

Yeah. So basically, if I build my stuff on a system that's /older/ than 
the target platform, it ought to work.

>> What are my chances of finding a Linux distro that still works and
>> offers the 2.4 kernel?
>
> An old CD-set of slackware ?

A better question: What are my chances of getting GHC, with it's vast 
list of complex dependencies, to work on an ancient copy of Linux?

Yeah, exactly.

Post a reply to this message

Le 20/07/2012 18:21, Orchid Win7 v1 nous fit lire :
>> It's just that compatibility of libraries is usually ascending: features
>> get added, so compiling against version 1.3 allows to still run on
>> version 1.44
> 
> Yeah. So basically, if I build my stuff on a system that's /older/ than
> the target platform, it ought to work.

Maybe... or it can fails too. What are the chance of finding libc4
library on todays system ?

Post a reply to this message