Difference between revisions of "Getting Started/Build/Distributions/FreeBSD"

Jump to: navigation, search
(MAP_ANONYMOUS was not declared in this scope)
 
(21 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Template:I18n/Language Navigation Bar|Getting_Started/Build/KDE4/FreeBSD}}
+
 
 
{{KDE4}}
 
{{KDE4}}
This page is focused on building KDE4 from svn source on FreeBSD, information specific to creating/building/using the FreeBSD ports of KDE4 should be gathered on the [http://wiki.freebsd.org/KDE4 FreeBSD Wiki].
 
  
==Required Ports==
+
This page focuses on building KDE SC '''trunk''' on FreeBSD. For building and using stable KDE SC releases on FreeBSD, you should use the ports collection. See the [http://freebsd.kde.org/ports.php KDE/FreeBSD website] for more information.
 +
 
 +
==Required ports==
 +
* devel/boost-python (for pimlibs)
 +
* devel/cmake
 
* devel/dbus
 
* devel/dbus
* devel/cmake
+
* devel/git
* x11/xorg (Presumably you could do with less... but I haven't done that yet)
+
 
* devel/subversion
 
* devel/subversion
* textproc/redland (for support/soprano)
+
* graphics/libungif (for libs)
 
* misc/shared-mime-info (for libs)
 
* misc/shared-mime-info (for libs)
* graphics/libungif (for libs)
+
* multimedia/libxine (for runtime, or configure with KDE4_DISABLE_MULTIMEDIA)
* devel/boost-python (for pimlibs)
+
 
* security/gpgme (for pimlibs)
 
* security/gpgme (for pimlibs)
* multimedia/libxine (for base-or config with KDE4_DISABLE_MULTIMEDIA)
 
* shells/bash (if using kdesvn-build)
 
 
* textproc/libxslt
 
* textproc/libxslt
* (expand as needed, this is a wiki :)
+
* textproc/redland (for support/soprano)
 +
* x11/xorg
 +
* x11-toolkits/shared-desktop-ontologies
  
 
==Differences from the normal build process==
 
==Differences from the normal build process==
The page on [[Getting_Started/Build/KDE4|building KDE4]] trunk makes a few assumptions about your environment. Note that FreeBSD's dbus and cmake ports will work (so those sections can be skipped).
+
The page on [[Getting_Started/Build|building KDE SC 4]] trunk makes a few assumptions about your environment. Note that FreeBSD's dbus and cmake ports will work (so those sections can be skipped).
  
==Using kdesvn-build==
+
Sometimes, building with '''make''' can fail on some modules. You should try using '''gmake''' instead.
The [http://kdesvn-build.kde.org/ kdesvn-build] script can be used on FreeBSD. The following describes an issue that seems to no longer occur:
+
  
qt-copy is going to fail to build dbus support due to reasons described below, so you can either run "kdesvn-build qt-copy" once... apply the fix below, then run "kdesvn-build". Alternatively, you can add "-lpthread" to the configure-flags in the qt-copy section of your .kdesvn-buildrc .
+
==Using kdesrc-build==
 
+
The [http://kdesrc-build.kde.org/ kdesrc-build] script can be used on FreeBSD. Note that if there are errors building qt-copy or libs, look at the issues below and fix them, then continue the build using kdesrc-build.
Yet another option is to add -DCMAKE_EXE_LINKER_FLAGS=-pthread to your cmake flags, which will add -pthread to the link lines of all executables.
+
  
 
==Errors compiling qt-copy==
 
==Errors compiling qt-copy==
; Even when I tell it to, qt-copy is not compiling with dbus support
+
; My build of qt-copy is failing when I have Qt 3 from ports installed.
; This seems to no longer be an issue when using kdesvn-build
+
For some reason, the configure system will sometimes put -I/usr/local/include (which contains the ports version of Qt 3 headers) into the general CXXFLAGS variable. Note that there is an INCPATH variable for these include paths which should also contain -I/usr/local/include. The difference is in the compile line; CXXFLAGS's appears first, whereas the paths in INCPATH are ordered properly such that the local (current build) headers are checked first. You need to go into the directory where the build is failing (use the previous lines before the error message), and open the Makefile. You should see the the -I/usr/local/include line in the CXXFLAGS line, and you can safetly remove it '''if''' there is a -I/usr/local/include line in INCPATH.
This is related to the test app for dbus in qt-copy not linking due to a pthreads dependency in libdbus on FreeBSD. To fix it go to: (builddir)/qt-copy/config.tests/unix/dbus . Then manually run
+
This seems to usually happen in build_dir/qt-copy/src/plugins/sqldrivers/psql/Makefile.
g++ dbus.o -lpthread -ldbus-1 -L/usr/local/lib -o dbus
+
That should generate the "dbus" file, and you should be able to continue your qt build as you left off, building dbus this time
+
  
; My build of qt-copy is failing when I have Qt4 from ports installed.
+
==Errors compiling kdesupport==
For some reason, the configure system will sometimes put -I/usr/local/include (which contains the ports version of qt4 headers) into the general CXXFLAGS variable. Note that there is an INCPATH variable for these include paths which should also contain -I/usr/local/include. The difference is in the compile line; CXXFLAGS's appears first, whereas the paths in INCPATH are ordered properly such that the local (current build) headers are checked first. You need to go into the directory where the build is failing (use the previous lines before the error message), and open the Makefile. You should see the the -I/usr/local/include line in the CXXFLAGS line, and you can safetly remove it IF there is a -I/usr/local/include line in INCPATH.
+
; System-wide Qt 4 keeps being found instead of qt-copy
This seems to usually happen in build_dir/qt-copy/src/plugins/sqldrivers/psql/Makefile
+
Sometimes, /usr/local/bin/qmake-qt4 insists on being found instead of qt-copy's qmake, which in turn makes cmake use the system-wide Qt during compilation. If everything else fails, you can pass -DQT_QMAKE_EXECUTABLE=/your/path/qmake to cmake.
  
; My build of qt-copy is failing in qatomic_x86_64.h on my 64bit system.
+
; Cannot link to polkit-dbus
See [http://trolltech.com/developer/task-tracker/index_html?method=entry&id=161994 Trolltech's bugzilla] for a description of this problem.  It's an issue with gcc3 and 64bit systems, with a particular optimization. Possible solutions described there include "To work around this bug, recompile qstylesheetstyle.cpp with removing -O2, or add the -fno-gcse compiler option."
+
If all polkit-related ports are correctly installed and the error persists, you most likely need to export LIBRARY_PATH and include /usr/local/lib in it.
 
+
; My build of qt-copy is failing because MAP_ANONYMOUS was not declared.
+
The flag MAP_ANONYMOUS is used in qt-copy/src/3rdparty/webkit/JavaScriptCore/kjs/collector.cpp:139 in function mmap(). FreeBSD's mmap() does not know the flag MAP_ANONYMOUS but MAP_ANON.
+
 
+
==Errors compiling kdelibs==
+
; kdelibs wont compile, complaining that it can't find qdbus
+
See the above question on dbus not compiling (even if you told it to compile). If Qt can't find the dbus libs, it silently fails and will continue to build without dbus.
+
 
+
==Errors compiling kdesupport==
+
; The following seems to no longer be an issue (at least as of Apr25)
+
Strigi is a prereq for building kdelibs at the moment. As of now (Apr 5), there appears to be an issue with building kdesupport/strigi/src/streams/tests/InputStreamReaderTest.cpp on systems where iconv.h does not live in /usr/include. Use "VERBOSE=1 make" to view the offending command, and then run it, modifying it by adding "-I/usr/local/include" to the big list of -I directives (you may also have to fix a few paths... be sure to put it in the right place!). At this point, the rest of the compile should go smoothly.
+

Latest revision as of 17:26, 13 July 2012

Ktip.png
 
Tip
Note: This page is about KDE 4. It isn't applicable for KDE 3 development.

This page focuses on building KDE SC trunk on FreeBSD. For building and using stable KDE SC releases on FreeBSD, you should use the ports collection. See the KDE/FreeBSD website for more information.

Contents

[edit] Required ports

  • devel/boost-python (for pimlibs)
  • devel/cmake
  • devel/dbus
  • devel/git
  • devel/subversion
  • graphics/libungif (for libs)
  • misc/shared-mime-info (for libs)
  • multimedia/libxine (for runtime, or configure with KDE4_DISABLE_MULTIMEDIA)
  • security/gpgme (for pimlibs)
  • textproc/libxslt
  • textproc/redland (for support/soprano)
  • x11/xorg
  • x11-toolkits/shared-desktop-ontologies

[edit] Differences from the normal build process

The page on building KDE SC 4 trunk makes a few assumptions about your environment. Note that FreeBSD's dbus and cmake ports will work (so those sections can be skipped).

Sometimes, building with make can fail on some modules. You should try using gmake instead.

[edit] Using kdesrc-build

The kdesrc-build script can be used on FreeBSD. Note that if there are errors building qt-copy or libs, look at the issues below and fix them, then continue the build using kdesrc-build.

[edit] Errors compiling qt-copy

My build of qt-copy is failing when I have Qt 3 from ports installed.

For some reason, the configure system will sometimes put -I/usr/local/include (which contains the ports version of Qt 3 headers) into the general CXXFLAGS variable. Note that there is an INCPATH variable for these include paths which should also contain -I/usr/local/include. The difference is in the compile line; CXXFLAGS's appears first, whereas the paths in INCPATH are ordered properly such that the local (current build) headers are checked first. You need to go into the directory where the build is failing (use the previous lines before the error message), and open the Makefile. You should see the the -I/usr/local/include line in the CXXFLAGS line, and you can safetly remove it if there is a -I/usr/local/include line in INCPATH. This seems to usually happen in build_dir/qt-copy/src/plugins/sqldrivers/psql/Makefile.

[edit] Errors compiling kdesupport

System-wide Qt 4 keeps being found instead of qt-copy

Sometimes, /usr/local/bin/qmake-qt4 insists on being found instead of qt-copy's qmake, which in turn makes cmake use the system-wide Qt during compilation. If everything else fails, you can pass -DQT_QMAKE_EXECUTABLE=/your/path/qmake to cmake.

Cannot link to polkit-dbus

If all polkit-related ports are correctly installed and the error persists, you most likely need to export LIBRARY_PATH and include /usr/local/lib in it.


This page was last modified on 13 July 2012, at 17:26. This page has been accessed 38,011 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal