On Thu, 19 Jul 2012 08:56:56 +0100, Invisible wrote:

>>> Most of the discussions appear to be /very/ old.
>>
>> It's an example of how to do a search.  Use the search tools to
>> constrain the results to a more recent timeframe.
> 
> One of the discussions suggests that the correct search term is "shell
> host". This does indeed appear to generate a lot of hits...

*That's* how searching on Google is accomplished.  Learning is an 
iterative process - sometimes finding the right search combinations are a 
learning process. :)

Jim

Post a reply to this message

On Thu, 19 Jul 2012 09:50:29 +0100, Invisible wrote:

> So perhaps I should try compiling a 32-bit ELF binary and see if that
> works? (Man, is there even a way to do that with a 64-bit Linux distro?
> I'm sure there is, but finding it...)

Yes, x64 Linux systems can run ia32 ELF binaries if the library 
dependencies are met using 32-bit libraries.

Jim

Post a reply to this message

On Thu, 19 Jul 2012 10:24:00 +0100, Invisible wrote:

> Now, how much do you want to bet that a non-trivial program compiled on
> one Unix box won't run on another Unix box? :-/

If the library requirements are met, it'll run.

If they aren't, then it won't.

Jim

Post a reply to this message

>> Now, how much do you want to bet that a non-trivial program compiled on
>> one Unix box won't run on another Unix box? :-/
>
> If the library requirements are met, it'll run.
>
> If they aren't, then it won't.

Trouble is, a typical Haskell program compiled with GHC has a vast list 
of dependencies. (Off the top of my head, GMP, ncurses, libffi...)

Without shell access, it's going to be fun trying to fake that lot.

Post a reply to this message

On Thu, 19 Jul 2012 17:18:37 +0100, Orchid Win7 v1 wrote:

>>> Now, how much do you want to bet that a non-trivial program compiled
>>> on one Unix box won't run on another Unix box? :-/
>>
>> If the library requirements are met, it'll run.
>>
>> If they aren't, then it won't.
> 
> Trouble is, a typical Haskell program compiled with GHC has a vast list
> of dependencies. (Off the top of my head, GMP, ncurses, libffi...)
> 
> Without shell access, it's going to be fun trying to fake that lot.

Doesn't ghc provide a static linking option?

Jim

Post a reply to this message

On Thu, 19 Jul 2012 10:20:06 +0100, Invisible wrote:

> Interestingly, the documentation claims that all CGI scripts must begin
> with a shebang and must have execute permissions. For at least PHP, this
> is clearly untrue...

That's because with apache, php is something it knows about with mod_php*, 
so it calls scripts with the php* extensions with the php processor.

But php script does accept a #!/path/to/executable at the start as well, 
and if the path is right and the script is executable, it'll work as Perl 
or any other scripted *nix language.

Jim

Post a reply to this message

>>>> Now, how much do you want to bet that a non-trivial program compiled
>>>> on one Unix box won't run on another Unix box? :-/
>>>
>>> If the library requirements are met, it'll run.
>>>
>>> If they aren't, then it won't.
>>
>> Trouble is, a typical Haskell program compiled with GHC has a vast list
>> of dependencies. (Off the top of my head, GMP, ncurses, libffi...)
>>
>> Without shell access, it's going to be fun trying to fake that lot.
>
> Doesn't ghc provide a static linking option?

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...

(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.)

Post a reply to this message

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