Has anyone been able to build NSS statically linked? I actually only need to build certutil and pk12util statically linked. I've seen that Chromium is building NSS statically, and they even have a patch file, but the whole build process is quite involved and I'm just trying to do a small subset. Any help would be greatly appreciated.
As it is right now, NSS cannot be built statically. There is some work in progress in bug 534471 and bug 533014 (NSS and NSPR respectively) but these patches are quite old and likely don't apply any more. It seems that nobody at Mozilla is currently working on this.
As to Chromium, they are using a heavily patched NSS version. Also, they are using GYP to build NSS, not the Makefiles normally supplied with NSS. You could probably build their NSS version but I'm not sure whether it is really useful outside Chrome. The relevant directories are deps/third_party/nss/ and src/net/third_party/nss/, former being NSS without libssl and the latter being libssl only.
Related
I started to learn wxWidgets some days ago and I found it really good, but when I tried to "export" it to another platform, it didn't work. I expected that, but when I searched how to distribute wxWidgets apps, I didn't find that much, except to install all the wxWidgets library on that platform.
I use Debian 10, while the other platform where I need to export my app uses Lubuntu. It says that it needs a wxgtk3.0 library, but I guess that library will need even more libraries.
How do I export my wxWidgets application without asking the user to manually install and build all the library on its platform? Maybe even using .deb package (if really needed). Thanks in advance.
Please understand that every single distribution uses it own format comparing to Windows where there is an Installation Wizard or OSX where there is a Bundle.
Now, you can create a deb file where you set everything up.
So you can create an rpm (which is basically the same thing as deb, just for different distribution).
This is the best way as it ensures that all dependencies and their versions are satisfied.
Hope this helps!
Many Linux distributions have wxWidgets packages, so one possibility would be to simply ask users to install these packages when they need to use your application. This is not really different from installing GTK libraries or even X11 (or Wayland) that your application also depends on -- the only difference is that these libraries are almost surely already installed on any Linux desktop system, while wxWidgets ones might not be.
Another alternative is to link your application statically with wxWidgets libraries. This will make it much bigger and will prevent the users from upgrading the libraries on their system to improve the application behaviour, but can be simpler for the users to install. Note that if you choose the static linking route, you typically need to build your application on the oldest distribution you want to support (which is probably not Debian 10, which is relatively recent), as this is a simple way to ensure that it doesn't require newer versions of the (other, non-wx) libraries than the ones already present on the user's system.
We have Matlab R2017a installed on a RHEL 7.3 machine and I can provide verbose installation instructions if necessary. We have the Matlab library paths saved in /etc/ld.so.conf.d/matlab.conf and have run ldconfig to make sure the paths get picked up. Matlab works and everything is functional. However, Matlab seems to come bundled with it's own versions of libraries such as libstdc++, libicui18n, and others.
I'm trying to build and link a non-Matlab executable with the two libraries mentioned above and it's linking against Matlab's and not the system. How can I tell the linker to use the system provided libraries? I'm pretty sure this isn't a Matlab-specific problem, but that happens to be the environment I'm working in. Any thoughts would be greatly appreciated.
Here is what our /etc/ld.so.conf.d/matlab.conf file looks like. Based on some testing, it does look like all three of these are necessary.
/opt/MATLAB/R2017a/bin/glnxa64
/opt/MATLAB/R2017a/runtime/glnxa64
/opt/MATLAB/2017a/sys/os/glnxa64
There are libraries installed in the runtime that depend on libraries installed in sys/os. The libraries in sys/os are the ones conflicting with the RHEL system libraries (such as libstdc++).
I'm looking to install Hubris for a Ruby-to-Haskell bridge.
Recent install instructions say that I need to enable shared library support in Cabal. Are there reasons why I might not want to do that?
One reason is that when you build binaries using shared Haskell libraries, these are affected by any future breakage of your locally installed Haskell packages. In other words, when you upgrade a library, you will have to either keep the old .so files around or rebuild the program. This is the main reason why Debian is not yet providing -dyn packages for any library besides the set of boot packages.
(The fact that cabal-install does not uninstall stuff helps here a bit, I guess. But nevertheless I prefer not to worry that doing something with cabal-install or in .cabal might break existing programs.
I am building a redistrbutable .so file.
However when my users try to use it they get the dreaded /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.9' not found error.
Doing an objdump, it seems its this particular symbol in my binary that is causing the issue:
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l##GLIBCXX_3.4.9
How do i tell my gcc/g++ to compile/link against an older version of GLIBXX so that my users dont get this error?
Or is the only way out of this conundrum to install a separate older version of linux which has an GLIBXX?
How do i tell my gcc/g++ to compile/link against an older version of GLIBXX so that my users dont get this error?
There is no way to do that. Your only choices are:
build with older g++ version, or
link libstdc++.a statically into your shared library, and hide its symbols (this may also have licensing implications, check with your lawyer).
package your version of libstdc++.so.6 together with your library, and ask users who have an older version to arrange to pick up your newer version instead (also has licensing implications, but I believe these are easier to satisfy).
You are building for GLIBCXX_3.4.9, hence your users also need to have at least GLIBCXX_3.4.9.
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.