Author Topic: Building from the new SF repo  (Read 32878 times)

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Building from the new SF repo
« on: March 29, 2013, 01:59:30 pm »
Since old times I have this self-made building script. It's terribly wrong and inefficient, but it worked every time.
Code
#!/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.
Code
.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.
« Last Edit: March 29, 2013, 08:00:32 pm by Commaster »

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: Building from the new SF repo
« Reply #1 on: March 29, 2013, 06:51:34 pm »
I get the same errors with the previous repo. I have not been able to compile a new version since rev 8900.
Kernel Extremist - PedroM power ©

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #2 on: March 29, 2013, 06:53:45 pm »
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!
« Last Edit: March 29, 2013, 07:46:35 pm by stefanos_ »

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #3 on: March 29, 2013, 07:51:40 pm »
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
« Last Edit: March 29, 2013, 08:25:53 pm by Commaster »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #4 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!
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #5 on: March 29, 2013, 08:03:51 pm »
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)
« Last Edit: March 29, 2013, 08:45:26 pm by Commaster »

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #6 on: March 29, 2013, 08:37:56 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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #7 on: March 29, 2013, 08:38:28 pm »
I look into it.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #8 on: March 29, 2013, 08:41:36 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #9 on: March 29, 2013, 08:53:00 pm »
@thomas-denk: With the latest revision, your changes fail at:

Code
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

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #10 on: March 29, 2013, 09:08:18 pm »
@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 ?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #11 on: March 29, 2013, 09:19:58 pm »
I also get this error with wheezy in one of my test-vm's.

I will fix it this evening.

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #12 on: March 29, 2013, 09:30:25 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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #13 on: March 29, 2013, 10:01:29 pm »
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 !

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #14 on: March 29, 2013, 10:11:22 pm »
Should be fixed in svn r8926.

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #15 on: March 30, 2013, 12:01:29 am »
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...

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: Building from the new SF repo
« Reply #16 on: March 30, 2013, 09:42:58 am »
Thanks for this quick fix ! And don't be sorry Jens, the work of the CB team is just awesome :D
Kernel Extremist - PedroM power ©

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #17 on: March 30, 2013, 03:27:40 pm »
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:

Code
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
« Last Edit: March 30, 2013, 06:35:21 pm by stefanos_ »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #18 on: March 30, 2013, 07:54:03 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: Building from the new SF repo
« Reply #19 on: March 31, 2013, 09:41:21 pm »
I confirm that now, it compiles again. Thanks :)
Kernel Extremist - PedroM power ©

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #20 on: April 01, 2013, 08:19:41 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

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #21 on: April 01, 2013, 09:41:16 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
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 ?
« Last Edit: April 01, 2013, 09:44:11 pm by jens »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #22 on: April 01, 2013, 11:11:18 pm »
Can you please test the attached patch ?
Don't bother, I'm currently fixing this in a rather brutal way:)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #23 on: April 01, 2013, 11:26:07 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).

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #24 on: April 02, 2013, 12:06:58 am »
yep, the patch works just fine. Shall I fetch the latest updates and adjust to those?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #25 on: April 02, 2013, 12:36:47 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #26 on: April 02, 2013, 02:31:27 pm »
@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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #27 on: April 03, 2013, 11:19:01 pm »
Check trunk head for the changes. Report any problems you encounter with the new version.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #28 on: April 04, 2013, 11:05:26 am »
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

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #29 on: April 06, 2013, 03:11:34 pm »
Under Debian wheezy, the latest revision throws the following errors:

Code
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

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #30 on: April 06, 2013, 03:39:52 pm »
Under Debian wheezy, the latest revision throws the following errors:

Code
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 !

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #31 on: April 07, 2013, 02:51:24 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #32 on: April 07, 2013, 03:00:34 pm »
Execute svn status to see which files have changed then execute svn revert for every file.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #33 on: April 07, 2013, 03:13:20 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 .

stefanos_

  • Guest
Re: Building from the new SF repo
« Reply #34 on: April 07, 2013, 03:47:26 pm »
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.codeblocks.org/index.php/topic,17647.msg121548.html#msg121548
« Last Edit: April 07, 2013, 11:11:40 pm by stefanos_ »

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #35 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:
Code
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Building from the new SF repo
« Reply #36 on: June 21, 2013, 08:12:32 am »
Same script as in 1st post.
OS Ubuntu 13.04 x64, wx 2.8.12.

Works with rev9159. Fails on rev9160:
Code
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.

Online Commaster

  • Almost regular
  • **
  • Posts: 171
Re: Building from the new SF repo
« Reply #37 on: September 11, 2013, 02:53:09 pm »
Sorry for pushing it too much, but in 9311 I get:

Code
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...
« Last Edit: September 11, 2013, 03:01:28 pm by Commaster »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Building from the new SF repo
« Reply #38 on: September 11, 2013, 02:58:12 pm »
Revert one or two commits and should compile again... And then someone will fix it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Building from the new SF repo
« Reply #39 on: September 11, 2013, 03:04:42 pm »
That's my fault, I will fix them soon. Sorry.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Building from the new SF repo
« Reply #40 on: September 11, 2013, 03:16:15 pm »
That's my fault, I will fix them soon. Sorry.
Fixed in rev9312.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.