I’ve written a very small application in Go, and configured an AWS Linux AMI to host. The application is a very simple web server. I’ve installed Go on the Linux VM by following the instructions in the official documentation to the letter. My application runs as expected when invoked with the “go run main.go” command.
However, I receive an “Invalid argument” error when I attempt to manually launch the binary file generated as a result of running “go install”. Instead, if I run “go build” (which I understand to be essentially the same thing, with a few exceptions) and then invoke the resulting binary, the application launches as expected.
I’m invoking the file from within the $GOPATH/bin/ folder as follows:
./myapp
I’ve also added $GOPATH/bin to the $PATH variable.
I have also moved the binary from $GOPATH/bin/ to the src folder, and successfully run it from there.
The Linux instance is a 64-bit instance, and I have installed the corresponding Go 64-bit installation.
go build builds everything (that is, all dependent packages), then produces the resulting executable files and then discards the intermediate results (see this for an alternative take; also consider carefully reading outputs of go help build and go help install).
go install, on the contrary, uses precompiled versions of the dependent packages, if it finds them; otherwise it builds them as well, and installs under $PATH/pkg. Hence I might suggest that go install sees some outdated packages which screw the resulting build.
Consider running go install ./... in your $GOPATH/src.
Or may be just selective go install uri/of/the/package for each dependent package, and then retry building the executable.
Related
Environment
I do use CI/CD of gitlab to bundle my application.
I do use node:14-alpine as image and do run yarn to build my app.
After build is finished, I do deploy my app via rsync to the target-server, which run's ubuntu 20.04.
On this server, I do use pm2 to start the app and keep it running.
Issue
If I look into the logs, I do see an error like this:
I've searched a bit, and found that the issue might be caused of musl-dev is missing.
I've installed it at my server, and into the docker-container, but with same result.
BUT, if I do delete the node_modules directory from server, and run yarn install right at the Server, the app run like expected
Question
So why does this issue happens here? Must I have the same distribution & version of linux in my docker-container to fit all dependencies?
Don't use an Alpine image if you're deploying on Ubuntu.
So why does this issue happens here?
The fundamental C standard library implementation is different on the two (Alpine uses musl libc; Ubuntu and more or less all other distros use GNU C Library (glibc)).
Trying to move binaries (such as those that might appear in node_modules for native modules) built against one libc implementation to a system using the other will likely be painful or not work at all (as you noticed).
Must I have the same distribution & version of linux in my docker-container to fit all dependencies?
If none of the dependencies use native code, then you should be able to just move things over without issues, but otherwise it'll be easiest (e.g. considering the versions of other libraries your dependencies may link against) to just use the same version as your target OS – or, if you don't want to think about that, just deploy your application as a Docker container.
Even if the suggestion from #AKX is a good answer, I've played a bit around to figure out how to solve this special case.
Here is my solution:
install musl-dev at the server
link it to /lib
apt-get install musl-dev
ln -s /usr/lib/x86_64-linux-musl/libc.so /lib/libc.musl-x86_64.so.1
In my case it's only this single dependency which cause the trouble. If I got more of this, I will follow AKX's suggestion and choose a debian/ubuntu-like distribution to bundle it.
I'm learning F#, never having used any DotNet nor Mono before. I like the language, but I'm having a hard time with the myriad runtime versions and how to tell the various tools which version to use.
Summary: it appears DLL Hell on Ubuntu is a thing. How can I tell FSAC to run its auto-complete magic against the latest runtime version, namely Microsoft.NETCore.App 2.1.5, instead of whatever older incarnation it decided to use?
Longish explanation.
My platform is Ubuntu 18.04 amd64. I have installed the latest DotNet Core, specifically the packages dotnet-sdk-2.1 (version 2.1.403-1) and its dependencies dotnet-host, dotnet-runtime-2.1, etc. (which are all version 2.1.5-1). I also have Mono installed, because many tools apparently rely on it.
When I try to use some features that were recently added to DotNet Core, it feels like I'm uncovering a Pandora Box.
Take this example, which uses the new ProcessStartInfo.ArgumentList:
#r "System.Diagnostics.Process.dll"
open System.Diagnostics
let execute exe args =
let proc = new Process()
proc.StartInfo.FileName <- exe
for arg in args do proc.StartInfo.ArgumentList.Add arg
proc.Start() |> ignore
proc.WaitForExit()
execute "echo" ["foo"; "baz"]
If I naively try to run it with /usr/bin/fsharpi (which exec's /usr/bin/mono /usr/lib/mono/fsharp/fsi.exe) I get a "ArgumentList is not defined" error. Fair enough, I guess?
If I run it with /usr/bin/dotnet /usr/share/dotnet/sdk/2.1.403/FSharp/fsi.exe it works! It took me a long time to figure out I could even do it, but at last I'm on the right path.
But if I load the file in any IDE, such as VSCode with the Ionide plugin, or Sublime Text with the FSharp plugin, they still flag ArgumentList as invalid. Sublime's plugin also flags the #r line as invalid, but doesn't tell me why.
Focusing on Sublime's plugin and digging into the code, it appears that it relies on a tool called FsAutoComplete aka. fsac and on Linux explicitly invokes it with mono.
I tried running the FSAC tool with DotNet Core, but it fails to find some library or other:
$ cd .config/sublime-text-3/Packages/FSharp/fsac/fsac/
$ dotnet fsautocomplete.exe
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/fsautocomplete.runtimeconfig.json file specifying the appropriate framework.
If I take a filesystem approach and search for System.Diagnostics.Process.dll, I'm baffled by the results:
/usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/microsoft.netcore.app/2.1.0/ref/netcoreapp2.1/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.3/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/linux/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/osx/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Plus another dozen in my home directory, under ~/.nuget. That's insane.
To begin with, the entire /usr/share/dotnet/sdk/NuGetFallbackFolder subtree does not seem to be owned by any Deb package, which is worrisome enough. The others belong to these packages:
mono-devel: /usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
mono-devel: /usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
msbuild: /usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
dotnet-sdk-2.1: /usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
(*) dotnet-runtime-2.1: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Running a simple Grep shows that only the last one marked with (*) knows anything about ArgumentList.
So all these other libraries are older / legacy versions, including the one in dotnet-sdk-2.1 itself.
I can only presume that the SDK, aka. the compilers and interpreters, are built against an older version of the runtime / system libraries than the one they build code against. Which is an interesting choice, to say the least.
Taking a process approach, lsof tells me that the FSAC process has only opened DLL files from inside /usr/lib/mono and from its own local directory. This is not promising.
Is there a way to tell FSAC to use the Microsoft.NETCore.App 2.1.5 runtime / system libraries for its autocomplete and linting work?
Every time I try to build bluez I get the error:
dh_install: libbluetooth3 missing files (usr/lib/*/libbluetooth.so.3), aborting
Looking in my own path I see that the currently installed version of the library is located at:
/usr/lib/x86_64-linux-gnu/libbluetooth.so.3
But the build script (fakeroot debian/rules binary) keeps putting the output into usr/lib/libbluetooth.so.3.
To specify the correct folder you need to declare the environment variable DEB_HOST_MULTIARCH and use the binary-arch target (though binary may suffice as documentation suggests binary calls both binary-arch and binary-indep):
DEB_HOST_MULTIARCH=x86_64-linux-gnu debian/rules binary-arch
The value was chosen based off of the current install path of libbluetooth.so.3 (/usr/lib/x86_64-linux-gnu/libbluetooth.so.3) and could possibly change if the Debian distribution you're running places 64bit binaries elsewhere.
I installed nodejs 64bit on my windows8.
NOTE: By install, I mean I used node-v0.10.35-x64.msi andn its Windows8 for SurfacePro3.
I am not familiar with add PATH. What exactly should add I add and how I run it after I added it?
However, nodejs will not be available outside of its own installation folder.
For example,
if I installed it at /www/test directory, then it will not available either in www or any level after test, like, /www/test/anothertest. Only /www/test will have node running.
I test it by write node -v on /www/test directory in command prompt. I consider its available when it returns me the node version number. When it is not recognized, it will say 'node' is not recognized as an internal or external command...'
I insta
Restart your computer always fix everything....
Yes it did now everything works lol
I am currently trying to run Coverity Prevent and I believe I have everything set up appropriately on my windows 7 build machine. I have run it with AnthillPro and when my code finishes and gets to Coverity it says that everything was built fine and the only error I get is:
Warning: Cygwin pathname conversion ignored; no applicable
'bash'/'mount', 'cygpath', or registry keys found.
I have even tried to install Cygwin to see if this could rectify the problem and I still end up with the same error.
I am currently using AnthillPro 3.7 and Coverity 5.5.3. The build log says that I have warnings but no errors and that it hasn't emitted anything. I have tried to run a script directly from the machine (not server) itself and I have the same error as I do using the Coverity Prevent in Anthill
This is the only information I get at the bottom of the build log.
Run from AnthillPro:
Build time (cov-build overall): 00:00:17.753597
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
d:\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
Run from Script:
The cov-build FAILED.
This may be because less than 90 percent of units were successfully compiled
Check for errors here:
D:\\Coverity\Scripts\build_AllToolsProjects.sln_pc_vs2010.bat
D:\\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
D:\\Coverity\Configuration\pc_vs2010
It sounds like you haven't configured the compiler - that's when you tell your Coverity Analysis installation which compiler you are using. devenv is not a compiler, cl.exe is.
Run the following command:
coverity-analysis-dir/bin/cov-configure --msvc
This will say that you are using the cl.exe compiler and it's of type msvc no matter where it's installed.
Then rerun your Coverity build and see if it captures more of your compilations.