Just wanted to ask regarding Boost, specifically version 1.74, which I currently have as a tar. Does Boost itself has a tool to generate a rpm, or would I need to specifically create a rpm out of the Boost tar? And in either case, how would I go about doing it?
Thanks in advance
My current boost tar is huge, so not using a rpm instead is using up a lot of space
Related
I would like to use pigz to compress massive tar archives.
I am using cygwin. Unfortunately, pigz is not one of the standard cygwin packages.
Anyone know how to install pigz under cygwin?
Below are the 2 techniques I tried without success:
1) The README on this webpage (or in the README file, if you download the source from here) says that you should be able to build it from source merely by
Type "make" in this directory to build the "pigz" executable.
When I do that on my machine, I get a ton of warnings starting with
pigz.c:2950:20: warning: unknown conversion type character 'j' in format [-Wformat=]
(intmax_t)g.in_tot, (intmax_t)len, tag);
and then this final error:
gcc -o pigz pigz.o yarn.o try.o deflate.o blocksplitter.o tree.o lz77.o cache.o hash.o util.o squeeze.o katajainen.o -lm -lpthread -lz
pigz.o:pigz.c:(.text+0xd4f8): undefined reference to `fsync'
collect2.exe: error: ld returned 1 exit status
make: *** [pigz] Error 1
That about exhausts my ability to build programs from source...
2) It looks like there is an old 2015 port of pigz version 2.3.3 to Cygwin Ports, the expanded cygwin package repository.
But that version out of date (the latest pigz is 2.4). Indeed, it looks like Cygwin Ports has migrated to github and searching there for pigz there finds nothing.
I am not even sure how to use Cygwin Ports! The project's homepage merely says
Follow the normal Cygwin installation instructions in order to install
any of the packages currently maintained by this project.
I assume that that means to run cygwin's setup-x86.exe, but when it asks you to "Choose A Download Site" you will need to enter some URL for Cygwin Ports.
Web searching found little information. This link says to use http://sourceware.org/cygwinports/ but setup-x86.exe soon generated an error for that URL. The instructions in this link also did not work for me.
The C99 standard specifies the j specifier for printf(). (Note that the 99 refers to 1999. It is now 2018.) You can force the pigz compilation to not assume C99 by changing __STDC_VERSION__-0 >= 199901L || __GNUC__-0 >= 3 to 0. Then it won't try to use j.
Please let me know what the values of __STDC_VERSION__, __GNUC__, and __GNUC_MINOR__ are for your compiler.
Also pigz requires POSIX compliance, which would provide the fsync() call. You can just delete the reference to fsync(), which would just result in the --synchronous and -Y options having no effect.
To follow up on comments above that I had with #varro and matzeri, I can now answer my own question: my suspicion was correct: RTools was the culprit. I found that if I temporarily removed all RTools elements from my Windows Path env var (for me: c:\Rtools\bin and c:\Rtools\mingw_32\bin), then I was able to get pigz make to work.
After doing this Path edit, I uninstalled my existing cygwin, reinstalled cygwin, installed my usual extra packages (chere, openssh, subversion, zip, unzip) and all their dependencies, installed make and all its dependencies, installed gcc-core (is the C compiler) and all its dependencies. At that point, I was able to make pigz perfectly.
There is a much easier way than compiling yourself. I had the same problem, and with a little bit of research found multiple ready-made .exe files (pigz.exe) for direct usage in Windows. I am using this one:
https://sourceforge.net/projects/pigz-for-windows/files/
The OP's main concern was: "I would like to use pigz to compress massive tar archives.", and I hope that this is a useful answer to that concern, although it does not explain how to get around the compiling problems.
Some additional notes:
The interesting thing that some folks may not be aware of is that nothing keeps us from using normal Windows binaries from within Cygwin, and vice versa. That is, even if the OP had sophisticated Cygwin / bash (or whatever) scripts which drive pigz and the whole process of compressing, he could use the ready-made pigz native Windows version linked above.
With or without Cygwin, there is no need to compile pigz yourself, unless you want the latest features or bug fixes.
Personally, I am using the native Windows pigz version from within Cygwin since a while. AFAIK, pigz has no progress bar, which is somehow inconvenient for me (from time to time I have to compress a single huge file (around 60 GB)). A convenient way to get around this is the pv utility. Since I haven't found a native Windows version of it, and since I am too lazy to compile it for Windows myself, I am using Cygwin's pv to display the progress when I let the native Windows pigz compress those huge files.
I am running some algorithm on my machine that requires a version of glibc 2.14 or above. For computing time improvements, I am migrating my whole code to the clusters of my university. However, the glibc version is 2.12 and they don't want to upgrade it. I am therefore trying to directly install the library on my allocated space and somehow link my algorithm to this library. I downloaded the 2.19 version.
I ran the following lines on my allocated space in the clusters
glibc-2.19/configure --prefix=/
make
make install
and I am facing the following issues when I am running the last command
/usr/bin/install -c -m 644 /home/myusername/libc.a //lib/libc.a
/usr/bin/install: cannot create regular file `//lib/libc.a': Permission denied
it's trying to create a file in a folder where I don't have permission but I don't know how to override that.
Any help is greatly appreciated!
glibc-2.19/configure --prefix=/
This is just wrong. You likely don't understand what --prefix does.
The default prefix is /usr/local. For system GLIBC, the prefix should most often be /usr.
What you likely want is --prefix=/home/$USER/glibc-install or something like that.
You should also read this answer.
Currently used packages in my system are..
buildroot-2011.02
libpng-1.4.5
autoconf-2.65
python-2.7.1
I am trying to upgrade Libpng from version-1.4.5 to version-1.6.8.
But the newer version of Libpng requires Autoconf 2.68 or higher.
If I update Autoconf to 2.68, Python 2.7.1 fails which requires older version of Autoconf.
So I have to update Python to higher version which supports Autoconf 2.68.
But this is creating whole lot of problems for me because Python is used in many other modules which also fails to build.
Other solution I could think is keeping both versions of Autoconf i.e. 2.68 and 2.65
and I have to make sure Libpng uses Autoconf 2.68 and Python uses Autoconf 2.65.
Is it possible to do this? Is there any alternate solution to this problem?
Please try the newest Buildroot version and use BR2_EXTERNAL feature. This way you'll keep your own packages/configuration separately from BR tree. So you can update BR whenever you like and your stuff still will be working.
mkdir /home/user/my_bsp
cd /home/user/
git clone git://git.buildroot.net/buildroot
cd buildroot
make BR2_EXTERNAL=/home/user/my_bsp help
Now your BR tree will be looking for configuration and packages in /home/user/my_bsp
I'm fairly new to linux so when yum install doesn't work, I'm lost. I found some files online for plzip but I don't know how to install the program from those files.
To install plzip you will most likely have to download the source code in tarball, uncompress and compile it. (usually: ./configure; make; make install) but as RHEL is RPM based your life will be much easier (for now) if you stick to what's available in RPM or in fact what was shipped with your distribution.
If I'm not mistaken you want to use multiple threads to compress you data. If you are on RHEL 5 or 6 you should have xz available to you:
yum install xz
From Wikipedia:
XZ Utils (previously LZMA Utils) is a set of free command-line
lossless data compressors, including LZMA and xz, for Unix-like
operating systems and, from version 5.0 onwards, Microsoft Windows.
From man xz
DESCRIPTION
xz is a general-purpose data compression tool with command line syntax similar to gzip(1) and bzip2(1). The native file format
is the .xz format, but also the legacy .lzma format and raw
compressed streams with no container format headers are supported.
In other words this is an implementation of Lempel-Zif-Markov algorithm and by far most popular tool to use it is 7zip. To read more about it you can visit great Wikipedia article: http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm
The other option would be to use pbzip - which is also available in rpm: http://compression.ca/pbzip2/ and by it looks of things it might make it to RHEL one day...
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.