User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: This is a fresh copy of the firefox-beta repository. I'm trying to build firefox-beta on my Ubuntu 10.4.1 system and have encountered the following error: file_util.cc:228:35: error: ‘ftruncate’ was not declared in this scope Actual results: See above. Expected results: I was expecting a clean build.
Priority: -- → P3
Summary: file_util.cc:228:35: error: ‘ftruncate’ was not declared in this scop → firefox-beta repository: file_util.cc:228:35: error: ‘ftruncate’ was not declared in this scope
Version: 8 Branch → unspecified
What is your gcc version?
Can you try adding the line "#include <unistd.h>" as the 14th line in that file? (before #include <fstream>)
Aceman, I have two gcc compilers here and have tried both... Each gets the same failure. George... /usr/bin/gcc --version gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. goffe@goffeg bash-4.1 /tools/mozilla/firefox };-) gcc --version gcc (GCC) 4.7.0 20111201 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm building with our suggested change now. THANKS! George...
Ok, comment if it builds and runs fine. I wonder where that include disappeared, it seems it was already included in the past: commit http://hg.mozilla.org/projects/electrolysis/rev/1727bfc11147 .
Aceman, I did see the include in the ifdef just before where you told me to insert that include... Maybe the ifdef is wrong? By the way, I had autoconf-4.65 on this system which caused the build processes to fail with something called "defn" missing... These files have a mixture of m4_defn, m4_define, and defn. The "defn"s cause my build to fail until I downgraded my autoconf to 2.13. Is this a bug? beta-src/build/autoconf/acwinpaths.m4 beta-src/ipc/chromium/src/third_party/libevent/aclocal.m4 beta-src/modules/freetype2/builds/unix/aclocal.m4 beta-src/nsprpub/build/autoconf/acwinpaths.m4 beta-src/toolkit/crashreporter/google-breakpad/aclocal.m4 Regards, George...
Aceman, I tried both compilers with the same resulting failure. Way past your(?) code. Now what? George... c++ -o crashreporter.o -c -I../../../dist/system_wrappers -include /usr/local/google/tools/mozilla/firefox/beta-src/config/gcc_hidden.h -DOSTYPE=\"Linux2.6.38\" -DOSARCH=Linux -I/usr/local/google/tools/mozilla/firefox/beta-src/toolkit/crashreporter/client/../google-breakpad/src -I/usr/local/google/tools/mozilla/firefox/beta-src/toolkit/crashreporter/client -I/usr/local/google/tools/mozilla/firefox/beta-src/toolkit/crashreporter/client -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/tools/mozilla/firefox/beta-src/obj-x86_64-unknown-linux-gnu/dist/include/nspr -I/tools/mozilla/firefox/beta-src/obj-x86_64-unknown-linux-gnu/dist/include/nss -fPIC -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MF .deps/crashreporter.pp /usr/local/google/tools/mozilla/firefox/beta-src/toolkit/crashreporter/client/crashreporter.cpp In file included from /usr/include/c++/4.4/memory:83, from ../../../dist/system_wrappers/memory:3, from /usr/local/google/tools/mozilla/firefox/beta-src/toolkit/crashreporter/client/crashreporter.cpp:49: /usr/include/c++/4.4/bits/shared_ptr.h: In member function ‘virtual void* std::_Sp_counted_deleter<_Ptr, _Deleter, _Alloc, _Lp>::_M_get_deleter(const std::type_info&)’: /usr/include/c++/4.4/bits/shared_ptr.h:146: error: cannot use typeid with -fno-rtti /usr/include/c++/4.4/bits/shared_ptr.h: In member function ‘virtual void* std::_Sp_counted_ptr_inplace<_Tp, _Alloc, _Lp>::_M_get_deleter(const std::type_info&)’: /usr/include/c++/4.4/bits/shared_ptr.h:204: error: cannot use typeid with -fno-rtti /usr/include/c++/4.4/bits/shared_ptr.h: In constructor ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(std::_Sp_make_shared_tag, _Alloc, _Args&& ...)’: /usr/include/c++/4.4/bits/shared_ptr.h:861: error: cannot use typeid with -fno-rtti /usr/include/c++/4.4/bits/shared_ptr.h: In function ‘_Del* std::get_deleter(const std::__shared_ptr<_Tp2, _Lp>&)’: /usr/include/c++/4.4/bits/shared_ptr.h:1005: error: cannot use typeid with -fno-rtti
Yes, only autoconf 2.13 are supported (yes, that is ancient but there are some reasons). See more here https://developer.mozilla.org/en/Developer_Guide/Mozilla_build_FAQ
Assignee: nobody → acelists
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #580642 - Flags: review?(benjamin)
(In reply to George R. Goffe from comment #7) > /usr/include/c++/4.4/bits/shared_ptr.h:1005: error: cannot use typeid with > -fno-rtti Is -fno-rtti compiler flag added by you? If yes, try to remove it. You can also add 'ac_add_options --disable-crashreporter' into mozconfig, if you do not need it. But this no longer the topic of this bug. Try to discuss this on irc.mozilla.org with somebody.
Version: unspecified → Trunk
Please could you tweak your hgrc to automatically add author info (guide here: https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F) + add a commit message when attaching patches, since it makes pushing half a dozen checkin-neededs a lot easier. Thanks :-)
Ok, I can try that. But you will still need to add the reviewers.
Adding "; r=foo" takes a lot less time than constructing the user line / coming up with a commit message, so if you could do the latter, that would be a big help :-)
Yes, I'll try to migrate to using the mq extension according to the page you linked. I'll try creating new patches with it. But I have one question. Visitors not logged into bugzilla do not see email addresses of bug commenters. But I think they can see attachment contents. The patch will contain my email. I am not yet sure if it is a problem for me. But is this solved in any way?
Once your patch lands, it will be public anyway, see: https://hg.mozilla.org/mozilla-central/log/tip As such, if you would rather keep your email address hidden (I can totally empathise, I have an aversion to spam myself), then I recommend setting up a bugzilla/mozilla only account and forwarding/fetching mail to your current email address.
OK, thanks. I already have the separate address for bugzilla, I just wanted to protect it too, if possible. Is it enough to put the bug number and summary as the user commit line? Do other people put something better there?
The commit message is normally in the format: Bug 123456 - What was changed; r=foo ie: Making sure to explain what changed and not just what the problem was. (Bugzilla bug summaries are obviously often more about the latter).
OK, can you see if my patch in bug 652555 meets these criteria?
Patch commit message in bug 652555 looks fine to me :-)
Thanks. So what about the patch here? Will you merge it, or do you wait for me to update it?
Component: General → IPC
Product: Firefox → Core
QA Contact: general → ipc
Target Milestone: --- → mozilla12
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.