End of file/pseudo-op errors compiling MongoDB with SSL - mongodb

I'm currently using MongoDB on Ubuntu 13.10 x64 with the replica set functionality across 3 sites and have gotten to the stage where I need to enable SSL. This requires compiling it myself and sadly I have no prior experience of this which is causing me some headaches.
I'm trying to compile r2.4.9 following the procedure outlined here: http://www.mongodb.org/about/tutorial/build-mongodb-on-linux/
I have installed a ton of packages based on what I found scouring the web for related articles:
git-core build-essential scons devscripts lintian dh-make libpcre3 libpcre3-dev libboost-dev libboost-date-time-dev libboost-filesystem-dev libboost-program-options-dev libboost-system-dev libboost-thread-dev libpcap-dev libreadline-dev libssl-dev rng-tools
I also changed the SConstruct file to remove the CCFLAG -Werror to stop it failing immediately with so many [-Werror=unused-local-typedefs] as mentioned in this question.
The compilation process seems to get quite far but always fails at the same file dbclient_rs.cpp:
g++ -o build/linux2/ssl/mongo/client/dbclient_rs.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -fno-builtin-memcmp -O3 -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -D_FILE_OFFSET_BITS=64 -DMONGO_SSL -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_EXECINFO_BACKTRACE -Ibuild/linux2/ssl/third_party/libstemmer_c/include -Isrc/third_party/libstemmer_c/include -Ibuild/linux2/ssl/third_party/s2 -Isrc/third_party/s2 -Ibuild/linux2/ssl/third_party/boost -Isrc/third_party/boost -Ibuild/linux2/ssl/third_party/pcre-8.30 -Isrc/third_party/pcre-8.30 -Ibuild/linux2/ssl -Isrc -Ibuild/linux2/ssl/mongo -Isrc/mongo -Ibuild/linux2/ssl/third_party/s2 -Isrc/third_party/s2 -Ibuild/linux2/ssl/third_party/snappy -Isrc/third_party/snappy -Ibuild/linux2/ssl/third_party/v8/include -Isrc/third_party/v8/include src/mongo/client/dbclient_rs.cpp
(warning spam removed)
{standard input}: Assembler messages:
{standard input}:73382: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
scons: *** [build/linux2/ssl/mongo/client/dbclient_rs.o] Error 4
scons: building terminated because of errors.
Note: I've also seen pseudo-op errors in the same place, but they were replaced by the above error when I removed the CCFLAG -w in favour of removing Werror instead.
Also just noticed when it starts up and does its checks the line Checking for C library rt... no - could this be a problem?
g++ version is 4.8.1, scons version is 2.3.0
Am I doing something unbelievably stupid here?
Many thanks.

Ok after more searching I found the an explanation of the problem here.
Seems to be related to not having enough RAM for the compilation process. I was running on a 512MB VPS. Worked fine after upgrading to 4GB (also removed the -pipe CCFLAG as suggested).

Related

Error installing postgis with brew

I'm having problems installing postgis using brew. I'm getting the following error(s):
==> Checking out http://svn.osgeo.org/postgis/trunk/
==> ./autogen.sh
==> ./configure --with-projdir=/usr/local --with-jsondir=/usr/local/opt/json-c --with-pgconfig=/usr/local/Cella
==> make
/bin/sh ../../libtool --mode=link clang -g -O2 -fno-common -DPIC -Wall -Wmissing-prototypes -I../rt_core -I../../liblwgeom -I/usr/local/include -I/usr/local/Cellar/gdal/1.11.1_3/include -I/usr/local/Cellar/geos/3.4.2/include ../rt_core/librtcore.a raster2pgsql.o ../../liblwgeom/liblwgeom.la -L/usr/local/Cellar/gdal/1.11.1_3/lib -lgdal -L/usr/local/Cellar/geos/3.4.2/lib -lgeos_c -liconv -lm -o raster2pgsql
libtool: link: cannot find the library `/usr/local/lib/libgeos_c.la' or unhandled argument `/usr/local/lib/libgeos_c.la'
make[2]: *** [raster2pgsql] Error 1
make[1]: *** [rtloader] Error 2
make: *** [all] Error 1
READ THIS: http://git.io/brew-troubleshooting
These open issues may also help:
Postgis sql files not found (https://github.com/Homebrew/homebrew/issues/26604)
I have looked at the suggested issues with no luck. I have also tried to remove and reinstall postgres. Has anyone experienced similar issue and found a solution?
The /usr/local/lib/libgeos_c.la is not ins this location. I have also tried reinstalling gdal and geos using brew.
Postgres.app comes with Postgis baked in. The Postgis folks even recommend it as the best way to get postgis on your mac. http://postgis.net/install/

Installing Bio::DB::Sam perl module

I am trying to install a perl module Bio::DB::Sam on my home directory on a remote server.
I downloaded the module, extracted the files, and ran:
perl Build.pl prefix=~/local
this is what happens next:
This module requires samtools 0.1.10 or higher (samtools.sourceforge.net).
Please enter the location of the bam.h and compiled libbam.a files: **/some_places/samtools-0.1.19**
Found /some_places/samtools-0.1.19/bam.h and /some_places/samtools-0.1.19/libbam.a.
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Bio-SamTools' version '1.39'
Next when I try to run:
./Build
this is what I get:
Building Bio-SamTools
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o blib/arch/auto/Bio/DB/Sam/Sam.so lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o -L/some_places/samtools-0.1.19 -lbam -lpthread -lz
/usr/bin/ld: /some_places/samtools-0.1.19/libbam.a(bgzf.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/some_places/samtools-0.1.19/libbam.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error building blib/arch/auto/Bio/DB/Sam/Sam.so from lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o at ~/perl5/lib/perl5/ExtUtils/CBuilder/Base.pm line 323.
I did google the possible solutions and tried a couple, but they didn't work, e.g. --enable-shared OR export CXXFLAGS="$CXXFLAGS -fPIC".
I have already have Bioperl installed on my home directory.
Any help would be appreciated.
Cheers
Here is a script that will fetch the SAMtools source and compile it, then fetch and compile the Perl bindings.
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
export SAMTOOLS=`pwd`
cpanm Bio::DB::Sam
Part of the problem you were likely seeing is that the SAMtools project has recently undergone some major code reorganization (and this has naturally made it difficult to work with external language bindings).
I fixed this issue by remaking samtools with the -fPIC parameter
make clean
make CXXFLAGS=-fPIC CFLAGS=-fPIC CPPFLAGS=-fPIC
then installed using cpan.
cpan[2]> install Bio::DB::Sam
[Solved]
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
enter cpan in terminal and enter
install Bio::DB::Sam
Be carefully:
You can not use the following command:
perl -MCPAN -Mlocal::lib -e 'CPAN::install(Bio::DB::Sam)'
You can only use cpan and then use
install Bio::DB::Sam
I followed instructions from README file below of Bio-SamTools-1.43 to edit the Makefile in samtools 0.1.17. Then, to install, I used
perl -MCPAN -e shell
install Bio::DB::Sam
README:
This is a Perl interface to the SAMtools sequence alignment
interface. It ONLY works on versions of Samtools up to 0.1.17. It does
not work on version 1.0 or higher due to major changes in the library
structure.
See http://samtools.sourceforge.net/ for samtools documentation.
ONE-STEP INSTALLATION
In the root directory of this distribution you will find the script
INSTALL.pl. Running this will download the latest versions of this
module and SamTools into a temporary directory, compile them, test and
install. Simply run:
perl INSTALL.pl
MULTI-STEP INSTALLATION
The more traditional install requires you to separately download,
unpack and compile SAMtools 0.1.10 through 0.1.17 in some accessible
directory. Typing "make" in the samtools directory will usually
work. SAMtools versions 0.1.18 and higher do not work with this
library.
Then set the environment variable SAMTOOLS to point to this directory.
You will also need to install Bio::Perl from CPAN.
Now run:
perl Build.PL
./Build
./Build test
(sudo) ./Build install
TROUBLESHOOTING:
If you encounter problems during compiling, you may need to edit
Build.PL so that extra_compiler_flags matches the CFLAGS and DFLAGS
settings in the Samtools Makefile. Here are some common problems:
When building this module, you get an error like the following:
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
To fix this, edit the Makefile in the Samtools distribution by adding
"-fPIC" to the CFLAGS line. While you're at it, you may also wish to
get rid of a bunch of unused variable warnings that appears under
recent versions of gcc. The modified CFLAGS will look like this
CFLAGS= -g -Wall -Wno-unused -Wno-unused-result -O2 -fPIC #-m64 #-arch ppc
Then do "make clean; make" in the Samtools directory to recompile the
library. After this you should be able to build this module without
errors.
When building this module, you get an error about a missing math
library.
To fix this, follow the recipe in (1) except add -m64 to CFLAGS so it
looks like this:
CFLAGS= -g -Wall -O2 -fPIC #-m64 #-arch ppc
TESTING AND CONTRIBUTING:
You can obtain the most recent development version of this module via
its GitHub site at https://github.com/GMOD/GBrowse-Adaptors. Please
feel free to submit bug reports, patches, etc. via GitHub.
AUTHOR:
Lincoln D. Stein
Copyright (c) 2009-2015 Ontario Institute for Cancer Research
This package and its accompanying libraries are free software; you can
redistribute it and/or modify it under the terms of the Artistic
License 2.0, the Apache 2.0 License, or the GNU General Public License
(version 1 or higher). Refer to LICENSE for the full license text.

How can I tell a CPAN installation of PDL to use my FFTW path?

I need to install the Perl PDL library via CPAN as the non-root user.
CPAN for non-root works thanks to this SO question: How can I use CPAN as a non-root user?
Now, PDL depends on the FFTW library. Evidently, my sysadmin has the 32-bit version installed when I require the 64-bit for this machine.
I base this on the following error message during the CPAN install:
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic FFTW.o -o ../../blib/arch/auto/PDL/FFTW/FFTW.so \
-lm -L/lib -L/usr/lib -L/usr/local/lib -L/usr/local/lib64 -L/lib64 -L/usr/lib64 -ldfftw -ldrfftw \
/usr/bin/ld: skipping incompatible /usr/local/lib/libdfftw.a when searching for -ldfftw
/usr/bin/ld: skipping incompatible /usr/local/lib/libdfftw.a when searching for -ldfftw
/usr/bin/ld: cannot find -ldfftw
Now I have successfully installed fftw in $HOME/lib, indeed libdfftw.a.
The problem is I can't get this gcc compilation instance to use that locally installed copy.
I have tried the following:
Setting LD_LIBRARY_PATH in .bash_profile, and yes, exporting it -- No dice.
Following How can I set library and include paths for Makefile.PL for a single installation?, I set o conf makepl_arg in cpan to: LIBS=-L/homedir/lib INC=-I/homedir/include -- Still no dice
I did the same as step 2 but for o conf mbuild_arg --- Again, no dice.
None of these attempts had any effect on the gcc line above; there were no additional paths specified with -L flags.
What else can I try in cpan to get this compilation command to reference my copy of fftw?
Update 1
I should add that before I make any changes, makepl_arg is:
makepl_arg [INSTALLDIRS=site]
Hence, I am setting makepl_arg to:
makepl_arg [INSTALLDIRS=site LIBS=-L/homedir/lib INC=-I/homedir/include]
I am setting these configurations without doing o conf commit to permit experimentation. Should I be commiting these changes?
Update 2
I see that those -L flags in the above gcc line are coming from the makefile, which itself seems to be made by MakeMaker which I presume is reading the file 'Makefile.PL'
The solution was to examine the .cpan/build/PDL-*/ directory.
In it the INSTALL file indicates that the perldl.conf file can be modified to indicate paths to FFTW libs and FFTW include directories.
The process is as follows and can be done after a failed attempt at installing PDL:
Copy the .cpan/build/PDL-*/perldl.conf file to ~/.perldl.conf - notice the . being added before the filename - PDL will look for this file when installing, even under CPAN
Modify FFTW__LIBS and FFTW_INC in ~/.perldl.conf to point to the appropriate locations.
Attempt install of PDL again with CPAN.
A bit confusing that PDL does not adhere to the makepl_arg cpan configuration.

XML::Parser refusing to install

I've been trying to install XML::Simple on Ubuntu 12.10 for the past two hours or so and have officially run out of ideas. It's failing at the XML::Parser.
I've done an
sudo apt-get install expat
and it still did not work. Here's the error I've been getting:
make[1]: Entering directory `/home/<user>/.cpan/build/XML-Parser-2.41-MCLo7T/Expat'
cp Expat.pm ../blib/lib/XML/Parser/Expat.pm
/usr/bin/perl /usr/share/perl/5.14.2/ExtUtils/xsubpp -noprototypes -typemap /usr/share /perl/5.14/ExtUtils/typemap -typemap typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c
cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"2.41\" -DXS_VERSION=\"2.41\" -fPIC "-I/usr/lib/perl/5.14/CORE" Expat.c
Expat.xs:12:19: fatal error: expat.h: No such file or directory
compilation terminated.
make[1]: *** [Expat.o] Error 1
make[1]: Leaving directory `/home/sclarawu/.cpan/build/XML-Parser-2.41-MCLo7T/Expat'
make: *** [subdirs] Error 2
TODDR/XML-Parser-2.41.tar.gz
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Seems to be telling me that it's unable to find expat.h, but I'm not sure why or how, considering expat is installed? I tried to apt expat-devel, but it appears not to be a package in apt. Any ideas would be greatly appreciated. :)
EDIT: I seemed to have been simply trying to install the wrong package. -.- It's always the little things. Much thanks to those who answered!
Another way to get to the same information which #Moritz Bunkus has pointed out above.
ubuntu:~$ apt-cache search expat
expat - XML parsing C library - example application
libexpat1 - XML parsing C library - runtime library
libexpat1-dev - XML parsing C library - development kit
The third one in the result set is what you are looking for.
Adding to the other answers, here's how to install the expat dependency on CentOS/RHEL:
yum install expat-devel
You need to install the Expat library and its development headers. For DebUbuntu this means libexpat1-dev as well as those distros often split their libraries into two packages: one for the runtime components (shared libraries, data files, general documentation), one for the development components (static libraries, header files, development documentation).
Just in case, using Debian Jessie I had to install libexpat1-dev by executing apt-get install libexpat1-dev
I only managed to install it by downloading it from cpan and manually editing the Makefile.pl inside to correctly pointing to the EXPATLIBPATH and EXPATINCPATH.
See this post for more detailed instructions.

bugzilla | perl module installation nightmare: no cc, is gcc OK?

I am trying to install Bugzilla. I don't recall it being so difficult. We have a ubuntu server on the cloud, and at first I attempted to install through the rackspace UI. This didn't work, so I ssh'ed in and actually downloaded the tarball to do it the old-fashioned way.
However, it appears there are three perl modules having install problems. I have tried everything I know to get them to install, and am at a loss. I've tried googling for some answers, but I am either not using the correct terminology or this is truly unique to my situation.
The three offending perl modules failing the checksetup.pl:
/usr/bin/perl install-module.pl DateTime
/usr/bin/perl install-module.pl DateTime::TimeZone
/usr/bin/perl install-module.pl Template
When I attempt to install any of them, they fail miserably, apparently because the cc compiler is not installed (see below). When I checked for a cc package under APT, I could only find gcc. Will that be sufficient, and will I need to alias gcc to cc in order for these installs to work?
/usr/bin/perl /usr/local/share/perl/5.10.1/ExtUtils/xsubpp -typemap /usr/share/perl/5.10/ExtUtils/typemap Stash.xs > Stash.xsc && mv Stash.xsc Stash.c
cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"2.22\" -DXS_VERSION=\"2.22\" -fPIC "-I/usr/lib/perl/5.10/CORE" Stash.c
/bin/sh: cc: not found
make[1]: *** [Stash.o] Error 127
make[1]: Leaving directory `/root/.cpan/build/Template-Toolkit-2.22-xzQg_q/xs'
make: *** [subdirs] Error 2
ABW/Template-Toolkit-2.22.tar.gz
/usr/bin/make -- NOT OK
Skipping test because of notest pragma
Running make install
Make had returned bad status, install seems impossible
You shouldn't compile Perl with one compiler (cc) and then compile modules with another compiler or compiler build (gcc) unless you happen to know their compatible. I find it very hard to believe that Ubuntu provided a Perl built with a compiler they don't provide.
Then there's the issue that you're installing unmanaged modules into a distro-managed Perl. That's... less than ideal.
The simplest solution is probably:
apt-get install \
libdatetime-perl \
libdatetime-timezone-perl \
libtemplate-perl
Another solution is to install a local build of Perl, perhaps using perlbrew.
Personally, I never use the system Perl. It's there for the system's needs first (not mine), and that causes problems. In this case, since the distro does provide the packages you need, it should be fine to just install those packages.
Just Install GCC and then Perl.To install the gcc package in the Debian/Ubuntu Linux distribution, enter the following command in a terminal:
> apt-get install gcc make linux-headers-$(uname -r)
I went ahead and installed the gcc package, and the installs completed. Whew. It has been a long time...