I'm trying to build VirtualBox 5.2.18 on Ubuntu Server LTS 18.04 64-bit. I want to build it without any GUI components and without Guest Additions, as I want to avoid installing any unnecessary dependencies. I am using the following options when configuring:
./configure --build-headless --disable-qt --disable-alsa --disable-pulse --disable-opengl --disable-sdl-ttf --disable-libvpx --disable-docs
Although there is an option to only build the Guest Additions (--only-additions), there doesn't seem to be an option passable to configure to skip building Guest Additions. Is there a way to skip building Guest Additions, or perhaps to ignore any build-time errors related to building Guest Additions?
I found a solution in https://forums.virtualbox.org/viewtopic.php?t=33090&start=0, which contains more useful details. One can build VirtualBox without GUI or Guest Additions by adding the following lines to LocalConfig.kmk in the root of the development tree:
VBOX_WITHOUT_ADDITIONS = 1
VBOX_WITH_HEADLESS = 1
VBOX_WITH_VRDP=
VBOX_WITH_VRDP_VIDEO_CHANNEL=
VBOX_WITH_VRDP_AUTHMOD=
VBOX_WITH_VRDP_RDESKTOP=
VBOX_WITH_VBOXFB=
VBOX_WITH_KCHMVIEWER=
VBOX_WITH_TESTSUITE=
VBOX_WITH_TESTCASES=
VBOX_WITH_SHARED_FOLDERS=
VBOX_WITH_SHARED_CLIPBOARD=
VBOX_WITH_VNC =
VBOX_X11_SEAMLESS_GUEST=
VirtualBox can then be built by executing the following in the root folder:
./configure --build-headless --disable-qt --disable-alsa --disable-pulse --disable-opengl --disable-sdl-ttf --disable-libvpx --disable-docs
source env.sh
kmk
It is unclear which of the options is necessary for skipping the building of the guest additions (in either LocalConfig.kmk or those passed to ./configure).
When kmk packing is executed, the following error message might appear:
kmk: *** No rule to make target `.../out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso',
needed by `.../out/linux.amd64/release/obj/Installer/linux/archive/additions/VBoxGuestAdditions.iso'.
Stop.
This error can be avoided by executing a touch command before kmk packing (this fix was obtained from https://forums.virtualbox.org/viewtopic.php?f=10&t=41598&p=187420&hilit=VBoxGuestAdditions#p187420):
kmk
mkdir -p out/linux.amd64/release/bin/additions/
touch out/linux.amd64/release/bin/additions/VBoxGuestAdditions.iso
kmk packing
The mkdir command was added before touch because touch might fail if the directory out/linux.amd64/release/bin/additions/ did not exist.
Some errors might come up during installation of VirtualBox-*.run, but it should successfully completely. However, if you try to execute VBoxManage, you might get the following error:
Could not find VirtualBox installation. Please reinstall.
This arises most probably because the executable file VirtualBox was not found in the installation folder (usually /opt/VirtualBox). The file VirtualBox is the GUI component which was not built. We can bypass the error by editing VBox.sh in the installation folder, and changing the line
elif test -f "${MY_DIR}/VirtualBox" && test -x "${MY_DIR}/VirtualBox"; then
to
elif test -f "${MY_DIR}/VBoxHeadless" && test -x "${MY_DIR}/VBoxHeadless"; then
VirtualBox should now run without any problems.
Related
To be more specific, my source code is compiled and linked successfully when I am running it from inside the container.
However, when I am trying to build the image from a Dockerfile it fails.
i.e.:
this works (These lines are from the terminal "inside" the container):
cd AppFolder; make; //success
this does not (These are lines from the dockerfile):
RUN git clone <url> && cd APPFolder && make
Now I get:
/usr/bin/ld: warning: libcuda.so.1 needed by...
How can I build the application from the dockerfile?
The only difference between a container and a layer during the image build is the next layers. perhaps you are running the RUN directive to early - i.e. before the cuda library was generated?
try putting this command as low as you can in the Dockerfile
Well, adding "-Wl,--allow-shlib-undefined" to the compiler/linker (g++) solved this issue. I think it "tells" the linker to "remain" pointer to function that will be "linked" only in runtime (i.e., when running the docker image)
The compilation of the CEF in Windows 10 until now has been a week of work and various remediation. Now it seems that I am at the last steps of the compilation but I have a problem not yet solved, Ninja fails at
[30545/36949] ACTION //tools/v8_context_snapshot:gener..._context_snapshot(//build/toolchain/win:win_clang_x86)
FAILED: v8_context_snapshot.bin
C:/code/depot_tools/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe ../../build/gn_run_binary.py ./v8_context_snapshot_generator --output_file=v8_context_snapshot.bin
[1203/185351.657:FATAL:com_init_check_hook.cc(159)] Check failed: false. CoCreateInstance appears to be previously patched. <cc cc cc cc cc e9 2b> Attempted to write <e9 80 2f d6 91 eb f9>
My enviroment Windows10, VS 2017 v 15.9.28, Win 10.0.17763 SDK and Ninja.
Does anyone know what it can be?
Thank you very much kind regards
I was finally able to compile CEF with .mp4 support for the chosen version v75. I share with you all the steps necessary to compile in the windows environment.
What's Required for branch 3770 --> Chromium Version v 75.
Win 7+, VS2017 15.7.1+, Win 10.0.17763 SDK, Ninja, at least 8GB of RAM and 40GB of free disk space. Need particular attention to the SDK version, installed it separately and not with Visual Studio, moreover it must necessarily be the one indicated, if there are later versions uninstall them completely.
Install the required Visual Studio sub-components by passing the following arguments to the Visual Studio installer:
$ PATH_TO_INSTALLER.EXE ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--includeRecommended
See https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding.md#markdown-header-current-release-branches-supported.
For Download and correct build step by step see:https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart
This procedure as it is only the download of the Master proceeds,
If you want to compile a specific branch, compile the path where to download it and modify the update.bat file accordingly.
Set all necessary enviroment variable and restart the PC before all:
Variable CEF_USE_GN value CEF_USE_GN=1
Variable GN_DEFINES value Set GN_DEFINES=proprietary_codecs=1 ffmpeg_branding=Chrome
Variable Path add value of C:\code\depot_tools your path for folder depot_tools.
Variable DEPOT_TOOLS_WIN_TOOLCHAIN valore DEPOT_TOOLS_WIN_TOOLCHAIN=0.
For example for the 3770 branch
build the path C: \ code \ chromium_git3770
and write in update.bat like:
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2017 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=C:\code\chromium_git3770 --depot-tools-dir=C:\code\depot_tools --branch=3770 --no-distrib --no-build
and the Create.bat like:
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2017 --sln=cef --filters=//cef/*
call cef_create_projects.bat
Resolve error:
Error on build with Ninja
try running “gclient runhooks” from the chromium/src directory always from cmd
this command renews the files in depot_tools
on Windows 10 especially there are various problems and various issues (node.js is missing, etc.)
ImportError: No module named win32file
Install correct WinApi on python folder.
C:\code\depot_tools>python -m pip install pywin32
Error FAILED: v8_context_snapshot.bin
where suggested running "gn clean" before a full build in all out path to build, after each build with error.
Wait about 4 hours and you will have your buil.
When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.
I need some simple example to start using clang.
I downloaded llvm and clang and built:
mkdir llvm-build
cd llvm-build
../llvm/configure
make
I tried to build PrintFunctionNames from clang examples but got an error message:
../../../../Makefile.common:61: ../../../../Makefile.config: No such file or directory
../../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: * No rule to make target `/Makefile.rules'. Stop.
Readme file says that only make is needed.
So how to build this plugin?
Go into llvm-build/tools/clang, and run "make BUILD_EXAMPLES=1".
Most assuredly you will have your LLVM trunk checkout and under the tools path you have checked out Clang trunk as well [explained under building Clang via http://clang.llvm.org/get_started.html.
Makefile Build Guide: http://llvm.org/docs/MakefileGuide.html
On OS X the build set up is a bit different, but on Debian Linux I'm building it daily as follows:
../trunk/configure --enable-target=x86_64,arm,cpp,cbe --with-built-clang --enable-pic --enable-polly --enable-shared --with-cxx-include-arch=x86_64 --enable-optimized --with-optimize-option=-Os --enable-assertions --disable-bootstrap --disable-multilib --enable-jit --enable-threads --no-create --no-recursion
then applying the make -j (n+1 number of cores) on the command for my Pentium D 945 system:
make [building against autotools make -j (n+1) doesn't always building llvm cleanly as it does against cmake. So if you want to run all cores, expect the possibility of running make -j(n+1) more than once to result in a clean build.
Standard form without accessing multiple cores:
make BUILD_EXAMPLES='1' //Read the note below
always results in a clean build, and if it doesn't report a bug to LLVM.
Note: If you're at the top level you can svn update the llvm trunk, project-test trunk and clang trunk as follows:
make trunk
Then go and run make again now that BUILD_EXAMPLES=1 is configured ahead of time.
make BUILD_EXAMPLES='1'
NOTE: Autotools will allow one to configure the BUILD_EXAMPLES='1' but will ignore the flag when you go to run make if you don't explicitly include BUILD_EXAMPLES='1' after make on the command line.
At the top of the LLVM tree you build against running make BUILD_EXAMPLES='1' will build the LLVM specific examples, then going inside your build/tools/clang path you then must run make BUILD_EXAMPLES='1' again to build the Clang examples.
Hence:
LLVM Top:
make BUILD_EXAMPLES='1' // for LLVM examples
cd tools/clang
make BUILD_EXAMPLES='1' // for Clang specific examples
Verify the examples installing under /usr/local/bin for LLVM and /usr/local/lib/ for Clang.
If you use CMAKE the default location for the binary examples is under /usr/local/examples
I followed the instructions at http://clang.llvm.org/get_started.html with two exceptions:
My build dir is inside the source dir (i.e. cd llvm ; mkdir build), but I don't think it's relevant.
I issued cmake as so :
cd build
cmake -DLLVM_BUILD_EXAMPLES=1 -DCLANG_BUILD_EXAMPLES=1 ..
After that (and compiling of course (make -j8)) I could find the examples in the build dir :
find -iname '*printfunctionname*'
./lib/PrintFunctionNames.so
...
I tried to do something similar yesterday: get a list of methods in a class using clang and succeeded. Maybe my post helps here also. My best help was this AST Matchers tutorial.
I'm trying to build a moderately sized Symbian Qt project (around 100 files) using the latest released Nokia Qt SDK (Qt 4.6.3 and Qt Mobility 1.0.2).
The build for the simulator finishes in under 3 minutes, but when I build for the device, the build takes well over 20 minutes! I can forget trying to debug on the device. It is very frustrating!
My machine specs are the following:
Windows 7 32-bit
3.24GB RAM
Intel Core 2 Duo 1.86GHz
The compiler has been stuck here for over 10 minutes:
Running build steps for project AppName...
Starting: "c:/nokiaqtsdk/symbian/sdk/bin/qmake.exe" C:/QtProjects/AppName/AppName.pro -r -spec symbian-abld -after OBJECTS_DIR=obj MOC_DIR=moc UI_DIR=ui RCC_DIR=rcc CONFIG+=release
The process "c:/nokiaqtsdk/symbian/sdk/bin/qmake.exe" exited normally.
Starting: "C:/NokiaQtSDK/Symbian/SDK/epoc32/tools/make.exe" release-gcce -w
C:\NokiaQtSDK\Symbian\SDK\epoc32\tools\make.exe: Entering directory `C:/QtProjects/AppName'
bldmake bldfiles
ABLD.BAT build gcce urel
make -r -f "\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\QtProjects\AppName\EXPORT.make" EXPORT VERBOSE=-s
make[1]: Entering directory `C:/QtProjects/AppName'
Nothing to do
make[1]: Leaving directory `C:/QtProjects/AppName'
make -r -f "\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\QtProjects\AppName\GCCE.make" MAKEFILE VERBOSE=-s
make[1]: Entering directory `C:/QtProjects/AppName'
make -s -C \QtProjects\AppName-f "MAKEFILE_0Xe001827C.MK" TO_ROOT=..\.. EPOCBLD=\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\MAKEFILE_0Xe001827C\GCCE TO_BLDINF=..\..\QtProjects\AppNamePLATFORM=GCCE MAKMAKE
perl -S makmake.pl -D \QtProjects\AppName\APPNAME_0Xe001827C GCCE
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(65) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(66) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\sys\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(69) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\oem\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(72) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(73) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(74) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\loc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(76) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\loc\sc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(77) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\middleware\loc\sc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(82) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\stlport\" not found
MMPFILE "\QtProjects\AppName\APPNAME_0Xe001827C .MMP"
I solved the slow compilation problem as indicated by this thread
http://discussion.forum.nokia.com/forum/showthread.php?196650-Selective-compiling&p=720040&viewfull=1#post720040
I added
SYMBIANBUILD_DEPENDENCYOFF = 1
to the project environment variables (or it could be added to Windows environment variables), and the project compilation was back to speed again.
The solution to set the environment variable 'SYMBIANBUILD_DEPENDENCYOFF = 1' as mentioned above also works for us and can result in much quicker Target (GCCE) build times.
However, be aware that you may often need to perform a full (cleaned) re-build of the source if you have modified header files, and specifically added/removed functions for classes and therefore amended the class interface. This is because using this environment variable prevents the Symbian build tools from scanning your include files for changes.
Manually deleting the relevant *.o object files from your QTSDK\Symbian\SDK\epoc32\BUILD_yourfolder_ is a way to prevent the need for a full rebuild but also ensure that affected code is rebuilt.
I believe the slow speed of the Symbian GCCE builds is due to the legacy ABLD build tools, which should be replaced by the Symbian Build System (SBS v2) soon.
I've had trouble with very slow builds due to ZoneAlarm - switching it off resulting in builds 10x quicker... Worth a try if you have an OS firewall installed.
So cool page, the slow building speed in qt creator make me very very very frustrating, I nearly give up the Qt 4.6.3 and 4.7.3, after add the system variable 'SYMBIANBUILD_DEPENDENCYOFF = 1', it is really amazing, speed back, So thanks!
By the way, there is no speed problem in qt 4.7.4 and the compiler use the sbs not the perl any more.