I want to know that how to build Npgsql binaries through Npsql-3.0.3 sources on linux. I don't want to use nuget mechanism to set up Npgsql on linux. Earlier i can see Npgsql.dll with Npgsql-2.2.4.3 sources for MS .net20/35/40/45 versions. So I can use mono to compile/execute my C# code to connect the database with support of Npgsql.dll as like below steps.
$opt/mono/bin/mcs npgsqltest.cs -r:/opt/mono/lib/mono/4.5/System.Data.dll -r:/opt/PostgreSQL/Npgsql/ms.net45/Npgsql.dll
$ /opt/mono/bin/mono npgsqltest.exe
Now I don't see any Npgsql.dll with new 3.0.3 sources, so how can I build binaries through sources on linux.
Please guild me for this if any docs or references available.
Related
I want to run an application based on Qt5 shared objects.
Although I have apt installed qt5-default, qttools5-dev and qttools5-dev-tools I get the error bellow:
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found
I have also tried to change some environment variables as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, resulted in no success!
What do you suggest?
When you built your application, which version of Qt5 did you build against? You can see this in QtCreator by looking at the currently selected kit:
If you just installed QtCreator from binary, it is shipped with it's own set of Qt5 shared libraries that your application is linked against, however your OS' version of those libraries (those installed from apt-get and similar) may not match.
When you try to run the application on it's own outside QtCreator, it may try to link against the OS version of the libs which are usually much older.
There are many ways to resolve this. One way, which would be preferred if you don't care for the newest version of Qt, is simply building towards the Qt libs supploed by the OS. You can do this by creating a new kit that specifies to build against the OS' libraries following this procedure.
Another way is shipping the shared libraries that you used from QtCreator together with the application so that those will override the OS ones. Usually just chucking them into the same folder as the executable will do the trick, as they will be found before the ones under /usr/lib/whatever etc.
Yet another way is to build your own static version of Qt and link with that. This has some benefits and some drawbacks. This is an advanced topic, so I won't go into detail (you can see here). But in this case the Qt libs are built into your app and will not depend on any external Qt libs version.
I am new to buildroot. Using buildroot 2016.05, I have successfully built a target SD card for a MicroZed board with a Xilinx kernel, but it was missing some utilities that I wanted in the root file system. In particular, I wanted scp.
Looking through the buildroot documentation and web searches didn't yield the answer, but I was able to search the Config.in files in the package folders for "scp" and eventually determine that I could install either dropbear or openssh to get scp.
Other than the brute force way I searched Config.in files, is there an approach with buildroot to resolve a "which package produces binary XYZ" question?
A big part of building embedded Linux systems is understanding the components of Linux systems in general. How do you figure out what packages to install on your desktop/server Linux installation? In this way Buildroot isn't really any different. As a help we do sort packages in groups (E.G. Network applications in this case) and provide help text for each package, but you are really expected to know that 'scp' is part of the ssh package (openssh or dropbear).
What can sometimes be helpful is to check what package a program comes from on your desktop Linux installation - E.G. dpkg -S $(which scp) for this question in case you are using Debian/Ubuntu
I'd like to use setcap, part of libcap-bin, on an embedded Linux device. I use buildroot and see that it has the packages libcap and libcap-ng available, but not libcap-bin.
I googled around but cannot find the source for libcap-bin to produce the setcap binary for the ARM target board.
On Ubuntu I just install with:
sudo apt-get install libcap-bin
Where can I get the source and how can I build libcap-bin for my ARM board?
As others have explained: you can't expect a 1:1 match between the packages you're seeing in your Ubuntu/Debian distribution and the packages you're seeing in Buildroot.
Ubuntu/Debian packages take source packages (in this case libcap) and create multiple binary packages from them, in order to allow you to install only the library, or the library + development files, or the library + programs, etc. For example, look at http://packages.ubuntu.com/source/quantal/libcap2, which is the reference page for the libcap2 source package: it gives you the list of binary packages generated in Ubuntu from this source package.
On the other hand, in Buildroot, there is only the concept of source packages. One package in Buildroot == one tarball from a given software component. Therefore, there is only package/libcap. At the moment, package/libcap/libcap.mk is written to only install the library because no-one needed the setcap and getcap programs. But you can extend package/libcap/libcap.mk (and possibly package/libcap/Config.in) to enable the compilation of the programs as well. As another commenter noted, you will need to add attr as a dependency (though the commenter wrongly said that Buildroot didn't had attr: it does have it, see package/attr).
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
I'm trying to install the mod_xsendfile Apache Module on Windows (7) x64 (using Apache 2.2) -- yes I'm doomed from the get-go, I know :-). Apparently there is :
a) No Win x64 binary for mod_xsendfile, just a Win32 binary from the module's website
b) No Win x64 binary for apxs from ApacheLounge
I've tried the usual LoadModule xsendfile_module modules/mod_xsendfile.so but the semi-obvious error (httpd: Syntax error on line 127 of C:/Apache/conf/httpd.conf: Cannot load C:/Apache/modules/mod_xsendfile.so into
server: The specified module could not be found.) occurs, it's not Win x64 compatible.
The question remains -- how does one build the module for x64, is that even possible ? I have VS and any tools that might be required.
I just wanted to see if this would improve my Rails protected attachment download speed - currently getting quite ghastly speeds for simple images.
Thank you in advance !
I'm the author of mod_xsendfile.
I provide win32 binaries only as a courtesy. I still recommend you build yourself from the source. That way you can be sure the binary isn't tampered with, not even by me :p
There are currently no official Win64 Apache2 (or 2.2) builds from the Apache Foundation. Since I test my builds against the official binaries I cannot be sure the binaries will work once the foundation releases official Win64 binaries. Hence no Win64 builds from me
Building from the source is pretty much straight-forward if you aren't novice to (in the Windows case) Visual Studio. The binaries ZIP and/or my github repo contain project files you may import into your Apache solution. I was told even the free Visual Studio Express should be enough to do working builds. The thing is open source.
Should there be unanticipated portability problems, I welcome patches ;)
As a last resort you can still run the official Win32 apache + mod_xsendfile on a Win64 box.
I was able to load mod_xsendfile in my system.
Here's my setup:
-Windows 7 Ultimate x64
-Apache/2.2.9 (installed via Xampp 1.6.7)
Basically, I just downloaded the module from here:
http://www.apachelounge.com/download/mods/mod_xsendfile-0.9-w32.zip
...extracted it to the "modules" directory of apache, added "LoadModule xsendfile_module modules/mod_xsendfile.so" to httpd.conf, then restarted apache.
After this, I checked the loaded modules using phpinfo(), and mod_xsendfile is already available.
Here are the binaries for both x32 and x64
https://github.com/nmaier/mod_xsendfile