I have setup with build directory set to ./bin within source root.
Everything works until I change ./bin to symbolic link.
Then everything configures correctly but make starts complaining about not found source files:
make[2]: *** No rule to make target '../cpp/foo.cpp', needed by 'CMakeFiles/mylib.dir/cpp/foo.cpp.o'.
Why it happens and what could I do about it?
I had idea to convert this path to absolute (inside makefile) and dump it to console in order to figure-out where it points to but it turned out that this "build.cmake" is recreated automatically at every make invocation :(
Thanks to Tsyvarev I realized that it is unmovable OS constraint with potential workaround using mount bind
I needed to do the same on a Mac (to exclude the build directory from iCloud Drive) and had success with executing the cmake-command from the build directory (not going there via link) and giving the absolute path for the source to cmake.
See also: https://stackoverflow.com/a/24435795/4883924
Related
Question
When building Singularity images using definition files, is there a way to specify the path to a file on the host system relative to the definition file (i.e. independent of where the build command is called)?
Example to Illustrate the Problem
I have the following files in the same directory (e.g. a git repository):
foobar.def
some_file.txt
foobar.def looks as follows:
Bootstrap: library
From: ubuntu:20.04
Stage: build
%files
# Add some_file.txt at the root of the image
some_file.txt /some_file.txt
This works fine when I build with the following command in the directory which contains the files:
singularity build --fakeroot foobar.sif foobar.def
However, it fails if I call the build command from anywhere else (e.g. from a dedicated "build" directory) because it searches some_file.txt relative to the current working directory of the build command, not relative to the definition file.
Is there a way to implement the definition file such that the build works independently of where the command is called? I know that I could use absolute paths but this is not a viable solution in my case.
To make it even more complicated: My actual definition file is bootstrapping from another local image, which is located in the build directory. So ideally I would need a solution where some files are found relative the working directory while others are found relative to the location of the definition file.
Short answer: Not really
Longer answer: Not really, but there's a reason why and it shouldn't really matter for most use cases. While Docker went the route of letting you specify what your directory context is, Singularity decided to base all of its commands off the current directory where it is being executed. This also follows with $PWD being auto-mounted into the container, so it makes sense for it to be consistent.
That said, is there a reason you can't run singularity build --fakeroot $build_dir/foobar.sif foobar.def from the repo directory? There isn't any other output written besides the final image and it makes more sense for the directory with the data being used to be the context to work from.
The project is Objective-C based. The project was building previously building successfully, but now when I try to build, I'm getting the above error. I've seen some posts here with similar issues, but those errors specify permissions errors or give messages like 'no such directory', whereas mine does not, and their solutions do not resolve my problem. In fact, the error message I receive has almost no detail at all:
MkDir /[PATH_TO_APP]/[APP_NAME].app (in target '[TARGET]' from project '[PROJECT]')
cd /[PATH_TO_APP]/
/bin/mkdir -p /[PATH_TO_APP]/[APP_NAME].app
error: unable to create directory '/[PATH_TO_APP]/[APP_NAME].app' (in target '[TARGET]' from project '[PROJECT]')
I've also tried the following:
Rename and rebuild the project.
Restarted machine.
Moved the project to a new directory.
Reinstalled Xcode.
Successfully created, built and ran a blank Objective-C app (which makes me think the error is not related to Xcode itself).
Note also that I recently archived and uploaded to the app store; I thought it might be something configuration related that I had forgotten about but haven't been able to locate anything.
Update: After navigating to the project folder in a terminal window and running ls -l command if can see the following for my .app:
[APP NAME].app -> /Users/[ME]/Library/Developer/Xcode/DerivedData/[APP NAME]-goiubutyqcjhzheixixhbodhavhe/Build/Intermediates.noindex/ArchiveIntermediates/[APP NAME]/InstallationBuildProductsLocation/Applications/[APP NAME].app
Note that that location (following the ->) does not exist.
You have a soft link (or symbolic link) where your app folder should be. Delete the soft link.
The following command creates a symbolic link at the command-line interface (shell):
ln -s target_path link_path
target_path is the relative or absolute path to which the symbolic link should point. Usually the target will exist, although symbolic links may be created to non-existent targets. link_path is the path of the symbolic link.
After creating the symbolic link, it may generally be treated as an alias for the target. Any file system management commands (e.g., cp, rm) may be used on the symbolic link. Commands which read or write file contents will access the contents of the target file. The rm (delete file) command, however, removes the link itself, not the target file. Likewise, the mv command moves or renames the link, not the target.
The POSIX directory listing application, ls, denotes symbolic links with an arrow after the name, pointing to the name of the target file (see following example), when the long directory list is requested (-l option). When a directory listing of a symbolic link that points to a directory is requested, only the link itself will be displayed. In order to obtain a listing of the linked directory, the path must include a trailing directory separator character ('/', slash).
— https://en.wikipedia.org/wiki/Symbolic_link
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
I have switched my XCode version from 3.2.6 to 5.1.1, I have been asked to change the project settings and porting to a new format and resolved many compilation errors as well.
Now there is no compilation errors i could able to build my project successfully.
When I tries to sign the project using codesign v2 (mac 10.9.5) i could see the following error
"Abc.app unsealed contents are present in the bundle root"
To Resolve I have gone through the below link and tried to create a bundle structure as mentioned in it, but i'm missing something basically I don't know what it is.
Codesign: What are unsealed contents?
My folder Structure would be similar to below, if anyone has seen discrepancy kindly mention what i need to correct.
/src/Abc/
Abc.xcodeproj
build\
doc\
English.proj
Info.plist
Installer.pmdoc
InstallScripts\
Japanese.lproj\
Libraries\
Abc_Prefix.pch
Abc.pmproj
Package\
Resource\
*.png, *.icns, *.jpg, setting.plist
Source\
Uninstall\
zh_TW.lproj\
In my experience, this error message means I've left some files in the same folder level as the Contents folder.
Everything must be inside the Contents folder.
Try moving whatever files are on the same level as the Contents folder to somewhere inside the Contents folder.
About a week ago I installed golang successfully on my computer and got it's terminal commands to process. So by that, I know go is on my computer.
I have been looking for a good IDE and found https://code.google.com/p/liteide/ LiteIDE which was made specifically for Go.
I read that if you already had go installed on your computer then you could use LiteIDE to start building your code right away. I must have read something wrong some where because I cannot get my projects to build at all. I think it there may be a missing/incorrect path and or something is just setup incorrectly.
This is the error I get in the console:
Current environment change id "win64-user"
C:/go/bin/go.exe env [c:\go]
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GORACE=
set GOROOT=c:\go
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set TERM=dumb
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CXX=g++
set CGO_ENABLED=1
Command exited with code 0.
First_Lite_Go_Proj [C:/go/src/First Litel Go Proj]
Error: process failed to start.
I checked the C:/go directory to make everything there is correct and it was. Also I'm using 64bit windows 7 and double checked that as well.
Any ideas? Mine are: Missing/Incorrect Paths, Can't access a certain directory due to restrictions.
While I have not tested this in Windows 7, on Windows 10, these were the steps that I took to make LiteIDE work
Installed Go to C:\Go
Added C:\Go\bin to PATH and made sure go was working from Command Line
This was the most important step for me. Defined GOPATH in an environment variable. In my case, it was C:\Users\vivek\Documents\Source\Go. I also made sure that there were three folders src, pkg and bin were created in GOPATH. At this point go env was showing me correct values for GOPATH and GOROOT. go get, go build and go install was working as well at this step.
Downloaded and unzipped LiteIDE to C:\liteide. Started LiteIDE and it worked out of the box for me. Make sure that GOPATH is seen correctly by LiteIDE by going to View > Manage GOPATH
Hope this helps. Good luck.
It's not a good idea to keep your projects in the GOROOT path, which per default (when installed using the MSI installer) is C:\Go. Always keep it separated from there. It also helps to avoid issues with updates.
Since Go projects are made up of packages which are organized in directory structures it is important to follow a few rules and keep the working space for your Go projects separated and clean.
In my opinion its best practice to create ONE working directory as the root for ALL your Go projects somewhere in your user space and stick to it.
One way to do this is to create a directory like "work" and set the environment variable GOPATH to it (e.g. C:\Users\Peter\Documents\work). Make sure to relog or restart your computer after your changes.
Upon certain operations Go will automatically create the directories bin, pkg and src below your GOPATH.
src contains your created or downloaded Go source files,
pkg contains your installed package objects, and
bin contains your installed executable files.
bin or pkg will automatically be created when you use the go install command to install a binary executable or a package. It's important to understand that these are files that are not part of the Go installation.
src, if it does not yet exist, will automatically be created the first time you issue a go get command or in case of LiteIDE, the first time you create a new Go1 Command Project or Go1 Package Project. Watch the "Location:" field on the dialog box, it should include your path defined in GOPATH followed by \src (e.g. C:\Users\Peter\Documents\work\src).
In the name field enter the path you want to use for your project. If you plan to track the development of your project on Github (or other repo) it's common practice to include the path to the Git repo in your source path (e.g. github.com/petergloor/hello-go).
Of course you can use any other structure to organize your projects as long you make sure they fall below the src directory in your GOPATH.
For more information about Go workspaces read https://golang.org/doc/code.html#Workspaces.
A final note about the GOROOT environment variable. Dont explicitly set this if you install Go in C:\Go. It's enough to include C:\Go\bin in your path and to set GOPATH. GOROOT is only needed in case Go is installed at another location.
I also had this problem first, but after completing the installation process, I succeeded.
Step 1:
Run (Ctrl+R) -> run target, request build first.
BuildAndRun(Ctrl+F7) -> build and run target
FileRun(Alt+F6) -> go run
step 2:
Check Config via this URL:
https://www.goinggo.net/2013/06/installing-go-gocode-gdb-and-liteide.html
Try setting up the GOROOT to the directory where go was installed. It worked for me.
Do you have 'Install' keyword in your project name? Try remove it.
You have to setup LiteIDE variables correctly (if there are not by default).
Please, check two options:
Go to Settings → "Manage GOPATH"
Options → LiteEnv (there are
environment definitions files). Just double click on someone and
setup Go environment variables.
I'm not sure how this works, but it worked in my case. I got this idea from this video on Youtube-Chris Hawkes
Open LiteIDE.
Click File---New.
Select "Go1 Command Project".
Browse the desired path.
Select the desired folder.
Name the folder and click Ok.
Now, you will be able to see a "main.go" file opened in the IDE.
Write whatever code you want to run in this file with correct syntax, it will run.
The only problem with this is, whenever I create another ".go" source code file in the same folder, the same error is shown. So, you might have to edit this file every time, you try to write new code.