[solved] request for gstreamer1.0 support Topic is solved
Moderator: trava90
Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
-
- Contributing developer
- Posts: 1742
- Joined: 2013-05-20, 18:19
- Location: Somewhere in Sector 001
Re: request for gstreamer1.0 support
Awesome! Thanks for the verification!
-
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: [solved] request for gstreamer1.0 support
Me too, as far as solved is concerned. The QEMU VM successfully built the 26.2_Atom_RelBranch for my ancient netbook. I got to see the chirping bird hit with a nut on the Quirksmode site... in triplicate. Youtube HTML5 also works. But my underpowered ancient Atom netbook struggles to keep up with HTML5 video, even with the CPU set to max (1.33 ghz). HTML5 video is a cpu hog compared to Flash.
The basic problem I had before seems to be that some "*.sh" files in the source code do not have the "executable" attribute set. They did not execute during the build, and the stuff they were supposed to set up was missing. I vaguely remember some instructions in the past to chmod +x all the source files There were 56 such files in the 26.2_Atom_RelBranch. To get a listing, in bash execute the following long 1-liner...
Even better, to set the attribute, I executed...
This changes only the files it has to. Maybe one of the devs could run a sweep through the repository to set the execute attributes on the *.sh files. I don't know how I managed to get the x86_64 builds to work in the past. But with permissions corrected, I even have the internal jemalloc working now. Here is my "package set" in Gentoo that is needed for the build. Note that "<", "=", and ">" have the standard mathematical meanings. It doesn't cover every dependancy. In my mozconfig.txt I had --disable-gio --disable-gconf --disable-dbus and --disable-pulseaudio, which means that I could get by without some libraries that others may need...
Note that the forum page http://linux.palemoon.org/ says I need libstdc++ 4.3. That should read 3.3.
Finally, here are my build and mozconfig.txt files attached. A few notes...
The basic problem I had before seems to be that some "*.sh" files in the source code do not have the "executable" attribute set. They did not execute during the build, and the stuff they were supposed to set up was missing. I vaguely remember some instructions in the past to chmod +x all the source files There were 56 such files in the 26.2_Atom_RelBranch. To get a listing, in bash execute the following long 1-liner...
Code: Select all
for filename in `find pmsrc ! -executable | grep "\.sh$"` ; do echo ${filename} ; done
Code: Select all
for filename in `find pmsrc ! -executable | grep "\.sh$"` ; do chmod u+x ${filename} ; done
Code: Select all
>=dev-libs/glib-2.24
media-libs/mesa
=sys-devel/autoconf-2.13
sys-libs/libstdc++-v3
<x11-libs/gtk+-3.0
x11-libs/libXt
media-libs/gstreamer
media-libs/gst-plugins-base
media-libs/gst-plugins-good
media-plugins/gst-plugins-libav
Finally, here are my build and mozconfig.txt files attached. A few notes...
- I had to rename the build script to build.txt to get the forum code to accept it
- The build file sets up CFLAGS and CCFLAGS. The mozconfig simply picks them up with --enable-optimize
- "-march=bonnell" is optimized and valid for my netbook, not necessarily yours.
- The build file also sets up the object dir as an enviromental variable, which mozconfig picks up. I had an embarressing moment when I copied the version "fu" directory to "bar". I forgot to modify mozconfig in "bar", and it was still sending code to pmbuild/ in "fu"... talk about "oops" programming. The build script now guarantees that if I start in the directory with the build script, the built code goes to pmbuild/ in that directory
You do not have the required permissions to view the files attached to this post.
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
-
- Contributing developer
- Posts: 1742
- Joined: 2013-05-20, 18:19
- Location: Somewhere in Sector 001
Re: [solved] request for gstreamer1.0 support
https://github.com/MoonchildProductions ... n/pull/421Walter Dnes wrote:Maybe one of the devs could run a sweep through the repository to set the execute attributes on the *.sh files.
-
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: [solved] request for gstreamer1.0 support
Thanks very much. One less step for me to do when building.trava90 wrote:https://github.com/MoonchildProductions ... n/pull/421Walter Dnes wrote:Maybe one of the devs could run a sweep through the repository to set the execute attributes on the *.sh files.
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
-
- Contributing developer
- Posts: 1742
- Joined: 2013-05-20, 18:19
- Location: Somewhere in Sector 001