[Compile or cmake problems]

Fixed: https://github.com/TrinityCore/TrinityCore/commit/51287930cb147cace9308713d0affddbf38df4d8

["unknown column" "missing table" "duplicate column" error / sql problems / SQLDriverLogFile < answer on 1st post of 1st page]

Log is clear: "Unknown column 'type' in 'field list'"

 

You miss some sql updates, core crash because the database is not up to date.

[Compile or cmake problems]

Click: as we talked on IRC all the changes i introduced to cmake files were done by another dev i trust and i just pushed to TC. Forwarded your text to him and this is his answer (it's a copy&paste of his words)

 

Do you have any specific reasoning behind removing the cmake macro for OpenSSL-handling?

 

Cmake provides OpenSLL macro, but got it reverted as Shaured said cmake uses the first library it finds even if it's x86 when compiling x64

 

And, why are you rewriting the PCH-system?



PCH-headers including the .cpp header into a predefined object (gch-file) adds another useless file for gcc-based compilations, and the earlier version worked totally fine.



This ALSO destroys clusterbased compilation, since the gch-file is NEVER propagated to the external host systems. Which means that IF my buildbotsystem would use the PCH-system, it would fuck up, as the GCH-file is local, and not propagated to the cluster-compilers. This would then add load to the LOCAL system on a massive amount each time something was/is/will be pushed into the repository.



All you would have needed to do would be to add the correct testcase for clang, and adjust the macro accordingly - it has worked flawless for years.

 

Reason of change: Did not include support for OS X-specific features and did not retrieve all compile flags, so PCH were build with options not compatible with sources and were not used at all during compilation.
 

Will do further tests, change was done without thinking ccache / distcc

 

Now, to the main issue : why the HELL are you removing GCC-specific compileflags allowing debugging to be done properly under GDB3?

This is not something that you or anyone else should nilly-willy do without discussing it here first.

Some info:



-ggdb : Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.



vs



-g3 : Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.



These two are NOT EQUAL, and removes specific GDB3-tagging in the binary - basically, you're fucking up gdb debugging, which is the standard debugger for *nix-based platforms

If clang fails using it, tough luck, define it different for clang through the cmake/compiler/* definitions per compiler, and EXPLICITLY test if you're under clang.

 

Wrong. -ggdb produce debug information in GDB-specific format, it is not a right format on all platforms. (also GDB3 does not exists for more than 20 years, 3.1 release was done in 1989) -g3 produces the most possible debug info.

 

"-g
    Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information.
 
    On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below)."

 

So g3 will enable most (if not all) extensions that are enabled by ggdb if native debug format is the same.
Official docs are here: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options
 

Sure, I'm fucking it up and use it on everyday basis as my primary development OS is UNIX-like

 

Also, the full removal of xcode is not even discussed - if you've got a problem with supporting xcode, take it here.

 

xcode is an IDE, code was changed to support clang (compiler). To specific suppor for xcode something like this should be added

if(MSVC)

  message(FATAL_ERROR "Your compiler is not supported. Consider using GCC or Clang.")

endif()


if("${CMAKE_GENERATOR}" MATCHES "Xcode")

  set(GLOBAL_XCODE_PROPERTIES

    XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "gnu++0x"

    XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++"

    XCODE_ATTRIBUTE_CLANG_LINK_OBJC_RUNTIME NO

    XCODE_ATTRIBUTE_CLANG_WARN_IMPLICIT_SIGN_CONVERSION NO

    XCODE_ATTRIBUTE_CLANG_WARN_SUSPICIOUS_IMPLICIT_CONVERSION NO

    XCODE_ATTRIBUTE_CLANG_WARN__EXIT_TIME_DESTRUCTORS NO

    XCODE_ATTRIBUTE_GCC_C_LANGUAGE_STANDARD "gnu99"

    XCODE_ATTRIBUTE_GCC_ENABLE_OBJC_EXCEPTIONS NO

    XCODE_ATTRIBUTE_GCC_INLINES_ARE_PRIVATE_EXTERN YES

    XCODE_ATTRIBUTE_GCC_STRICT_ALIASING YES

    XCODE_ATTRIBUTE_GCC_SYMBOLS_PRIVATE_EXTERN YES

    XCODE_ATTRIBUTE_GCC_TREAT_INCOMPATIBLE_POINTER_TYPE_WARNINGS_AS_ERRORS YES

    XCODE_ATTRIBUTE_GCC_WARN_64_TO_32_BIT_CONVERSION NO

    XCODE_ATTRIBUTE_GCC_WARN_ABOUT_MISSING_NEWLINE YES

    XCODE_ATTRIBUTE_GCC_WARN_ABOUT_RETURN_TYPE YES

    XCODE_ATTRIBUTE_GCC_WARN_FOUR_CHARACTER_CONSTANTS YES

    XCODE_ATTRIBUTE_GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS YES

    XCODE_ATTRIBUTE_GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED YES

    XCODE_ATTRIBUTE_GCC_WARN_NON_VIRTUAL_DESTRUCTOR YES

    XCODE_ATTRIBUTE_GCC_WARN_PEDANTIC YES

    XCODE_ATTRIBUTE_GCC_WARN_SHADOW YES

    XCODE_ATTRIBUTE_GCC_WARN_SIGN_COMPARE YES

    XCODE_ATTRIBUTE_GCC_WARN_UNINITIALIZED_AUTOS YES

    XCODE_ATTRIBUTE_GCC_WARN_UNUSED_PARAMETER YES

    XCODE_ATTRIBUTE_GCC_WARN_UNUSED_VARIABLE YES

    XCODE_ATTRIBUTE_WARNING_CFLAGS "-Wall -Wextra"

  )

  if(NOT DEFINED OVERRIDE_DONE)

    set(OVERRIDE_DONE 1)

    function(add_executable TARGET)

      _add_executable(${TARGET} ${ARGN})

      set_target_properties(${TARGET} PROPERTIES ${GLOBAL_XCODE_PROPERTIES})

    endfunction()

    function(add_library TARGET)

      _add_library(${TARGET} ${ARGN})

      set_target_properties(${TARGET} PROPERTIES ${GLOBAL_XCODE_PROPERTIES})

    endfunction()

  endif()

else()

  set(CMAKE_BUILD_TYPE_INIT "Debug")

  set(FLAGS_C "-fvisibility=hidden -pedantic -W -Wall -Wextra -Wno-missing-field-initializers")

  set(FLAGS_CXX "${FLAGS_C} -fvisibility-inlines-hidden")


  if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")

    set(CMAKE_C_FLAGS_INIT "-std=gnu99 ${FLAGS_C} ${CMAKE_C_FLAGS_INIT}")

    set(CMAKE_CXX_FLAGS_INIT "-std=gnu++11 ${FLAGS_CXX} ${CMAKE_CXX_FLAGS_INIT}")

  elseif ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")

    set(CMAKE_C_FLAGS_INIT "-std=gnu99 ${FLAGS_C} ${CMAKE_C_FLAGS_INIT}")

    set(CMAKE_CXX_FLAGS_INIT "-std=gnu++11 -stdlib=libc++ ${FLAGS_CXX} ${CMAKE_CXX_FLAGS_INIT}")

  endif()

endif()

Now, the last part that I really want to air out : why the hell are you removing the -fno-delete-null-pointer-checks parameter? That is there for a purpose, namely to allow NP-bugs to be properly debugged and checked. -fdelete-null-pointer-checks Assume that programs cannot safely dereference null pointers, and that no code or data elemet resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null. Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior. Some targets, especially embedded ones, disable this option at all levels. Otherwise it is enabled at all levels: -O0, -O1, -O2, -O3, -Os. Passes that use the information are enabled independently at different optimization levels.

  Not required if program is correct. Will provide an example as soon as I rebott to mac, brb.

template<class T>

void FleeingMovementGenerator<T>::_setTargetLocation(T &owner)

{

    if (!&owner)

        return;

 

For example this code in trinity repo. Something is passed by reference and reference can not be NULL (in case some specific mumbo-jumbo is not done). With -fno-delete-no-pointer-checks compiler has to produce code for this check, though it is useless in 99% of cases. In fact I remember only one discussion when NULL pointer check was wrongly removed in Linux kernel sources, I doubt that it is ever required in userspace program.