Linux 'quasi-static' build

[Jon Leighton]

Hi folks,

As explained last week, when I came to build the Linux packages for
release, I had some problems with the new 'quasi-static' setup.

For example, I had built the 64 bit package in a 64 bit Ubuntu Lucid VM.
I then tried to run the binary on my own 64 bit host machine (Fedora
16). It ran just fine, but when I tried to actually request a page, the
request always failed instantly. I am not sure why it failed - there are
no obvious reasons that I can see.

My general feeling is that the quasi-static setup seems a bit
complicated and clever. I don't personally understand all the nuances of
the low-level Linux machinery like ELF headers and ABI compatibility,
etc, so it seems a bit problematic to maintain this solution unless
there is somebody who is better-informed who has the time to get to the
bottom of these issues.

It seems like the solution is really only for the benefit of users who
want to run the PhantomJS binary on older distros. I think it's fair to
say that these are a minority, and to me it seems acceptable to just ask
such users to build from source.

So I am proposing that we remove the quasi-static stuff. See
https://github.com/ariya/phantomjs/pull/282

I hope this doesn't come across the wrong way. I appreciate the effort
that Milian put in, but it seems like a problem to maintain.

Cheers,
Jon

[Ariya Hidayat]

I admit I didn't check it with 64-bit. I don't mind this is to be
reverted until we find the solution and/or a better almost-static
alternative.

Milian, what do you think?


Regards,


--
Ariya Hidayat, http://ariya.ofilabs.com
http://twitter.com/ariyahidayat

[Milian Wolff]

On Tuesday 26 June 2012 08:22:11 Ariya Hidayat wrote:
> I admit I didn't check it with 64-bit. I don't mind this is to be
> reverted until we find the solution and/or a better almost-static
> alternative.
>
> Milian, what do you think?

I don't get it: This deployment step is totally optional, so if people don't
want to use it (i.e. it messes things up for them), then they could just not
use it?

Furthermore, I tested this on a 64Bit built-host and successfully ran these on
different 32bit and 64bit machines - both older distros and newer ones. So if
this step really breaks things for you, I'd be interested in knowing whats
going on (which distro? does it work without deployment step? ...)

Cheers

PS: I won't be able to respond to emails until next week, so please stay
tuned.
--
Milian Wolff
ma...@milianw.de
http://milianw.de

[Jon Leighton]

Hi Milian,

Thanks for replying.

On 26/06/12 21:36, Milian Wolff wrote:
> On Tuesday 26 June 2012 08:22:11 Ariya Hidayat wrote:
>> I admit I didn't check it with 64-bit. I don't mind this is to be
>> reverted until we find the solution and/or a better almost-static
>> alternative.
>>
>> Milian, what do you think?
>
> I don't get it: This deployment step is totally optional, so if people don't
> want to use it (i.e. it messes things up for them), then they could just not
> use it?

That's a good point. I assumed that because the script was added to the
phantomjs repository, it had become the "blessed" way to create the
linux package which gets distributed on google code. We could make it an
optional step in the script (e.g. via a command line option), and then
the question of whether to use it for the "official" linux packages is a
separate one.

Do you use this script to create your own packages? If so, I presume
that's because you need to deploy to multiple different systems and
don't want to recompile for each target system? (Just trying to better
understand the use case.)

> Furthermore, I tested this on a 64Bit built-host and successfully ran these on
> different 32bit and 64bit machines - both older distros and newer ones. So if
> this step really breaks things for you, I'd be interested in knowing whats
> going on (which distro? does it work without deployment step? ...)

Yes, it definitely breaks and it's definitely not an issue when
switching back to not changing the ELF header and not bundling
additional libraries other than the Qt ones and fontconfig + truetype.

As I stated in my email, the program does run successfully, but it fails
when trying to load any page. If you want to take a look, here is the
package that I originally built using the full 'quasi-static' setup:

http://dump.jonathanleighton.com/phantomjs-1.6.0-linux-x86_64-dynamic.tar.bz2

The package was built in an Ubuntu Lucid x86_64 virtual machine. I then
tested it on my host machine, which is Fedora 16 x86_64. Running a
simple script like this:

var page = require('webpage').create()
page.open('http://google.com/', function(status) {
console.log(status)
})

results in "fail" being printed to the terminal. The page does not load
successfully for reasons that are unknown to me.

This symptom also matches the problem reported in the recent thread
titled "Anyone having problem with ver1.6 linux version?" [which related
to the 32 bit package, not 64 bit], although I can't say for sure
whether that was the same issue.

I have some questions regarding the brandelf step. Please excuse my
ignorance, I couldn't find any obvious answers during my own research...

We use brandelf to change the header to state that the binary adheres to
the SysV ABI. Are there no differences between the SysV ABI and the
Linux ABI? Is it safe to just "rebrand" like this? (I.e. do we not need
to compile for SysV ABI compatibility from the start?)

[Note that this can't be the source of the issue I experienced, as the
binary on Ubuntu Lucid comes out with the SysV ABI anyway.]

Also, do you know how this setup interacts with Qt's efforts to detect
SSL libraries at runtime?

Thanks,
Jon

[Milian Wolff]

Hey Jonathan,

see my comments inline below.

On Wednesday, June 27, 2012 1:11:57 AM UTC+2, Jonathan Leighton wrote:

Hi Milian,

Thanks for replying.

On 26/06/12 21:36, Milian Wolff wrote:
> On Tuesday 26 June 2012 08:22:11 Ariya Hidayat wrote:
>> I admit I didn't check it with 64-bit. I don't mind this is to be
>> reverted until we find the solution and/or a better almost-static
>> alternative.
>>
>> Milian, what do you think?
>
> I don't get it: This deployment step is totally optional, so if people don't
> want to use it (i.e. it messes things up for them), then they could just not
> use it?

That's a good point. I assumed that because the script was added to the
phantomjs repository, it had become the "blessed" way to create the
linux package which gets distributed on google code. We could make it an
optional step in the script (e.g. via a command line option), and then
the question of whether to use it for the "official" linux packages is a
separate one.

I never thought about this usecase, though it would certainly make sense and be quite helpful to have an easy tarball available which one could use to test PhantomJS locally without building it by oneself...
 

Do you use this script to create your own packages? If so, I presume
that's because you need to deploy to multiple different systems and
don't want to recompile for each target system? (Just trying to better
understand the use case.)

My usecase, or better one of our customers usecase, was to use PhantomJS on archaic linux distros like RHEL 5 or old SLED versions. It was simply much better in terms of time efficiency and availability of up2date dependencies to built PhantomJS on a new machine and then deploy some package to the server(s).

In our tests this turned out to be effective and the script I upstreamed works like a charm for us.
 

> Furthermore, I tested this on a 64Bit built-host and successfully ran these on
> different 32bit and 64bit machines - both older distros and newer ones. So if
> this step really breaks things for you, I'd be interested in knowing whats
> going on (which distro? does it work without deployment step? ...)

Yes, it definitely breaks and it's definitely not an issue when
switching back to not changing the ELF header and not bundling
additional libraries other than the Qt ones and fontconfig + truetype.

Are you sure that both is required? I.e. not changing the ELF header *and* not shipping the other libs? Or is one or the other step enough to make it work again? When I test your package below, removing the non-Qt libs makes it work even though their ELF ABI was changed - so I somehow doubt this is the issue?
 

As I stated in my email, the program does run successfully, but it fails
when trying to load any page. If you want to take a look, here is the
package that I originally built using the full 'quasi-static' setup:

http://dump.jonathanleighton.com/phantomjs-1.6.0-linux-x86_64-dynamic.tar.bz2

The package was built in an Ubuntu Lucid x86_64 virtual machine. I then
tested it on my host machine, which is Fedora 16 x86_64. Running a
simple script like this:

var page = require('webpage').create()
page.open('http://google.com/', function(status) {
   console.log(status)
})

results in "fail" being printed to the terminal. The page does not load
successfully for reasons that are unknown to me.

Yep, I can confirm this issue on my 64bit archlinux box - odd! Moving the following libraries out of the libs folder makes your example work for me:

ld-linux-x86-64.so.2  libc.so.6  libdl.so.2  libpthread.so.0

Then changing the phantomjs wrapper to not run the actual binary through ld-linux-x86-64.so.2 makes it work. I can safely say though that this will break on old machines as this step is crucial there in order to access the new features of libc e.g. there.

 

This symptom also matches the problem reported in the recent thread
titled "Anyone having problem with ver1.6 linux version?" [which related
to the 32 bit package, not 64 bit], although I can't say for sure
whether that was the same issue.

I have some questions regarding the brandelf step. Please excuse my
ignorance, I couldn't find any obvious answers during my own research...

We use brandelf to change the header to state that the binary adheres to
the SysV ABI. Are there no differences between the SysV ABI and the
Linux ABI? Is it safe to just "rebrand" like this? (I.e. do we not need
to compile for SysV ABI compatibility from the start?)

I am in the same situation: I don't know much about whats going on in the background. I just noticed that I cannot run ELFs with the Linux ABI on archaic systems (since they don't know that relatively new ELF ABI). I stumbled upon brandelf, tried it out and it worked like a charm for my tests (i.e. RHEL 5 etc). If you - or anyone else - could tell me how to configure Qt + PhantomJS such that it uses the old SysV ABI we could of course try this out and see whether it helps with the problem above.

 

[Note that this can't be the source of the issue I experienced, as the
binary on Ubuntu Lucid comes out with the SysV ABI anyway.]

Also, do you know how this setup interacts with Qt's efforts to detect
SSL libraries at runtime?

No, I have no idea about that - but I doubt that this is the issue here as other simpler pages that don't use SSL show the same issue (i.e. don't load properly). I rather think something odd happens with the libraries, but I don't really know whats going on here...

So my advise would be to make the step which includes ld-linux, libc etc. as well as the brandelf step in the quasi-static build optional as these are only required if we want to deploy to an archaic linux. There they are crucial though and do (did?) work just fine for me.

[Jon Leighton]

Hi Milian,

> Yes, it definitely breaks and it's definitely not an issue when
> switching back to not changing the ELF header and not bundling
> additional libraries other than the Qt ones and fontconfig + truetype.
>
>
> Are you sure that both is required? I.e. not changing the ELF header
> *and* not shipping the other libs? Or is one or the other step enough to
> make it work again? When I test your package below, removing the non-Qt
> libs makes it work even though their ELF ABI was changed - so I somehow
> doubt this is the issue?

Yeah, I don't think the ELF header is the issue because it actual fact
the build was done on a Ubuntu Lucid box and came out using the SysV ABI
anyway. So the Linux ABI was never involved and hence the brandelf step
was a noop.

> We use brandelf to change the header to state that the binary
> adheres to
> the SysV ABI. Are there no differences between the SysV ABI and the
> Linux ABI? Is it safe to just "rebrand" like this? (I.e. do we not need
> to compile for SysV ABI compatibility from the start?)
>
>
> I am in the same situation: I don't know much about whats going on in
> the background. I just noticed that I cannot run ELFs with the Linux ABI
> on archaic systems (since they don't know that relatively new ELF ABI).
> I stumbled upon brandelf, tried it out and it worked like a charm for my
> tests (i.e. RHEL 5 etc). If you - or anyone else - could tell me how to
> configure Qt + PhantomJS such that it uses the old SysV ABI we could of
> course try this out and see whether it helps with the problem above.

I don't know how to do that myself but I suspect there is a compile
option somewhere.

> So my advise would be to make the step which includes ld-linux, libc
> etc. as well as the brandelf step in the quasi-static build optional as
> these are only required if we want to deploy to an archaic linux. There
> they are crucial though and do (did?) work just fine for me.

I agree. I'll submit a patch that creates a --quasi-static option for
the script this making this optional.

Thanks,
Jon

--
http://jonathanleighton.com/