Since old times I have this self-made building script. It's terribly wrong and inefficient, but it worked every time.
#!/bin/bash
mkdir trunk
cd trunk
echo "Uninstalling..."
sudo make uninstall
cd ..
echo "Removing trash..."
rm -rf trunk
echo "Relinking..."
sudo ldconfig
echo "Checking out..."
if [ $# -eq 0 ]
then
svn co svn://svn.code.sf.net/p/codeblocks/code/trunk
else
svn co svn://svn.code.sf.net/p/codeblocks/code/trunk -r $1
fi
cd trunk
echo "Bootstraping..."
./bootstrap
echo "Configuring..."
./configure --with-contrib-plugins=all
echo "Making..."
rv=1
while [ $rv -ne 0 ];
do
make
rv=$?
echo $rv
sleep 5
done
echo "Installing..."
sudo make install
echo "Relinking..."
sudo ldconfig (New repo link already inserted)
Sadly, I'm unable to finish the building process with the new repo.
.libs/asstreamiterator.o: In function `ASStreamIterator::readLine()':
asstreamiterator.cpp:(.text+0x193): undefined reference to `wxStringBase::npos'
...
.libs/astyleconfigdlg.o: In function `AstyleConfigDlg::OnPreview(wxCommandEvent&)':
astyleconfigdlg.cpp:(.text+0x7d): undefined reference to `wxXmlResource::GetXRCID(wchar_t const*, int)'
...
.libs/dlgformattersettings.o: In function `DlgFormatterSettings::ApplyTo(astyle::ASFormatter&)':
dlgformattersettings.cpp:(.text+0x6d): undefined reference to `wxXmlResource::GetXRCID(wchar_t const*, int)'
...
.libs/formattersettings.o: In function `FormatterSettings::ApplyTo(astyle::ASFormatter&)':
formattersettings.cpp:(.text+0x60): undefined reference to `wxStringBase::npos' (Many similar lines left out)
Any major changes, that I've missed?
I double-checked on old backups of my system, taken on the 8900 build day. Still no success.
I get the same errors with the previous repo. I have not been able to compile a new version since rev 8900.
I had the same issue yesterday with the latest revision and had to roll back to svn8900 to make it work. Now i can't rellocate my repository as it cannot find the same UUID and I had to remove it and re-checkout to test it.
Update: The issue continues even with the newly moved svn revision code. The error seems to be Astyle plugin got compiled with different compiler as the signatures do not seem to match with those of wxGTK-2.8.12 and complains. I hope I'm wrong!
Looks like 8903 issue:
* linux: add --no-undefined linker option to autotools and project-files
I'm running several rev-builds now to locate the exact spot. 8901 is fine, 8905 is not...
Update: 8903 does fail. 8902 works.
Last command before it goes boom:
Quote/bin/bash ../../../libtool --tag=CXX --mode=link g++ -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -module -version-info 0:1:0 -shared -no-undefined -avoid-version -Wl,--no-undefined -o libastyle.la -rpath /usr/local/lib/codeblocks/plugins asstreamiterator.lo astyleconfigdlg.lo astyleplugin.lo dlgformattersettings.lo formattersettings.lo ASBeautifier.lo ASEnhancer.lo ASFormatter.lo ASResource.lo ../../sdk/libcodeblocks.la -lpthread -ldl
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginS.o .libs/asstreamiterator.o .libs/astyleconfigdlg.o .libs/astyleplugin.o .libs/dlgformattersettings.o .libs/formattersettings.o .libs/ASBeautifier.o .libs/ASEnhancer.o .libs/ASFormatter.o .libs/ASResource.o -Wl,-rpath -Wl,/home/commaster/.temp/codeblocks/trunk/src/sdk/.libs ../../sdk/.libs/libcodeblocks.so -lpthread -ldl -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.7/crtfastmath.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o -O2 -Wl,--no-undefined -pthread -Wl,-soname -Wl,libastyle.so -o .libs/libastyle.so
What OS/distros are you using? It compiles fine on my gentoo machine.
Also make sure you're using wxGTK-2.8.12!
Good old Ubuntu 12.10 with wx 2.8.12 all the time, as it succeeded in previous compilations.
It compiles 8901 just fine... Isn't this an indicator, that the setup is proper?
(Right, I checked only to that point where I would get the build error)
Quote from: oBFusCATed on March 29, 2013, 08:01:49 PM
What OS/distros are you using? It compiles fine on my gentoo machine.
Also make sure you're using wxGTK-2.8.12!
Debian wheezy, 32-bit fully up to date here.
I look into it.
Quote from: Commaster on March 29, 2013, 08:03:51 PM
It compiles 8901 just fine... Isn't this an indicator, that the setup is proper?
8901 could not be fine... it will fail to load the CC plugin.
@thomas-denk: With the latest revision, your changes fail at:
filemanager.cpp: In function 'bool platform::move(const wxString&, const wxString&)':
filemanager.cpp:193:21: error: 'oldname' was not declared in this scope
filemanager.cpp:193:30: error: 'newname' was not declared in this scope
make[3]: *** [filemanager.lo] Error 1
make[3]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/sdk'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src'
make: *** [all-recursive] Error 1
@stefanos_:
it's already fixed in trunk.
@all with the build issues:
could you please replace $(PLUGIN_WX_LIBS) with $(WX_LIBS) or add the second in the Makefile.am in src/plugins/astyle ?
I also get this error with wheezy in one of my test-vm's.
I will fix it this evening.
Quote from: jens on March 29, 2013, 09:08:18 PM
could you please replace $(PLUGIN_WX_LIBS) with $(WX_LIBS) or add the second in the Makefile.am in src/plugins/astyle ?
added in rev8903, fails in autosave now. Looks like all plugins are affected. Thanks.
PLUGIN_WX_LIBS is no longer needed with no-undefined option.
I wonder why it works on fedora and gentoo.
I did not build (debian) nightlies since r8898, so I missed this issue.
Sorry for the inconvenience !
Should be fixed in svn r8926.
Quote from: jens on March 29, 2013, 10:11:22 PM
Should be fixed in svn r8926.
svn build rev 8926 (2013-03-29 21:04:23) gcc 4.7.2 Linux/unicode - 64 bit
Thank you very much!
We can now lock this topic, I think...
Thanks for this quick fix ! And don't be sorry Jens, the work of the CB team is just awesome :D
Latest revision compiles fine under Debian wheezy, 32-bit but the crashing issue with cleaning "Recent Projects > Clear History" still exists. I ran it via terminal and reports a Segmentation Fault.
Steps taken with gdb:
Loading toolbar...
Initializing plugins...
KeyBinder failed UpdateById on[3401][_Export]
KeyBinder failed UpdateById on[1019][Cu_t]
KeyBinder failed UpdateById on[1018][_Copy]
KeyBinder failed UpdateById on[1020][_Paste]
Program received signal SIGSEGV, Segmentation fault.
0x00000018 in ?? ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb657be48 in ?? () from /lib/i386-linux-gnu/libgcc_s.so.1
(gdb) c
Continuing.
[Thread 0xae05eb70 (LWP 9414) exited]
[Thread 0xb0321b70 (LWP 9379) exited]
[Thread 0xb0b22b70 (LWP 9378) exited]
[Thread 0xb1323b70 (LWP 9377) exited]
[Thread 0xb5fd5880 (LWP 9157) exited]
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
I hope it helps a bit; I don't know how to use it properly, therefore show some respect :D
Update: This time decided to throw a window with report: http://pastebin.com/bLqUevvm (http://pastebin.com/bLqUevvm)
Quote from: stefanos_ on March 30, 2013, 03:27:40 PM
I hope it helps a bit; I don't know how to use it properly, therefore show some respect :D
No, probably next time try to use the bt command, so the place where it have crashed is visible.
But don't worry this time because I get the crash, too.
I confirm that now, it compiles again. Thanks :)
Quote from: oBFusCATed on March 30, 2013, 07:54:03 PM
Quote from: stefanos_ on March 30, 2013, 03:27:40 PM
I hope it helps a bit; I don't know how to use it properly, therefore show some respect :D
No, probably next time try to use the bt command, so the place where it have crashed is visible.
But don't worry this time because I get the crash, too.
I have done so, and I hope it did it properly :D
Here you are:
http://pastebin.com/s2LbzixV (http://pastebin.com/s2LbzixV)
Quote from: stefanos_ on April 01, 2013, 08:19:41 PM
Quote from: oBFusCATed on March 30, 2013, 07:54:03 PM
Quote from: stefanos_ on March 30, 2013, 03:27:40 PM
I hope it helps a bit; I don't know how to use it properly, therefore show some respect :D
No, probably next time try to use the bt command, so the place where it have crashed is visible.
But don't worry this time because I get the crash, too.
I have done so, and I hope it did it properly :D
Here you are: http://pastebin.com/s2LbzixV (http://pastebin.com/s2LbzixV)
The crash happens, because the pointers holding the wxFileHistory-object for the projects and the files in MainFrame get recreated, but the pointers stored in the starthere-page are not updated.
Can you please test the attached patch ?
Quote from: jens on April 01, 2013, 09:41:16 PM
Can you please test the attached patch ?
Don't bother, I'm currently fixing this in a rather brutal way:)
Quote from: oBFusCATed on April 01, 2013, 11:11:18 PM
Quote from: jens on April 01, 2013, 09:41:16 PM
Can you please test the attached patch ?
Don't bother, I'm currently fixing this in a rather brutal way:)
The patch already by resetting the two pointers in the startherepage class at the end of
MainFrame::InitializeRecentFilesHistory(), that's the only place where the pointers get recreated in MainFrame.
Another (probably better) approach would be to have a (probably protected?) getter-function in MainFrame for the pointers, make both classes friends and always fetch the pointers if needed (not too expensive, because this happens not very often).
yep, the patch works just fine. Shall I fetch the latest updates and adjust to those?
Jens:
A really better approach is what I'm doing -> remove the code duplication by extracting the code for a single list in its own class.
Then I'll see if this logic can be simplified, further.
Please don't commit.
@Jens: The issue remains the same with Windows XP SP3, TDM's GCC 4.7.1-2, 32-bit, wxMGW-2.18.12; it crashes upon cleanup.
Check trunk head for the changes. Report any problems you encounter with the new version.
With the latest revision, it compiles on Windows and cleans the project history just fine. I will compile the latest revision on Debian wheezy too and let you know if not today, by tomorrow.
Cheers
Under Debian wheezy, the latest revision throws the following errors:
startherepage.h: In member function 'void StartHerePage::SetProjectsFiles(const wxFileHistory*, const wxFileHistory*)':
startherepage.h:32:74: error: no match for 'operator=' in '((StartHerePage*)this)->StartHerePage::m_projects = projects'
startherepage.h:32:74: note: candidate is:
recentitemslist.h:10:7: note: RecentItemsList& RecentItemsList::operator=(const RecentItemsList&)
recentitemslist.h:10:7: note: no known conversion for argument 1 from 'const wxFileHistory*' to 'const RecentItemsList&'
startherepage.h:32:94: error: no match for 'operator=' in '((StartHerePage*)this)->StartHerePage::m_files = files'
startherepage.h:32:94: note: candidate is:
recentitemslist.h:10:7: note: RecentItemsList& RecentItemsList::operator=(const RecentItemsList&)
recentitemslist.h:10:7: note: no known conversion for argument 1 from 'const wxFileHistory*' to 'const RecentItemsList&'
main.cpp: In member function 'void MainFrame::InitializeRecentFilesHistory()':
main.cpp:2192:48: error: 'm_pProjectsHistory' was not declared in this scope
main.cpp:2192:68: error: 'm_pFilesHistory' was not declared in this scope
make[3]: *** [main.o] Error 1
make[3]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src'
make: *** [all-recursive] Error 1
Quote from: stefanos_ on April 06, 2013, 03:11:34 PM
Under Debian wheezy, the latest revision throws the following errors:
startherepage.h: In member function 'void StartHerePage::SetProjectsFiles(const wxFileHistory*, const wxFileHistory*)':
startherepage.h:32:74: error: no match for 'operator=' in '((StartHerePage*)this)->StartHerePage::m_projects = projects'
startherepage.h:32:74: note: candidate is:
recentitemslist.h:10:7: note: RecentItemsList& RecentItemsList::operator=(const RecentItemsList&)
recentitemslist.h:10:7: note: no known conversion for argument 1 from 'const wxFileHistory*' to 'const RecentItemsList&'
startherepage.h:32:94: error: no match for 'operator=' in '((StartHerePage*)this)->StartHerePage::m_files = files'
startherepage.h:32:94: note: candidate is:
recentitemslist.h:10:7: note: RecentItemsList& RecentItemsList::operator=(const RecentItemsList&)
recentitemslist.h:10:7: note: no known conversion for argument 1 from 'const wxFileHistory*' to 'const RecentItemsList&'
main.cpp: In member function 'void MainFrame::InitializeRecentFilesHistory()':
main.cpp:2192:48: error: 'm_pProjectsHistory' was not declared in this scope
main.cpp:2192:68: error: 'm_pFilesHistory' was not declared in this scope
make[3]: *** [main.o] Error 1
make[3]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/stefanos/svn_code/CodeBlocks/src'
make: *** [all-recursive] Error 1
You should remove my (temporary) patch !
That's weird; when I ran "svn update", it found that specific files were conflicting with those from revision and choose the "mc" command to blame my local repo that issues the conflict.
Shall I roll back to a previous revision, recompile, and the fetch the latest HEAD?
Execute svn status to see which files have changed then execute svn revert for every file.
Quote from: oBFusCATed on April 07, 2013, 03:00:34 PM
Execute svn status to see which files have changed then execute svn revert for every file.
Or just delete them and do a new checkout/update .
I have reverted the files (src/src/main.cpp, src/src/startherepage.h, and src/src/startherepage.cpp) as oBFusCATed had suggested.
I'm waiting for it to finish.
UPDATE: Everything work just fine after running "svn revert" and recompiled everything. Now there's another issue with parser this time, which another user reported it until I figure out how to use GIMP to get a screenshot with the duplicate (and more!) content.
I report it here http://forums.next.codeblocks.org/index.php/topic,17647.msg121548.html#msg121548 (http://forums.next.codeblocks.org/index.php/topic,17647.msg121548.html#msg121548)
Same script as in 1st post.
OS Ubuntu 13.04 x64, wx 2.8.12.
Works with rev9159. Fails on rev9160:
make[5]: Leaving directory `/trunk/src/plugins/contrib/wxSmith/wxwidgets'
Making all in plugin
make[5]: Entering directory `/trunk/src/plugins/contrib/wxSmith/plugin'
/bin/bash ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/wxpropgrid/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxsmithpluginregistrants.lo -MD -MP -MF .deps/wxsmithpluginregistrants.Tpo -c -o wxsmithpluginregistrants.lo wxsmithpluginregistrants.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/wxpropgrid/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxsmithpluginregistrants.lo -MD -MP -MF .deps/wxsmithpluginregistrants.Tpo -c wxsmithpluginregistrants.cpp -fPIC -DPIC -o .libs/wxsmithpluginregistrants.o
mv -f .deps/wxsmithpluginregistrants.Tpo .deps/wxsmithpluginregistrants.Plo
make[5]: *** No rule to make target `../libwxsmithlib.la', needed by `libwxsmith.la'. Stop.
Quote from: Commaster on June 21, 2013, 07:40:59 AM
Same script as in 1st post.
OS Ubuntu 13.04 x64, wx 2.8.12.
Works with rev9159. Fails on rev9160:
make[5]: Leaving directory `/trunk/src/plugins/contrib/wxSmith/wxwidgets'
Making all in plugin
make[5]: Entering directory `/trunk/src/plugins/contrib/wxSmith/plugin'
/bin/bash ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/wxpropgrid/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxsmithpluginregistrants.lo -MD -MP -MF .deps/wxsmithpluginregistrants.Tpo -c -o wxsmithpluginregistrants.lo wxsmithpluginregistrants.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/wxpropgrid/include -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxsmithpluginregistrants.lo -MD -MP -MF .deps/wxsmithpluginregistrants.Tpo -c wxsmithpluginregistrants.cpp -fPIC -DPIC -o .libs/wxsmithpluginregistrants.o
mv -f .deps/wxsmithpluginregistrants.Tpo .deps/wxsmithpluginregistrants.Plo
make[5]: *** No rule to make target `../libwxsmithlib.la', needed by `libwxsmith.la'. Stop.
Fixed in trunk (svn r9162).
Thanks for reporting.
Sorry for pushing it too much, but in 9311 I get:
codecompletion.cpp: In constructor 'CodeCompletion::CodeCompletion()':
codecompletion.cpp:579:13: error: 'idSystemHeadersThreadFinish' was not declared in this scope
codecompletion.cpp: In destructor 'virtual CodeCompletion::~CodeCompletion()':
codecompletion.cpp:599:16: error: 'idSystemHeadersThreadFinish' was not declared in this scope
make[4]: *** [codecompletion.lo] Error 1
Thank you!
UPD: So I'm at 9310 now, seems to compile that spot just fine...
Revert one or two commits and should compile again... And then someone will fix it.
That's my fault, I will fix them soon. Sorry.
Quote from: ollydbg on September 11, 2013, 03:04:42 PM
That's my fault, I will fix them soon. Sorry.
Fixed in rev9312.