I'm pretty sure it's because I am using t2.nano and not something a little more beefy.
But I have used laravel forge to provision an ec2 server, I can't deploy my application however because I need to install GRPC.
I have followed these instructions: https://cloud.google.com/php/grpc#using-pecl
And when I run: sudo pecl install grpc it runs for around 10 mins and then just gets stuck.
Seems to be running the same thing over and over again, can't quite workout the full stack trace or more importantly where it begins, but I'll post below.
DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX=\"PHP\" -DGRPC_XDS_USER_AGENT_VERSION_SUFFIX=\"1.41.0\" -c /tmp/pear/temp/grpc/src/core/ext/filters/client_channel/channel_connectivity.cc -fPIC -DPIC -o src/core/ext/filters/client_channel/.libs/channel_connectivity.o
/bin/bash /tmp/pear/temp/pear-build-rootRBppUP/grpc-1.41.0/libtool --mode=compile g++ -I. -I/tmp/pear/temp/grpc -I/tmp/pear/temp/pear-build-rootRBppUP/grpc-1.41.0/include -I/tmp/pear/temp/pear-build-rootRBppUP/grpc-1.41.0/main -I/tmp/pear/temp/grpc -I/usr/include/php/20200930 -I/usr/include/php/20200930/main -I/usr/include/php/20200930/TSRM -I/usr/include/php/20200930/Zend -I/usr/include/php/20200930/ext -I/usr/include/php/20200930/ext/date/lib -I/tmp/pear/temp/grpc/include -I/tmp/pear/temp/grpc/src/core/ext/upb-generated -I/tmp/pear/temp/grpc/src/core/ext/upbdefs-generated -I/tmp/pear/temp/grpc/src/php/ext/grpc -I/tmp/pear/temp/grpc/third_party/abseil-cpp -I/tmp/pear/temp/grpc/third_party/address_sorting/include -I/tmp/pear/temp/grpc/third_party/boringssl-with-bazel/src/include -I/tmp/pear/temp/grpc/third_party/re2 -I/tmp/pear/temp/grpc/third_party/upb -I/tmp/pear/temp/grpc/third_party/xxhash -DHAVE_CONFIG_H -std=c++11 -fno-exceptions -fno-rtti -g -O2 -fvisibility=hidden -DOPENSSL_NO_ASM -D_GNU_SOUR
CE -DWIN32_LEAN_AND_MEAN -D_HAS_EXCEPTIONS=0 -DNOMINMAX -DGRPC_ARES=0 -DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX='"PHP"' -DGRPC_XDS_USER_AGENT_VERSION_SUFFIX='"1.41.0"' -c /tmp/pear/temp/grpc/src/core/ext/filters/client_channel/client_channel.cc -o src/core/ext/filters/client_channel/client_channel.lo
libtool: compile: g++ -I. -I/tmp/pear/temp/grpc -I/tmp/pear/temp/pear-build-rootRBppUP/grpc-1.41.0/include -I/tmp/pear/temp/pear-build-rootRBppUP/grpc-1.41.0/main -I/tmp/pear/temp/grpc -I/usr/include/php/20200930 -I/usr/include/php/20200930/main -I/usr/include/php/20200930/TSRM -I/usr/include/php/20200930/Zend -I/usr/include/php/20200930/ext -I/usr/include/php/20200930/ext/date/lib -I/tmp/pear/temp/grpc/include -I/tmp/pear/temp/grpc/src/core/ext/upb-generated -I/tmp/pear/temp/grpc/src/core/ext/upbdefs-generated -I/tmp/pear/temp/grpc/src/php/ext/grpc -I/tmp/pear/temp/grpc/third_party/abseil-cpp -I/tmp/pear/temp/grpc/third_party/address_sorting/include -I/tmp/pear/temp/grpc/third_party/boringssl-with-bazel/src/include -I/tmp/pear/temp/grpc/third_party/re2 -I/tmp/pear/temp/grpc/third_party/upb -I/tmp/pear/temp/grpc/third_party/xxhash -DHAVE_CONFIG_H -std=c++11 -fno-exceptions -fno-rtti -g -O2 -fvisibility=hidden -DOPENSSL_NO_ASM -D_GNU_SOURCE -DWIN32_LEAN_AND_MEAN -D_HAS_EXCEPTIONS=0 -DNOMINMAX -DGRPC_ARES=0 -
DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX=\"PHP\" -DGRPC_XDS_USER_AGENT_VERSION_SUFFIX=\"1.41.0\" -c /tmp/pear/temp/grpc/src/core/ext/filters/client_channel/client_channel.cc -fPIC -DPIC -o src/core/ext/filters/client_channel/.libs/client_channel.o
If there are any logs I can grab please drop the command in to tail or cat and I'll attach them to the question!
Upgrade to a bigger tier than the t2.nano and it should work. I think it's because of the RAM limit. I had the same issue with some instances in Digital Ocean.
Related
I'm trying to install OpenGrm NGram on my Mac, but I'm getting stuck while running make. Specifically, the process gets hung on the following command:
libtool: compile: g++ -DHAVE_CONFIG_H -I./../include -I/usr/local/include/
-std=c++11 -MT hist-arc.lo -MD -MP -MF .deps/hist-arc.Tpo -c hist-arc.cc
-fno-common -DPIC -o .libs/hist-arc.o
I already have OpenFST and Thrax installed.
I have inherited a powerpc project that built fine under a SUSE linux environment back around 2008. My goal is to build the same thing in Linux Mint (v 17). The target processor is a powerpc, which is set in the environment variables, I believe. During the build on Mint linux, it produces the following error:
developer#Will-test-Mint-VM ~/temp/linux.apps $ make -f Makefile.runme
make DESTDIR=`pwd`/tmp install
make[1]: Entering directory `/home/developer/temp/linux.apps'
Making install in libStreamerControl
make[2]: Entering directory `/home/developer/temp/linux.apps/libStreamerControl'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c -o streamerControl.lo streamerControl.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c streamerControl.c -o streamerControl.o
gcc: error: unrecognized command line option '-meabi'
make[2]: *** [streamerControl.lo] Error 1
...
It is complaining about the -meabi option. I have installed/updated some packages that may be relevant (updated versions of eldk-5.6, automake, libtool, and powerpc-linux-gnu-gcc 4.8.2).
Specifically, I would like to know about the -meabi option. I didn't find a lot about it. What could be causing the compiler to not know what it is? I saw the output build from the SUSE setup, and it handled the -meabi option fine. Any suggestions?
Thanks,
Will
From your comment, it sounds like you're cross compiling here (ie., your build architecture is not the same as your host architecture). In this case, your (build) gcc won't recognise -meabi, as it's only valid for the host gcc.
So, you'll need to get your project building with the correct compiler for this to work. The method to do this will depend on the makefiles in your project. You've mentioned ARCH and CROSS_COMPILE, but these variables are specific to the Linux kernel's build system.
At a guess, your makefiles probably use some fairly standard variables to control the choice of compiler & toolchain, like CC, LD, etc. Try something like:
make -f Makefile.runme CC=powerpc-linux-gnu-gcc LD=powerpc-linux-gnu-ld
If your compile still fails, you may need to provide sources (or links to) your Makefiles.
Under GNUStep on Arch Linux, I'm running into an interesting error on a fresh install.
Using my build system I run
gcc `gnustep-config --debug-flags` [other command line args]
in order to build up the command line per the operating system's necessary flags.
This works fine under Ubuntu, but on Arch Linux I'm getting a rather random error:
/usr/include/features.h:328:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
Well, gnustep-config --debug-flags spits out the following:
-MMD -MP -D_FORTIFY_SOURCE=2 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -pthread -fPIC -g -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -march=x86-64 -mtune=generic -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fgnu-runtime -fconstant-string-class=NSConstantString -fexec-charset=UTF-8 -I. -I/home/qix/GNUstep/Library/Headers -I/usr/include -D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include -I/usr/include -I/usr/lib/libffi-3.1/include/ -I/usr/lib/libffi-3.1/include -I/usr/include/libxml2 -I/usr/include/p11-kit-1
As well, I wish not to have optimizations on my debug builds (and later on I even override GNUStep's -g parameter to -g2).
Is there a way to explicitly undefine -D_FORTIFY_SOURCE later on in the command line, after the call to gnustep-config?
For example, something like
gcc `gnustep-config --debug-flags` -U_FORTIFY_SOURCE ...
where the -U undefines the previously defined macro?
Something to mention; I have -Werror enabled on purpose, and I'd like to keep it.
For now, using sed to work around this works. It appears this is a known issue with _FORTIFY_SOURCE causing issues, and there isn't a straightforward fix.
`gnustep-config --debug-flags | sed 's/-D_FORTIFY_SOURCE=2//g'`
I am facing problems on installing perl module UUID-0.05.
$ sudo make
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=\"0.05\" -DXS_VERSION=\"0.05\" -fPIC "-I/usr/lib/perl/5.14/CORE"
UUID.c UUID.xs:5:23: fatal error: uuid/uuid.h: No such file or directory
compilation terminated. make: * [UUID.o] Error 1
See my answer below.
Slaven Rezic,
You are right.
/usr/bin$ apt-file search uuid/uuid.h
libboost1.46-dev: /usr/include/boost/uuid/uuid.hpp
libboost1.46-doc: /usr/share/doc/libboost1.46-doc/HTML/libs/uuid/uuid.html
libboost1.48-dev: /usr/include/boost/uuid/uuid.hpp
libboost1.48-doc: /usr/share/doc/libboost1.48-doc/HTML/libs/uuid/uuid.html
uuid-dev: /usr/include/uuid/uuid.h
this works great. thanks for the info.
I'm working with a tool that is supposed to simplify the build process of Unix-based apps. One of the things it does automatically is run "autoreconf -i" before doing "./configure". However, when it tries to build the expat library on OSX (Lion), the build fails:
$ tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ autoreconf -i
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `conftools'.
glibtoolize: copying file `conftools/ltmain.sh'
glibtoolize: You should add the contents of the following files to `aclocal.m4':
glibtoolize: `/usr/bin/../share/aclocal/libtool.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltoptions.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltversion.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltsugar.m4'
glibtoolize: `/usr/bin/../share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting
config.status: creating expat_config.h
$ make
bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
./libtool: line 473: CDPATH: command not found
./libtool: line 1297: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
On the other hand, if I don't do autoreconf first, it build just fiine:
$ cd ..; rm -r expat-2.0.1; tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h
$ make
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
What is "autoreconf -i" doing, and why is it causing the build to fail?
I think the problem is here:
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
In my experience with OS X Leopard and Snow Leopard (I have not tried Lion yet), the autotools actually installed with OS X are not recent enough to actually reconfigure anything for the system. So I usually grab the latest autotools from a GNU mirror and make a local version of them if I need to reconfigure.
"autoreconf -i" copies files from the installed GNU autotools to AC_CONFIG_AUX_DIR, an in this case is probably ltmain.sh.
A user should never run autoreconf. As ldav1s points out (+1), the autotools installed on your box do not match the tools used to generate the tarball. There are many packages in the wild that recommend (or even require) the user to run autoconf in some form to build the package; those packages are broken. A properly built package should build on a machine that does not have any of the autotools installed, and unless you are a package maintainer you should probably just uninstall them. IMO, they should not be included in default installations.
If you use a package that requires the autotools to build, please report that as a bug to the package maintainer. If a version control system (eg git, hg, svn ) is being used as the distribution mechanism, then you will either need to run the autotools to build the package or the package will have to include autotools generated files in the repository. This is why version control systems should not be used as a distribution tool for packages that use the autotools.