[chromium-dev] WebContents is dead, long live TabContents!
I just moved the remaining methods from WebContents to TabContents. I kept the methods and data members the same, just merged the classes, so it should be easy to find what you're looking for (or to resolve conflicts if you have local changes to web_contents.cc). Hopefully this will make the complexity in this area much more manageable. We still have a shell class called WebContents (derived from TabContents) and references to it, which are temporary so I don't have to immediately change all references to it. It will hopefully soon go away. FAQ: Why did we do this? Chromium 1 used a variety of specialized tab contents types which we wrote native interfaces for. This included the history and downloads page. TabContents was the base class providing shared functionality and an external API, and there were a variety of subclasses for the different tab types. WebContents was the TabContents specialization for web pages. There were several problems with this. The original idea is that our native UI would be more awesome than a web page could ever be. But it turned out to be teh suck because a variety of things didn't work (find in page, printing, selection) and because we didn't end up doing anything fancy in there anyway. With native UI, we would have to write it again for every platform, which nobody was excited about doing. There were also very difficult bugs associated with switching tab contents types. For example, in Chromium 1, if you go to the history page, navigate to a regular web page, go back, then navigate to a different regular web page, you would see a flash of the first web page during the second transition. This was the tab contents types being switched between a HistoryContents and a previously-used WebContents. So now we only display web pages inside tabs. This makes the switching problem go away. Glen rewrote history and downloads we be special web pages with additional permissions, and I did a whole heckuva lof of refactoring to delete all the old TabContents switching. We still swap RenderViewHosts inside the TabContents when we need to switch processes. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebContents is dead, long live TabContents!
Hooray! Ding dong the witch is dead! Congrats for finally reaching the end of this. -Ben On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson bre...@chromium.org wrote: I just moved the remaining methods from WebContents to TabContents. I kept the methods and data members the same, just merged the classes, so it should be easy to find what you're looking for (or to resolve conflicts if you have local changes to web_contents.cc). Hopefully this will make the complexity in this area much more manageable. We still have a shell class called WebContents (derived from TabContents) and references to it, which are temporary so I don't have to immediately change all references to it. It will hopefully soon go away. FAQ: Why did we do this? Chromium 1 used a variety of specialized tab contents types which we wrote native interfaces for. This included the history and downloads page. TabContents was the base class providing shared functionality and an external API, and there were a variety of subclasses for the different tab types. WebContents was the TabContents specialization for web pages. There were several problems with this. The original idea is that our native UI would be more awesome than a web page could ever be. But it turned out to be teh suck because a variety of things didn't work (find in page, printing, selection) and because we didn't end up doing anything fancy in there anyway. With native UI, we would have to write it again for every platform, which nobody was excited about doing. There were also very difficult bugs associated with switching tab contents types. For example, in Chromium 1, if you go to the history page, navigate to a regular web page, go back, then navigate to a different regular web page, you would see a flash of the first web page during the second transition. This was the tab contents types being switched between a HistoryContents and a previously-used WebContents. So now we only display web pages inside tabs. This makes the switching problem go away. Glen rewrote history and downloads we be special web pages with additional permissions, and I did a whole heckuva lof of refactoring to delete all the old TabContents switching. We still swap RenderViewHosts inside the TabContents when we need to switch processes. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
hi there,
thanks for working on getting the shared lib of libraries! I was
pointed to this work by Evan Martin as well and he pointed me to this
(http://codereview.chromium.org/88058). However I am having some
difficulty getting it to build and it errors out while building
libxml.
==
...
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/xmlcatalog
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose'
collect2: ld returned 1 exit status
scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/xmlcatalog] Error 1
scons: building terminated because of errors.
===
Here are the steps that I tried:
a) first I tried to download each patch from patch set 4 and patched
the corresponding files manually. Removed sconsbuild directory and
rebuilt. it had the same errors.
I read your instructions in Description section but I did not
understand where exactly I need to make changes to exclude and include
those files. I looked at all_main.scons and common.gypi. it would be
really helpful if you can elaborate on those instructions.
b) I did a get latest with revision 14166 by using following command:
CHROMIUM_ROOT$ gclient sync --revision s...@14166
(chromium root = directory that has src directory in it).
Let me know what steps I might be missing. Another point I want to add
is that I have followed the instructions in 'Staying Green more of the
time' section of getting code on chrome wiki for linux developers, if
that matters any.
Thanks,
On Apr 21, 8:21 pm, Steven Knight s...@chromium.org wrote:
The gyp build can generate shared libraries on Linux (as of r14166).
You can set up to use shared libraries by setting the GYP_DEFINES variable
as follows:
$ export GYP_DEFINES='library=shared_library'
$ gclient runhooks --force
If it's not set when you run gclient, it will silently generate .scons
files that build with static libraries, of course, so put it in your
.profile or .bashrc or whatever suits.
As an alternative to an environment variable, put the following text in the
~/.gyp/include.gypi startup file in your home directory:
{
'variables': {
'library': 'shared_library',
},
}
Note that you *can* build shared and static in the same tree by switching
back and forth (the shared object files will have a different suffix), but
the .a and .so files get built in the same sconsbuild/{Debug,Release}/lib
directory. This can throw you for a loop if the linker decides to use an
old .so in preference to the new .a you just built, so it's safer to clean
things out (at least the lib/ subdirectory, anyway).
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
Looks like it's missing -ldl, but I haven't looked closely.
On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote:
hi there,
thanks for working on getting the shared lib of libraries! I was
pointed to this work by Evan Martin as well and he pointed me to this
(http://codereview.chromium.org/88058). However I am having some
difficulty getting it to build and it errors out while building
libxml.
==
...
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/xmlcatalog
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose'
collect2: ld returned 1 exit status
scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/xmlcatalog] Error 1
scons: building terminated because of errors.
===
Here are the steps that I tried:
a) first I tried to download each patch from patch set 4 and patched
the corresponding files manually. Removed sconsbuild directory and
rebuilt. it had the same errors.
I read your instructions in Description section but I did not
understand where exactly I need to make changes to exclude and include
those files. I looked at all_main.scons and common.gypi. it would be
really helpful if you can elaborate on those instructions.
b) I did a get latest with revision 14166 by using following command:
CHROMIUM_ROOT$ gclient sync --revision s...@14166
(chromium root = directory that has src directory in it).
Let me know what steps I might be missing. Another point I want to add
is that I have followed the instructions in 'Staying Green more of the
time' section of getting code on chrome wiki for linux developers, if
that matters any.
Thanks,
On Apr 21, 8:21 pm, Steven Knight s...@chromium.org wrote:
The gyp build can generate shared libraries on Linux (as of r14166).
You can set up to use shared libraries by setting the GYP_DEFINES variable
as follows:
$ export GYP_DEFINES='library=shared_library'
$ gclient runhooks --force
If it's not set when you run gclient, it will silently generate .scons
files that build with static libraries, of course, so put it in your
.profile or .bashrc or whatever suits.
As an alternative to an environment variable, put the following text in the
~/.gyp/include.gypi startup file in your home directory:
{
'variables': {
'library': 'shared_library',
},
}
Note that you *can* build shared and static in the same tree by switching
back and forth (the shared object files will have a different suffix), but
the .a and .so files get built in the same sconsbuild/{Debug,Release}/lib
directory. This can throw you for a loop if the linker decides to use an
old .so in preference to the new .a you just built, so it's safer to clean
things out (at least the lib/ subdirectory, anyway).
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am having some difficulty getting it to build and it errors out while building libxml. == ... Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/xmlcatalog Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 scons: building terminated because of errors. === Here are the steps that I tried: a) first I tried to download each patch from patch set 4 and patched the
[chromium-dev] Re: gyp shared library builds on Linux
could you please tell me what files I have to modify to add -ldl ? When I do command line with -ldl option it goes without error but the automated build using hammer is obviously regenerating some files that still miss -ldl option. Thanks, On Apr 24, 8:26 am, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am having some difficulty getting it to build and it errors out while building libxml. == ... Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/xmlcatalog Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to
[chromium-dev] Re: gyp shared library builds on Linux
Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am having some difficulty getting it to build and it errors out while building libxml. == ... Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/xmlcatalog Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
[chromium-dev] Re: gyp shared library builds on Linux
Hmmm ... actually it seems as if -ldl is present in third_party/libxml/libxml.gyp ... so take a look if it's there for you and run gclient sync if it isn't. Try running gclient runhooks --force if none of the other things work. Perhaps your scons files have not been updated properly. --Craig On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am having some difficulty getting it to build and it errors out while building libxml. == ... Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/xmlcatalog Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os
[chromium-dev] Re: Progress indicator for mini_installer on Windows
On Fri, Apr 24, 2009 at 2:40 AM, Mark Larson (Google) m...@chromium.orgwrote: On Thu, Apr 23, 2009 at 22:40, Robert Dailey rcdai...@gmail.com wrote: Filed a feature request: http://code.google.com/p/chromium/issues/detail?id=10955 My response to the bug (closed WontFix): mini_installer can never have a UI. It needs to remain silent for automatic updates. In some cases it may get launched from a system service that does not have an interactive desktop, so it cannot have UI. Perhaps a third-party Chromium updater is what you're looking for: http://www.google.com/search?q=chromium+nightly+installer Or just wait for the hourglass cursor to go away after you double-click mini_installer.exe. I don't want to invest in building, testing, and archiving a separate installer for the continuous builds. They're not production-ready, and I will make no commitments to keeping them so. Sounds understandable. Thanks for taking the time to review my request. I really appreciate it. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
ok , so building chrome terminated with this error. scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/lib/libglue.so] Source file: /home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ WebKit/WebCore/Configurations/Version.xcconfig is static and is not compatible with shared target: /home/dev/ProgramFiles/v8/home/chrome- svn/tarball/chromium/src/sconsbuild/Debug/lib/libglue.so scons: building terminated because of errors. I know you have instruction in your Description to remove the Version.xcconfig file so I removed it from that directory. (is it remove from directory or remove from config file? please let me know which file if it is config file). However removing from directory gave this error: scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/webkit/glue/intermediate/webkit_version.h] Source `/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/WebKit/WebCore/Configurations/ Version.xcconfig' not found, needed by target `/home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/webkit/ glue/intermediate/webkit_version.h'. scons: building terminated because of errors. Thanks, Nidhi On Apr 24, 9:55 am, nshah nidhi.kejri...@gmail.com wrote: actully I saw it there but then I was not sure if it needs another condition block for shared_library but before asking you again I wanted to try to build chrome (hammer app) and see if that works as you suggested. Thanks! Nidhi On Apr 24, 9:16 am, Craig Schlenter craig.schlen...@gmail.com wrote: Hmmm ... actually it seems as if -ldl is present in third_party/libxml/libxml.gyp ... so take a look if it's there for you and run gclient sync if it isn't. Try running gclient runhooks --force if none of the other things work. Perhaps your scons files have not been updated properly. --Craig On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
[chromium-dev] Re: gyp shared library builds on Linux
Actually all the targets work ... Steven fixed them all and I just hadn't realised that so the hammer app thing and my earlier rambling is ignorable. I see from your other mail that you are using the tarball though so I'd recommend trying to sync up with the current svn trunk. It should all work there. Also you must do the gclient runhooks --force thing ... I might be on #chromium later ... Drop by if you're still having trouble. That's easier than trying to solve it here... --Craig On 24 Apr 2009, at 15:55, nshah nidhi.kejri...@gmail.com wrote: actully I saw it there but then I was not sure if it needs another condition block for shared_library but before asking you again I wanted to try to build chrome (hammer app) and see if that works as you suggested. Thanks! Nidhi On Apr 24, 9:16 am, Craig Schlenter craig.schlen...@gmail.com wrote: Hmmm ... actually it seems as if -ldl is present in third_party/libxml/libxml.gyp ... so take a look if it's there for you and run gclient sync if it isn't. Try running gclient runhooks -- force if none of the other things work. Perhaps your scons files have not been updated properly. --Craig On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/ home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/ home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/ tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 - Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz- tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD - DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am
[chromium-dev] Re: gyp shared library builds on Linux
Just to follow up explicitly to what Craig said, you should do something like the following, and make sure there are no errors: # Clobber rm -rf sconsbuild # Make sure everything is up to date gclient sync --force # Make sure the scons files were regenerated from the gyp files gclient runhooks --force On Fri, Apr 24, 2009 at 4:50 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Actually all the targets work ... Steven fixed them all and I just hadn't realised that so the hammer app thing and my earlier rambling is ignorable. I see from your other mail that you are using the tarball though so I'd recommend trying to sync up with the current svn trunk. It should all work there. Also you must do the gclient runhooks --force thing ... I might be on #chromium later ... Drop by if you're still having trouble. That's easier than trying to solve it here... --Craig On 24 Apr 2009, at 15:55, nshah nidhi.kejri...@gmail.com wrote: actully I saw it there but then I was not sure if it needs another condition block for shared_library but before asking you again I wanted to try to build chrome (hammer app) and see if that works as you suggested. Thanks! Nidhi On Apr 24, 9:16 am, Craig Schlenter craig.schlen...@gmail.com wrote: Hmmm ... actually it seems as if -ldl is present in third_party/libxml/libxml.gyp ... so take a look if it's there for you and run gclient sync if it isn't. Try running gclient runhooks -- force if none of the other things work. Perhaps your scons files have not been updated properly. --Craig On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/ home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/ home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/ tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 - Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz- tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD - DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee
[chromium-dev] Re: WebContents is dead, long live TabContents!
woot! On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson bre...@chromium.org wrote: I just moved the remaining methods from WebContents to TabContents. I kept the methods and data members the same, just merged the classes, so it should be easy to find what you're looking for (or to resolve conflicts if you have local changes to web_contents.cc). Hopefully this will make the complexity in this area much more manageable. We still have a shell class called WebContents (derived from TabContents) and references to it, which are temporary so I don't have to immediately change all references to it. It will hopefully soon go away. FAQ: Why did we do this? Chromium 1 used a variety of specialized tab contents types which we wrote native interfaces for. This included the history and downloads page. TabContents was the base class providing shared functionality and an external API, and there were a variety of subclasses for the different tab types. WebContents was the TabContents specialization for web pages. There were several problems with this. The original idea is that our native UI would be more awesome than a web page could ever be. But it turned out to be teh suck because a variety of things didn't work (find in page, printing, selection) and because we didn't end up doing anything fancy in there anyway. With native UI, we would have to write it again for every platform, which nobody was excited about doing. There were also very difficult bugs associated with switching tab contents types. For example, in Chromium 1, if you go to the history page, navigate to a regular web page, go back, then navigate to a different regular web page, you would see a flash of the first web page during the second transition. This was the tab contents types being switched between a HistoryContents and a previously-used WebContents. So now we only display web pages inside tabs. This makes the switching problem go away. Glen rewrote history and downloads we be special web pages with additional permissions, and I did a whole heckuva lof of refactoring to delete all the old TabContents switching. We still swap RenderViewHosts inside the TabContents when we need to switch processes. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebContents is dead, long live TabContents!
Congrts, Brett! -- Erg. On Fri, Apr 24, 2009 at 9:15 AM, Erik Kay erik...@chromium.org wrote: woot! On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson bre...@chromium.org wrote: I just moved the remaining methods from WebContents to TabContents. I kept the methods and data members the same, just merged the classes, so it should be easy to find what you're looking for (or to resolve conflicts if you have local changes to web_contents.cc). Hopefully this will make the complexity in this area much more manageable. We still have a shell class called WebContents (derived from TabContents) and references to it, which are temporary so I don't have to immediately change all references to it. It will hopefully soon go away. FAQ: Why did we do this? Chromium 1 used a variety of specialized tab contents types which we wrote native interfaces for. This included the history and downloads page. TabContents was the base class providing shared functionality and an external API, and there were a variety of subclasses for the different tab types. WebContents was the TabContents specialization for web pages. There were several problems with this. The original idea is that our native UI would be more awesome than a web page could ever be. But it turned out to be teh suck because a variety of things didn't work (find in page, printing, selection) and because we didn't end up doing anything fancy in there anyway. With native UI, we would have to write it again for every platform, which nobody was excited about doing. There were also very difficult bugs associated with switching tab contents types. For example, in Chromium 1, if you go to the history page, navigate to a regular web page, go back, then navigate to a different regular web page, you would see a flash of the first web page during the second transition. This was the tab contents types being switched between a HistoryContents and a previously-used WebContents. So now we only display web pages inside tabs. This makes the switching problem go away. Glen rewrote history and downloads we be special web pages with additional permissions, and I did a whole heckuva lof of refactoring to delete all the old TabContents switching. We still swap RenderViewHosts inside the TabContents when we need to switch processes. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Crossplatform ProcessSingleton and ChromeBrowserProcessId()
There are now different platform-dependent ways to ensure that only one instance of Chrome is running, and to get its pid. I think that there is a way of accomplishing both goals in a cross-platform way, reusing existing IPC system. I'll try to explain how IMO things are now, and why this might be not the best way: Now: 1. Windows Hidden top-level window is used for getting Chrome pid and IPC on startup. This is actually reinventing IPC over window messages with custom protocol. 2. Linux UNIX socket is used for IPC on startup, and fuser program is launched on it to get the pid - IMHO not the best way to do it. 3. Mac There is now ProcessSingleton on Mac, as it's not needed. Some hack on ps output is used to get the pid. So there are 3 different implementations, and not very optimal ones. Same effect could be acieved by this method: Don't try to get pid dynamically, but create on startup in datadir file 'ChromePid' or something like that with pid. Also, create an IPC channel with channel_id equal to pid with forced FIFO mode on POSIX. Current POSIX implementation should be modified to allow this and to store socket in datadir, not in /var/tmp. Then ProcessSingleton check would be simple and crossplatform: find pid file, read pid, connect to channel, send some message and wait for response. This eliminates all differences between platforms in process_singleton_* and chrome_process_util_*. What do you think? Nikita Ofitserov --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
Currently there are different implementations of ProcessSingleton and ChromeBrowserProcessId() on Windows, Linux and Mac. Most of them are quite hacky, so there should be a better way. I think current IPC system with slight modifications can replace them all. Now: 1. Windows Hidden top-level window is used for getting Chrome pid and IPC on startup. 2. Linux UNIX socket is used for IPC on startup, and fuser program is launched on it to get the pid - IMHO not the best way to do it. 3. Mac There is no ProcessSingleton on Mac, as it's not needed. Chrome pid comes out of some hack with ps output. I suggest: Don't try to get pid dynamically, but create on startup in datadir file 'ChromePid' or something like that with pid. Also, create an IPC channel with channel_id equal to pid with forced FIFO mode on POSIX. Current POSIX implementation should be modified to allow this and to store socket in datadir, not in /var/tmp. Then ProcessSingleton check would be simple and crossplatform: find pid file, read pid, connect to channel, send some message and wait for response. This eliminates all differences between platforms in process_singleton_* and chrome_process_util_*. What do you think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov himi...@gmail.com wrote: I suggest: Don't try to get pid dynamically, but create on startup in datadir file 'ChromePid' or something like that with pid. Creating files during startup would slow startup too much. Chrome crashing would leave a stale PID file lying around, confusing future launches. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome Views w/o BrowserProcessImpl?
Is it possible to use views without an instance of BrowserProcess or are they very tightly coupled? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Views w/o BrowserProcessImpl?
At present views has some dependencies on some other parts of the browser infrastructure but I plan to sever a lot of this in the coming month or two. -Ben On Fri, Apr 24, 2009 at 7:36 PM, Book'em Dano daniel.c...@gmail.com wrote: Is it possible to use views without an instance of BrowserProcess or are they very tightly coupled? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Views w/o BrowserProcessImpl?
Okay, thanks Ben On Apr 24, 7:38 pm, Ben Goodger (Google) b...@chromium.org wrote: At present views has some dependencies on some other parts of the browser infrastructure but I plan to sever a lot of this in the coming month or two. -Ben On Fri, Apr 24, 2009 at 7:36 PM, Book'em Dano daniel.c...@gmail.com wrote: Is it possible to use views without an instance of BrowserProcess or are they very tightly coupled? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
I have noticed some of these creep in in the past couple of weeks. DO NOT DO IT. Or I will hunt you down. I am trying to extract views from chrome/ and every time you do this, it adds spaghetti to the plate and makes my life harder. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
Is it possible to enforce these rules with code rather than capital letters? I don't think I've made this particular error, but it's something I could see myself doing. From their names, chrome/common seems like a reasonable thing to include from chrome/views. Just a thought. Don't we have something already to enforce dependency rules like this? - a On Fri, Apr 24, 2009 at 9:59 PM, Ben Goodger (Google) b...@chromium.org wrote: I have noticed some of these creep in in the past couple of weeks. DO NOT DO IT. Or I will hunt you down. I am trying to extract views from chrome/ and every time you do this, it adds spaghetti to the plate and makes my life harder. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
On Fri, Apr 24, 2009 at 10:10 PM, Aaron Boodman a...@chromium.org wrote: Is it possible to enforce these rules with code rather than capital letters? I don't think I've made this particular error, but it's something I could see myself doing. From their names, chrome/common seems like a reasonable thing to include from chrome/views. Just a thought. Don't we have something already to enforce dependency rules like this? The problem is that there are already some dependencies, so we can't enforce them. The dependencies are checked on a per-directory basis. I would like to prevent people from including browser from renderer_host and tab_contents but can't for the same reason. We could have some complicated exception list in the checkdeps tool, but that's much harder than shouting on the mailing list. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
Sadly, chrome/common sounds generic enough that it's become a place to stash files. I'm not blameless - for some reason I put Animation there, when it clearly belongs in views/. Common's purpose is for files shared between two or more subdirs of chrome where those subdirs are peers on the dependency tree. -Ben On Fri, Apr 24, 2009 at 10:10 PM, Aaron Boodman a...@chromium.org wrote: Is it possible to enforce these rules with code rather than capital letters? I don't think I've made this particular error, but it's something I could see myself doing. From their names, chrome/common seems like a reasonable thing to include from chrome/views. Just a thought. Don't we have something already to enforce dependency rules like this? - a On Fri, Apr 24, 2009 at 9:59 PM, Ben Goodger (Google) b...@chromium.org wrote: I have noticed some of these creep in in the past couple of weeks. DO NOT DO IT. Or I will hunt you down. I am trying to extract views from chrome/ and every time you do this, it adds spaghetti to the plate and makes my life harder. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
