[SOLVED]Compile error

Hello I’m trying to make newest Trinitycore branch 3.3.5. I’m building it on Ubuntu 15.01. I’ve did all steps as on Triniticore installation wiki. After 15% percent this happened

http://i.imgur.com/GeufFYM.png

can someone help me with it? :slight_smile: I want to finally build Trinitycore after 2 days

— Canned message start —

If this is your 1st time with TrinityCore read http://collab.kpsn.org/display/tc/TrinityCore+Home

Also read http://www.trinitycore.org/f/topic/1518-trouble-with-your-trinity-install-readme-1st-faqs/

     and [http://www.trinitycore.org/f/topic/10656-updating-or-starting-with-trinitycore-issues/](http://www.trinitycore.org/f/topic/10656-updating-or-starting-with-trinitycore-issues/)

Since those threads are big, use control+f to find your keyword on them, also try different keywords.

Also please Look in upper right hand corner of the forum, there is a button labeled search field, feel free to search for your issues first before posting, most questions like this one have already been answered.

If you still cannot find the answers you seek feel free to make a post and tell us the steps you took to resolve this issue and we will do our best to help you.

— Canned message end —

Did you try compiling multiple times?
Try using less jobs if you use multiple, maybe one only.

The error says it is an internal compiler error. It may be a bug in the compiler and not related to trinity.

@rochet2 jump into irc! XD

hi,

Ive tried to Compile with VS2013 on Windows 10 x64

  • TrinityCore revision : ce0ce25a666f 2016-04-20 12:59:57 +0200 (6.x branch)

char const* GitRevision::GetFullVersion()
{
#if PLATFORM == PLATFORM_WINDOWS
# ifdef _WIN64
return _PACKAGENAME " rev. " VER_PRODUCTVERSION_STR " (Win64, " _BUILD_DIRECTIVE “)”;
# else
return _PACKAGENAME " rev. " VER_PRODUCTVERSION_STR " (Win32, " _BUILD_DIRECTIVE “)”;
# endif
#else
return _PACKAGENAME " rev. " VER_PRODUCTVERSION_STR " (Unix, " _BUILD_DIRECTIVE “)”;
#endif

Fehler 27 error C2146: Syntaxfehler: Fehlendes ‘;’ vor Bezeichner ‘_BUILD_DIRECTIVE’ E:\src\common\GitRevision.cpp 57 1 common
Fehler 28 error C2065: ‘_BUILD_DIRECTIVE’: nichtdeklarierter Bezeichner E:\src\common\GitRevision.cpp 57 1 common
Fehler 29 error C2143: Syntaxfehler: Es fehlt ‘;’ vor ‘Zeichenfolge’ E:\src\common\GitRevision.cpp 57 1 common

how to fix it :slight_smile:

https://github.com/TrinityCore/TrinityCore/issues/16673

not the same…that was linux…an i have a clean enviroment used.

Could you open an issue at https://github.com/TrinityCore/TrinityCore/issues? Make sure to include your current revision, OS version, VS/MSVC versions, etc

Having issues with latest ( b82ffb8 at the time of writing).

My compile script can be found here, starting on line 57 and ending on line 68 for the purposes of relevance.

I looked at #14657, which seemed to be someone with the same issue, but no love there. I’m not running Arch.

CentOS 7.2 x64, cmake3 version 3.5.1 (I also have cmake 2.8.11 installed, but I’m explicitly referencing cmake3 in my build script), gcc 4.8.5. I successfully built the server on March 15th and this is the first time I’ve tried since (my last successful build was [FONT=‘courier new’]632e667[/FONT]). SELinux is set to permissive.

When running make, I get the following error:

[FONT=‘courier new’][ 5%] Building C object dep/jemalloc/CMakeFiles/jemalloc.dir/src/arena.c.o[/FONT]

[FONT=‘courier new’]In file included from /home/XXXXX/TrinityCore/dep/jemalloc/include/jemalloc/internal/jemalloc_internal.h:568:0, [/FONT]

[FONT=‘courier new’] from /home/XXXXX/TrinityCore/dep/jemalloc/src/arena.c:2:/home/XXXXX/TrinityCore/dep/jemalloc/include/jemalloc/internal/util.h:88:49: error: expected ‘;’, ‘,’, or ‘)’ before ‘nptr’[/FONT]

[FONT=‘courier new’] uintmax_t malloc_strtoumax(const char *restrict nptr,[/FONT]

[FONT=‘courier new’]make[2]: *** [dep/jemalloc/CMakeFiles/jemalloc.dir/src/arena.c.o] Error 1[/FONT]

[FONT=‘courier new’]make[1]: *** [dep/jemalloc/CMakeFiles/jemalloc.dir/all] Error 2[/FONT]

[FONT=‘courier new’]make: *** [all] Error 2[/FONT]

Nothing changed the way Jemalloc is used recently.

I don’t really have a fix for your issue but you can try one of these:

[ul][li]Make sure that the build directory has been cleaned up before compiling again[/li]
[li]Disable Jemaloc by using -DNOJEM=1[/li]
[li]Change from GCC to Clang (it’s also generally faster compiliing)[/li]
[/ul]

I removed cmake from yum, installed cmake following https://xinyustudio.wordpress.com/2014/06/18/how-to-install-cmake-3-0-on-centos-6-centos-7/ and it passes jemalloc stage:

http://i.imgur.com/qjYZdsm.pnghttp://i.imgur.com/jhCViVe.png

http://i.imgur.com/f2IHpNC.png

http://i.imgur.com/77jcANQ.png

Clearing out the build directory seems to have done it. There was stuff in there from as far back as June of 2015, so immediate assumption is that it had something to do with old stuff that needed to get rebuilt, or something that cmake 2 left behind. I’ll add a full clear of the build directory, not just clearing the one file, to the build script.

Thanks very much for the help on this one. I was banging my head against it for hours and didn’t think to try the basic “clear out the old stuff” step. Really appreciated.

I don’t have a wiki account, but the RHEL docs could be updated - in the interest of ease of use - to:

[FONT=‘courier new’]yum install epel-release -y && yum install cmake3[/FONT]

[FONT=arial]rather than what’s there. Plus, that way, no need to build cmake 3 from source.[/FONT]

[FONT=arial]As a side note - and now is when I’m starting to stray from original scope - but as someone who has zero experience with clang as a compiler, is it worth making the switch?[/FONT]

Clang is supposed to be a drop in replacement for GCC. Simply install it, change CC and CXX (or equivalent of update-alternatives on CentOS) and you are good to go. Clang is most of times faster than GCC and it shows some better warnings. However GCC 6.1 was released recently and it looks good.

Give it a try, you can always go back with a command.

Ref the wiki, anyone can make edits, thanks!

Cool. I’ll hop in and mess around with the CentOS/RHEL install instructions in the wiki then. I’ve got a dev Fedora box that I’ll stick Clang on and give it a shot. Appreciate the advice and help!

edit: After testing on my Fedora box, all that needs to happen is:

yum remove gcc gcc-c++ && yum install clang

and clang will just start working, with no further changes. It’s also way faster. Thanks again for the advice.

Greetings community, as I’m trying to generate the code for the 6.xx core on cmake I find that If I use Boost 1.55 the code generation is completed with no issues, however, when I try to compile the core, I get several errors, then I found out that I have to use a newer version of Boost to get rid of them. Problem is, when I switch to a newer version of boost (tried versions 1.59 and newest 1.61), cmake does not recognize them leading to the errors shown in this picture.

What I do to switch between versions is go into Control Panel -> System and Security -> System -> Advanced System Configuration -> Environment Variables and set the path there.

So how can I solve this? thanks!

[ATTACH]1786._xfImport[/ATTACH]

Do you have Boost 1.61 compiled for VS 2013 64 bits? https://sourceforge.net/projects/boost/files/boost-binaries/1.61.0/ boost_1_61_0-msvc-12.0-64.exe

Do you have a BOOST_ROOT env var set to Boost dir? e.g [FONT=courier new]C:/boost_1_61_0[/FONT] (no slash at the end)

Thanks Nay, you helped realize that I had installed boost_1_61_0-msvc-14.0-64.exe instead of boost_1_61_0-msvc-12.0-64.exe and that worked.

— Canned message start —
It appears the issue in the original post was solved, so this thread shall be closed.
Should you encounter any other difficulties, please open a new thread.
— Canned message end —

— Canned message start —
It appears the issue in the original post was solved, so this thread shall be closed.
Should you encounter any other difficulties, please open a new thread.
— Canned message end —

— Canned message start —
It appears the issue in the original post was solved, so this thread shall be closed.
Should you encounter any other difficulties, please open a new thread.
— Canned message end —