| View previous topic :: View next topic |
| Author |
Message |
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
 Posted: Sun May 31, 2009 11:53 pm Post subject: |
 |
|
| rmh3093 wrote: |
yeah, they are all built then linked in statically
EDIT:
| Quote: | # To do a shared build on linux we need to be able to choose between type
# static_library and shared_library. We default to doing a static build
# but you can override this with "gyp -Dlibrary=shared_library" or you
# can add the following line (without the #) to ~/.gyp/include.gypi
# {'variables': {'library': 'shared_library'}}
# to compile as shared by default
'library%': 'static_library',
|
|
Interesting, but I surely wouldn't go for shared libraries with chromium  (It would be like providing access to your library for a group of blind people...) My point was that the source:binary size ratio seems absurd in case of chromium. |
|
| Back to top |
|
 |
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
| Posted: Mon Jun 01, 2009 12:48 am Post subject: |
|
|
| rmh3093 wrote: | | new ebuild, got cflags working properly now |
Good to see... But I have comments - as usual 
Firstly, this
| Code: | cflags=
for flag in $CFLAGS; do
cflags=$cflags\'$flag\',
done;
filter-ldflags -Wl,--as-needed
ldflags=
for flag in $LDFLAGS; do
ldflags=$ldflags\'$flag\',
done; |
can be done far easier the way I did in my modified ebuild:
| Code: | cflags="'${CFLAGS// /\',\'}'"
ldflags="'${LDFLAGS// /\',\'}'" |
This also makes it unnecessary to declare new variables and can be used directly as
| Code: | echo " 'cflags': [ '${CFLAGS// /\',\'}' ]," >> ~/.gyp/include.gypi
echo " 'ldflags': [ '${LDFLAGS// /\',\'}' ]," >> ~/.gyp/include.gypi
|
Secondly, I'd rather not make a private config file as part of src_prepare() in this way... But I can't much argue why
What comes to my mind, are thoughts like "What if you're destroying a useful private settings file?", "On the other hand, if you need it only for building, why keep the file afterwards? But if you do, why not test for its existence firstly?" and "Why so many echo's? This could be done by a single cat..."
Sorry for all the cavils - it's in my nature I'm afraid |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 12:53 pm Post subject: |
|
|
| kernelOfTruth wrote: | while we're at it
is the CHOST somewhere declared in those files ?
I know that amd64 / x86_64 isn't supported / implemented by upstream yet but it would be a nice find if it built just fine that way and worked 
would it be that easy to change
CHOST="i686-pc-linux-gnu"
to CHOST="x86_64-pc-linux-gnu"
or would there be more things to change ?
many thanks in advance |
how many times do I need to say what is needed to get chromium to build on 64bit??? we need new emul-linux-x86-xlibs!!!!!!
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 1:00 pm Post subject: |
|
|
| .yankee wrote: | Secondly, I'd rather not make a private config file as part of src_prepare() in this way... But I can't much argue why
What comes to my mind, are thoughts like "What if you're destroying a useful private settings file?", "On the other hand, if you need it only for building, why keep the file afterwards? But if you do, why not test for its existence firstly?" and "Why so many echo's? This could be done by a single cat..."
Sorry for all the cavils - it's in my nature I'm afraid |
I'm not sure I understand what your issue is? The chromium devs implemented the include.gypi concept so that things than be overridden with out touching the main file. If this file exists in ~/.gyp/include.gypi then it will automatically be sourced by the gyp program when it builds the scons files.... i dont get what u mean destry a useful priviate settings file.... and i am not keeping it afterwardes. I set the ebuild temp dir as the new HOME dir before i create that config file, it only exists while chromium is being built, it gets deleted when the temp dir is removed after install....
... now with regards to the echo's and all the other bash-fu... I am just testing out concepts and shit with this ebuild to see what works. considering how long it takes to copy the src to a working dir and the build chrome, it takes a while to test this ebuild and I dont really care about spending even more time fixing my bash every 5 min
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 1:07 pm Post subject: |
|
|
| kernelOfTruth wrote: | while we're at it
is the CHOST somewhere declared in those files ?
I know that amd64 / x86_64 isn't supported / implemented by upstream yet but it would be a nice find if it built just fine that way and worked
would it be that easy to change
CHOST="i686-pc-linux-gnu"
to CHOST="x86_64-pc-linux-gnu"
or would there be more things to change ?
many thanks in advance |
if you install the latest emul-linux-x86-(baselibs|gtklibs|xlibs) from the gentoo overlay and then emul-linux-x86-nspr and emul-linux-x86-nss from THE overlay you can get chrome to build but it will fail when it comes to linking against pango or something because of a missing freetype function
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Mon Jun 01, 2009 2:18 pm Post subject: |
|
|
| rmh3093 wrote: | | kernelOfTruth wrote: | while we're at it
is the CHOST somewhere declared in those files ?
I know that amd64 / x86_64 isn't supported / implemented by upstream yet but it would be a nice find if it built just fine that way and worked
would it be that easy to change
CHOST="i686-pc-linux-gnu"
to CHOST="x86_64-pc-linux-gnu"
or would there be more things to change ?
many thanks in advance |
how many times do I need to say what is needed to get chromium to build on 64bit??? we need new emul-linux-x86-xlibs!!!!!! |
now you're mixing apples with oranges: what does the 64bit build have to do with the 32bit compatibility libs ?
I'll see if can find some free time and build those missing links during the next weeks but compiling it natively on 64bit would be the more easier approach hence that question whether it would be difficult or not ...
anyways - I'm thinking of setting up a 32bit chroot again after several months without need for it to bypass that problem
thanks
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 2:46 pm Post subject: |
|
|
| kernelOfTruth wrote: | | rmh3093 wrote: | | kernelOfTruth wrote: | while we're at it
is the CHOST somewhere declared in those files ?
I know that amd64 / x86_64 isn't supported / implemented by upstream yet but it would be a nice find if it built just fine that way and worked
would it be that easy to change
CHOST="i686-pc-linux-gnu"
to CHOST="x86_64-pc-linux-gnu"
or would there be more things to change ?
many thanks in advance |
how many times do I need to say what is needed to get chromium to build on 64bit??? we need new emul-linux-x86-xlibs!!!!!! |
now you're mixing apples with oranges: what does the 64bit build have to do with the 32bit compatibility libs ?
I'll see if can find some free time and build those missing links during the next weeks but compiling it natively on 64bit would be the more easier approach hence that question whether it would be difficult or not ...
anyways - I'm thinking of setting up a 32bit chroot again after several months without need for it to bypass that problem
thanks |
V8 does NOT work with 64bit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! dont waste your time.....
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 3:20 pm Post subject: |
|
|
| .yankee wrote: |
This also makes it unnecessary to declare new variables and can be used directly as
| Code: | echo " 'cflags': [ '${CFLAGS// /\',\'}' ]," >> ~/.gyp/include.gypi
echo " 'ldflags': [ '${LDFLAGS// /\',\'}' ]," >> ~/.gyp/include.gypi
|
|
this does not work fyi... the result has an extra backslash ')
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
| Posted: Mon Jun 01, 2009 8:58 pm Post subject: |
|
|
| rmh3093 wrote: |
this does not work fyi... the result has an extra backslash ') |
I see you're getting on a tone similar to mine... But there's no need to get angry!
Well, there was a typo in my post of course. It should have been
| Code: | echo " 'cflags': [ '${CFLAGS// /','}' ]," >> ~/.gyp/include.gypi
echo " 'ldflags': [ '${LDFLAGS// /','}' ]," >> ~/.gyp/include.gypi |
As for this: | rmh3093 wrote: | | i dont get what u mean destry a useful priviate settings file.... and i am not keeping it afterwardes. I set the ebuild temp dir as the new HOME dir before i create that config file, it only exists while chromium is being built, it gets deleted when the temp dir is removed after install.... |
OK then - I didn't realise that it all went to a tempdir instead of actual HOME. My bad. Let's not go killing each other for these, ok? |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 9:00 pm Post subject: |
|
|
| .yankee wrote: | | rmh3093 wrote: |
this does not work fyi... the result has an extra backslash ') |
I see you're getting on a tone similar to mine... But there's no need to get angry!
Well, there was a typo in my post of course. It should have been
| Code: | echo " 'cflags': [ '${CFLAGS// /','}' ]," >> ~/.gyp/include.gypi
echo " 'ldflags': [ '${LDFLAGS// /','}' ]," >> ~/.gyp/include.gypi |
As for this: | rmh3093 wrote: | | i dont get what u mean destry a useful priviate settings file.... and i am not keeping it afterwardes. I set the ebuild temp dir as the new HOME dir before i create that config file, it only exists while chromium is being built, it gets deleted when the temp dir is removed after install.... |
OK then - I didn't realise that it all went to a tempdir instead of actual HOME. My bad. Let's not go killing each other for these, ok? |
i realize my bash can be improved.... im just trying to get shit out there that works right now.... I will take your cleanups and improvements any day, thanks for them, keep them coming
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 01, 2009 9:01 pm Post subject: |
|
|
| kernelOfTruth wrote: | | rmh3093 wrote: |
V8 does NOT work with 64bit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! dont waste your time..... |
roger that,
thanks
well that's a shame - it would be even faster  |
actually it wont... thats why its not a priority, chromes performances comes from its thread usage, nothing about v8 should improve from 64bit
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
.yankee
Apprentice
Joined: 24 Feb 2008
Posts: 194
Location: Polska
|
| Posted: Mon Jun 01, 2009 9:09 pm Post subject: |
|
|
| rmh3093 wrote: | | im just trying to get shit out there that works right now.... |
And a great job you are doing overall! It's just me and my nature of hanging on stupid small details anywhere I can spot them - rather than praise what actually deserves that...
| rmh3093 wrote: | | I will take your cleanups and improvements any day, thanks for them, keep them coming |
...But I'm very happy we can have peace after all  |
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Fri Jun 05, 2009 10:57 am Post subject: |
|
|
google released a 64bit linux dev version of chrome. no, i did not try it out so far.
could this mean that the state of 64bit capabilities of chromium are improving too? i am not really following the events in the chromium repo, so i don't know.
the last time i tried chromium, it didn't work, although i use the multilib overlay and should have all necessary libs in 32bit.
EDIT: i tried it.
after unpacking in directory and launching, i get | Code: | | error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory |
normal amd64 machine. no multilib overlay. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Fri Jun 05, 2009 11:30 am Post subject: |
|
|
after providing libgconf and libORBit, i get | Code: | $ ./google-chrome
/usr/share/themes/Clearlooks/gtk-2.0/gtkrc:75: error: unexpected identifier `reliefstyle', expected character `}'
[4407:4407:4728505736:ERROR:/b/slave/chrome-official-linux/build/src/chrome/browser/google_update_settings_linux.cc(60)] Not implemented reached in static bool GoogleUpdateSettings::GetLanguage(std::wstring*)
Segmentation fault
$ |
|
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Fri Jun 05, 2009 1:38 pm Post subject: |
|
|
| alex.blackbit wrote: | google released a 64bit linux dev version of chrome. no, i did not try it out so far.
could this mean that the state of 64bit capabilities of chromium are improving too? i am not really following the events in the chromium repo, so i don't know.
the last time i tried chromium, it didn't work, although i use the multilib overlay and should have all necessary libs in 32bit.
EDIT: i tried it.
after unpacking in directory and launching, i get | Code: | | error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory |
normal amd64 machine. no multilib overlay. |
please keep binary talk in another thread please! I dont wan't your missing libs getting confused with the source build chrome!!!
EDIT: and its not 64bit... its still a 32bit build, there is not 64bit support on any platform yet
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Fri Jun 05, 2009 1:39 pm Post subject: |
|
|
| kernelOfTruth wrote: | so it seems to be the same like before - no news
why is that thing depending on gconf ?
they should provide one's own settings "registry" & tool to change those settings ...  |
why would they reinvent the wheel, using gconf is the right thing to do.
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
alex.blackbit
Advocate
Joined: 26 Jul 2005
Posts: 2397
|
| Posted: Fri Jun 05, 2009 2:46 pm Post subject: |
|
|
you are right. it's still 32bit. the google guys are liars.
and i'll be silent now. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Mon Jun 08, 2009 12:19 am Post subject: |
|
|
i just wanted to let you 64bit people know that I will have chrome building on gentoo by the end of this week
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
bob_111
Apprentice
Joined: 12 Oct 2004
Posts: 155
|
| Posted: Tue Jun 16, 2009 1:20 pm Post subject: |
|
|
Hey guys, great job so far but i've hit a bit of a snag. Chrome won't compile because its treating warnings as errors. Is it possible to disable all warning together using CFlags ?
| Code: | cc1plus: warnings being treated as errors
browser/metrics/metrics_log.cc: In static member function 'static std::string MetricsLog::CreateHash(const std::string&)':
browser/metrics/metrics_log.cc:122: error: dereferencing type-punned pointer will break strict-aliasing rules
scons: *** [/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/src/src/sconsbuild/Release/obj/chrome/browser/metrics/metrics_log.o] Error 1
scons: building terminated because of errors. |
Cheers. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Tue Jun 16, 2009 5:31 pm Post subject: |
|
|
can't get it to work either:
| Quote: | These are the packages that would be merged, in order:
Calculating dependencies / *
* ERROR: www-client/chromium-9999 failed.
* Call stack:
* ebuild.sh, line 1879: Called _source_ebuild
* ebuild.sh, line 1818: Called source '/usr/gentoo/overlays/THE/www-client/chromium/chromium-9999.ebuild'
* chromium-9999.ebuild, line 10: Called inherit 'gclient' 'eutils' 'flag-o-matic'
* ebuild.sh, line 1218: Called die
* The specific snippet of code:
* [ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
* The die message:
* gclient.eclass could not be found by inherit()
*
* If you need support, post the topmost build error, and the call stack if relevant.
* This ebuild is from an overlay: '/usr/gentoo/overlays/THE/'
*
... done!
!!! All ebuilds that could satisfy "www-client/chromium" have been masked.
!!! One of the following masked packages is required to complete your request:
- www-client/chromium-9999 (masked by: corruption) |
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Tue Jun 16, 2009 7:30 pm Post subject: |
|
|
| kernelOfTruth wrote: | can't get it to work either:
| Quote: | These are the packages that would be merged, in order:
Calculating dependencies / *
* ERROR: www-client/chromium-9999 failed.
* Call stack:
* ebuild.sh, line 1879: Called _source_ebuild
* ebuild.sh, line 1818: Called source '/usr/gentoo/overlays/THE/www-client/chromium/chromium-9999.ebuild'
* chromium-9999.ebuild, line 10: Called inherit 'gclient' 'eutils' 'flag-o-matic'
* ebuild.sh, line 1218: Called die
* The specific snippet of code:
* [ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
* The die message:
* gclient.eclass could not be found by inherit()
*
* If you need support, post the topmost build error, and the call stack if relevant.
* This ebuild is from an overlay: '/usr/gentoo/overlays/THE/'
*
... done!
!!! All ebuilds that could satisfy "www-client/chromium" have been masked.
!!! One of the following masked packages is required to complete your request:
- www-client/chromium-9999 (masked by: corruption) |
|
Odd...
| Code: | Redman zen # ls /var/paludis/repositories/THE/eclass/
gclient.eclass
|
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
|
Unsupported Software
