Cross compiler:
Sourcery_G++_Lite/bin/arm-none-linux-gnueabi
Autoconfig failed on below checking of "grab the raw symbol name" with arm-none-linux-gnueabi-nm.
checking command to parse /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-nm -B output from arm-none-linux-gnueabi-gcc object... **failed**
Eventually, this caused all checking for symbols failed.
checking for struct dirent.d_type... yes
checking The type of len parameter of gperf hash/lookup function... size_t
checking for FREETYPE... yes
checking for FT_Get_BDF_Property... no
checking for FT_Get_PS_Font_Info... no
checking for FT_Has_PS_Glyph_Names... no
checking for FT_Get_X11_Font_Format... no
checking for FT_Done_MM_Var... no
checking for EXPAT... yes
checking expat.h usability... yes
checking expat.h presence... yes
checking for expat.h... yes
checking for XML_SetDoctypeDeclHandler... no
configure: error:
*** expat is required. or try to use --enable-libxml2
FAILED
libexpat has been cross-compiled and is avaialbe under root/usr/lib, autoconfig cannot detect it properly.
I believe the cross compiler toolchain works well, as it builds all other modules like Freetype, jpeg or png library. fontconfig is the only module that failed so far.
Any clue what can be the possible cause?
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
When I install mysql2 by gem, I encounter some puzzles. I have been beset for 2 days.
I've tried all this command:
gem install mysql2 -v '0.5.1' --source 'https://gems.ruby-china.com/' -- --with-mysql-lib="/usr/lib/mysql"
gem install mysql2 -v '0.5.1' --source 'https://gems.ruby-china.com/' -- --with-mysql-lib="/usr/lib64/mysql"
gem install mysql2 -v '0.5.1' --source 'https://gems.ruby-china.com/'
But all of those return me with the same error which shows below ：
Building native extensions with: '--with-mysql-lib=/usr/lib/mysql'
This could take a while...
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.
current directory: /usr/local/rvm/gems/ruby-2.3.0/gems/mysql2-0.5.1/ext/mysql2
/usr/local/rvm/rubies/ruby-2.3.0/bin/ruby -r ./siteconf20180719-13223-afd0n0.rb extconf.rb --with-mysql-lib=/usr/lib/mysql
checking for rb_absint_size()... yes
checking for rb_absint_singlebit_p()... yes
checking for rb_wait_for_single_fd()... yes
Using mysql_config at /usr/bin/mysql_config
checking for mysql.h... yes
checking for errmsg.h... yes
checking for SSL_MODE_DISABLED in mysql.h... no
checking for MYSQL_OPT_SSL_ENFORCE in mysql.h... no
checking for MYSQL.net.vio in mysql.h... yes
checking for MYSQL.net.pvio in mysql.h... no
checking for MYSQL_ENABLE_CLEARTEXT_PLUGIN in mysql.h... yes
checking for SERVER_QUERY_NO_GOOD_INDEX_USED in mysql.h... yes
checking for SERVER_QUERY_NO_INDEX_USED in mysql.h... yes
checking for SERVER_QUERY_WAS_SLOW in mysql.h... yes
checking for MYSQL_OPTION_MULTI_STATEMENTS_ON in mysql.h... yes
checking for MYSQL_OPTION_MULTI_STATEMENTS_OFF in mysql.h... yes
checking for my_bool in mysql.h... yes
Setting libpath to /usr/lib64/mysql
creating Makefile
current directory: /usr/local/rvm/gems/ruby-2.3.0/gems/mysql2-0.5.1/ext/mysql2
make "DESTDIR=" clean
current directory: /usr/local/rvm/gems/ruby-2.3.0/gems/mysql2-0.5.1/ext/mysql2
make "DESTDIR="
compiling client.c
compiling result.c
compiling statement.c
statement.c: In function 'rb_raise_mysql2_stmt_error':
statement.c:47:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
VALUE rb_error_msg = rb_str_new2(mysql_stmt_error(stmt_wrapper->stmt));
^
statement.c:53:3: warning: ISO C90 forbenter code hereids mixed declarations and code [-Wdeclaration-after-statement]
rb_encoding *default_internal_enc = rb_default`enter code here`_internal_encoding();
^
In file included from ./mysql2_ext.h:39:0,
from statement.c:1:
statement.c: In function 'rb_mysql_stmt_execute':
./client.h:22:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
mysql_client_wrapper *wrapper; \
^
statement.c:261:3: note: in expansion of macro 'GET_CLIENT'
GET_CLIENT(stmt_wrapper->client);
^
statement.c:389:13: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
VALUE rb_val_as_string = rb_funcall(argv[i], intern_to_s, 0);
^
In file included from ./mysql2_ext.h:39:0,
from statement.c:1:
statement.c: In function 'rb_mysql_stmt_fields':
./client.h:22:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
mysql_client_wrapper *wrapper; \
^
statement.c:491:3: note: in expansion of macro 'GET_CLIENT'
GET_CLIENT(stmt_wrapper->client);
^
compiling mysql2_ext.c
compiling infile.c
linking shared-object mysql2/mysql2.so
/usr/bin/ld: cannot find -lmysqlclient
collect2: error: ld returned 1 exit status
make: *** [mysql2.so] Error 1
make failed, exit code 2
Gem files will remain installed in /usr/local/rvm/gems/ruby-2.3.0/gems/mysql2-0.5.1 for inspection.
Results logged to /usr/local/rvm/gems/ruby-2.3.0/extensions/x86_64-linux/2.3.0/mysql2-0.5.1/gem_make.out
and here are all my files about mysql
You are missing mysqlclient.
Try following the steps here: Ruby gem mysql2 install failing
On OSX, try brew install mysql-connector-c
Worst case you may need to uninstall mysql and reinstall it: https://github.com/brianmario/mysql2/issues/687#issuecomment-144811470
I have cross-compiled libpng 1.6.28, libjpeg-turbo 1.5.1 and GLib 2.50.3 for MS Windows with i686-w64-mingw32 on Debian Stretch to a special folder, but still can't get gdk-pixbuf working. My commandline used for configure is:
./configure --host=i686-w64-mingw32 PKG_CONFIG_PATH=/usr/local/mingw32-i686/lib/pkgconfig --prefix=/usr/local/mingw32-i686
It passes the configure part fine, but problems start at making point. It throws the following error:
/usr/local/mingw32-i686/lib/libgio-2.0.a(libgio_2_0_la-giomodule.o): In function `DllMain#12':
/home/maju/GTK-build/glib-2.50.3/gio/giomodule.c:942: multiple definition of `DllMain#12'
./.libs/libgdk_pixbuf-2.0.a(libgdk_pixbuf_2_0_la-gdk-pixbuf-io.o):gdk-pixbuf-io.c:(.text+0x1ca): first defined here
collect2: error: ld returned 1 exit status
Makefile:1859: polecenia dla obiektu 'gdk-pixbuf-csource.exe' nie powiodły się
(last line is just untranslated error message for gdk-pixbuf-csource.exe).
It's also followed by warning messages:
*** Warning: This system cannot link to static lib archive libgdk_pixbuf-2.0.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
for every required library.
Can anyone explain it to me?
the DllMain might mean “glib for doze doesn’t build static right”
this patch
https://lists.fedoraproject.org/pipermail/mingw/2013-March/006441.html
still applies for later versions of glib. lame.
updated version of patch https://bugzilla.redhat.com/show_bug.cgi?id=1306047
https://bugzilla.redhat.com/attachment.cgi?id=1122789 is seemingly final version of that patch, see
https://smani.fedorapeople.org/glib-prefer-constructors-over-DllMain.patch
Not sure about the cannot link, I configure glib for cross compile like --host=i686-w64-mingw32 --prefix=/Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 --disable-shared --enable-static --with-pcre=internal
FWIW
I'm trying to install sia-hsd alarm system,
github link
up to that ./configure output is
Setting top to : /home/siahsd-master
Setting out to : /home/siahsd-master/build
Checking for program gcc,cc : gcc
Checking for program ar : /usr/bin/ar
Checking for program pkg-config : /usr/bin/pkg-config
Checking for 'glib-2.0' : yes
Checking for 'talloc' : yes
Checking for 'tevent' : yes
Checking for 'samba-util' : yes
Checking for 'ndr' : yes
Checking for header stdio.h : yes
Checking for header stdlib.h : yes
Checking for header stdint.h : yes
Checking for header stdbool.h : yes
Checking for header sys/time.h : yes
Checking for header sys/types.h : yes
Checking for header sys/stat.h : yes
Checking for header netinet/in.h : yes
Checking for header arpa/inet.h : yes
Checking for header unistd.h : yes
Checking for header string.h : yes
Checking for header fcntl.h : yes
Checking for header errno.h : yes
Checking for header talloc.h : yes
Checking for header glib.h : yes
Checking for header glibconfig.h : yes
Checking for header dbi/dbi.h : yes
Checking for header util/data_blob.h : yes
Checking for header core/ntstatus.h : yes
Checking for header charset.h : yes
Checking for library dbi : yes
Checking for library talloc : yes
Checking for library ndr : yes
Checking for library gmp : yes
Checking for library hogweed : yes
Checking for library nettle : yes
'configure' finished successfully (2.057s)
output of make "CPP=gcc -E -ffreestanding" command is below
[21/27] cstlib: build/jsonbot.c.7.o -> build/libjsonbot.a
[22/27] cstlib: build/siahs.c.6.o -> build/libsiahs.a
[23/27] cstlib: build/sia.c.5.o -> build/libsia.a
[24/27] cstlib: build/config.c.4.o -> build/libconfig.a
[25/27] cprogram: build/chirond.c.10.o build/ndr_chiron.c.10.o -> build/chirond
[26/27] cprogram: build/siahsd.c.8.o -> build/siahsd
[27/27] cprogram: build/secipd.c.9.o build/crc16.c.9.o build/ndr_secip.c.9.o -> build/secipd
Waf: Leaving directory `/home/siahsd-master/build'
'build' finished successfully (3.389s)
When I'm using the make install command, I got this error :
make: *** No rule to make target `install'. Stop.
Any idea about how to solve it ?
Thanks a lot
As stated, the Makefile doesn't contain a "install" target, thus make does not know how to make it. Taking a look at the waf build file, that doesn't provide any clue on how the install target should be implemented. Apparently installation is not required after building the software, just run it.
You could implement the "dist" target in the Makefile to see what it actually packages. Maybe that provides a hint on what should be installed.
dist:
#bin/waf dist
I am trying to compile phpcompiler from source using this configure command.
./configure --prefix=/opt/phc-0.3.0.1/ --with-php=/opt/php-5.3.17/
The configure error was,
checking for exit in -lboost_regex-mt... no
checking for exit in -lboost_regex-mt... (cached) no
checking for exit in -lboost_regex... no
checking for exit in -lboost_regex... (cached) no
checking for exit in -lboost_regex... (cached) no
configure: error: Could not link against boost_regex
Thats completely wrong as I have both boost and boost_regex packages installed. Both libs and header files. Then I dug this in the config.log file
configure:17053: g++ -o conftest -g -O2 -L/lib/php5 -L/usr/lib/php5 conftest.cpp /usr/lib/libCrun.so.1 -lphp5 -L/opt/php-5.3.17//lib -R/opt/php-5.3.17//lib -ldl >&5
g++-4.6.real: error: /usr/lib/libCrun.so.1: No such file or directory
g++-4.6.real: error: unrecognized option '-R'
So, for this unrecognized option '-R' error, many -lboost_regex checks were failed!
How can I fix this? is there any file that I can edit to fix it? And why -R is used? I think it would be -L flag.
As your comment indicates that this -R option comes from configure, the following line in m4/php-embed.m4 appears to be the most likely source:
LIBS="-lphp5 -L${PHP_INSTALL_PATH}/lib -R${PHP_INSTALL_PATH}/lib $LIBS"
If you look at configure, all other occurrences of -R will write that as ${wl}-R, where ${wl} will most likely expand to -Wl,. So one way to fix this would be adding the ${wl} before -R in the above line and running autogen.sh to recreate configure.
You may whish to file a bug for this, after checking existing ones.
You can see a similar error (and resolution) in Git 2.23 (Q2 2019) where -R has been removed.
The way of specifying the path to find dynamic libraries at runtime
has been simplified.
The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses.
See commit 0f50c8e (17 May 2019) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 51d6c0f, 13 Jun 2019)
Makefile: remove the NO_R_TO_GCC_LINKER flag
Change our default CC_LD_DYNPATH invocation to something GCC likes
these days.
Since the GCC 4.6 release unknown flags haven't been passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set.
Our use of "-R" dates back to 455a7f3 ("More portability.",
2005-09-30, Git v0.99.8a).
Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27, Git v1.5.0-rc1) the NO_R_TO_GCC flag was added, allowing optional use of "-Wl,-rpath=".
Then in f5b904d ("Makefile: Allow CC_LD_DYNPATH to be overriden",
2008-08-16, Git v1.6.1-rc1) the ability to override this flag to something else
entirely was added, as some linkers use neither "-Wl,-rpath," nor "-R".
From what I can tell we should, with the benefit of hindsight, have
made this change back in 2006.
GCC & ld supported this type of invocation back then, or since at least binutils-gdb.git's.
a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20).
Further reading and prior art can be found at:
tsuna/boost.m4 issue 15
Gnome issue 641416
Building cURL passing the -R option to linker
Making a plain "-R" an error seems from reading those reports to have been
introduced in GCC 4.6 released on March 25, 2011, but I couldn't
confirm this with absolute certainty, its release notes are ambiguous
on the subject, and I couldn't be bothered to try to build & bisect it
against GCC 4.5.
I am having a bear of a time getting autoconf to check for the presence of a particular header file.
Let's call the header dependency "inky.h", and let's say that inky is a library that was installed (seperately) with the prefix set to "/usr/local". This put "inky.h" in /usr/local/inky/inky.h and libinky.so in /usr/local/lib.
Now, I'm trying to verify the presence of inky.h in my applications configure.ac as follows:
dnl # Setup temp LDFLAGS and look for inky library/header
LDFLAGS_SAVE=${LDFLAGS};
CPPFLAGS_SAVE=${CPPFLAGS};
dnl # Look for inky on the user specified inky install path
LDFLAGS ="-L${inky_library_path}";
CPPFLAGS="-I${inky_include_path}/inky";
AC_MSG_NOTICE([Looking for inky.h using: ${CPPFLAGS}]);
dnl # This check finds inky.h just fine. This check was only used for debugging
AC_CHECK_FILE(
[${inky_include_path}/inky/inky.h],
[AC_MSG_NOTICE([Found inky.h])],
[AC_MSG_NOTICE([Didn't find inky.h])]
)
dnl # Look for the inky header file. If it isn't found, terminate.
AC_CHECK_HEADER(inky.h,
[],
[AC_MSG_ERROR([Couldn't find or include inky.h])]
)
This produces the following output from ./configure (after an autoreconf -vfi):
configure: Looking for inky.y in fetk include path: -I/usr/local/include/inky.y
checking for /usr/local/include/inky/inky.h... yes
configure: Found inky.h
checking inky.h usability... no
checking inky.h presence... yes
configure: WARNING: inky.h: present but cannot be compiled
configure: WARNING: inky.h: check for missing prerequisite headers?
configure: WARNING: inky.h: see the Autoconf documentation
configure: WARNING: inky.h: section "Present But Cannot Be Compiled"
configure: WARNING: inky.h: proceeding with the compiler's result
checking for inky.h... no
configure: error: Couldn't find or include inky.h
Now, this appears to be the case because inky.h includes 2 other headers, so I add them in on the fourth parameter of AC_CHECK_HEADER like so:
dnl # Look for the inky header file. If it isn't found, terminate.
AC_CHECK_HEADER(inky.h,
[],
[AC_MSG_ERROR([Couldn't find or include inky.h])],
[dinky.h plinky.h]
)
Which renders this output from ./configure:
configure: Looking for inky in fetk include path: -I/usr/local/include/inky
checking for /usr/local/include/inky/inky.h... yes
configure: Found inky.h
checking for inky.h... no
configure: error: Couldn't find or include inky.h
I'm at my wits end with autoconf. Does anyone have any idea where I'm going wrong here. Is it possible to get configure to provide more details about what is failing? Why can I find the file itself, but the AC_CHECK_HEADER macro fails?
Also, please don' tell me to use a different package distribution suite. I would never have chosen Autoconf myself, but I do have to add some dependencies to a pre-existing project.
Also note that the actual library is not named "inky." However, there is an issue of "official use only" for this project, so I have changed the names to protect the...well, to protect myself!
[Edit - Closing]
Figured out the problem. See my answer.
I found what the issue was. The library that I am working with is a C library, but the "inky" library that I am linking against is a C++ library. So, the language (AC_LANG) was set to C early in the configure.ac script. While performing checks for "inky", I needed to change the language to C++ so that Autoconf used the C++ compiler instead of the C compiler. This was done rather easily by using:
AC_LANG_PUSH([C++])
dnl # Do the checks for inky
AC_LANG_POP([C++])
This solved both the problem that I asked about in this thread, and on that I hand't posted yet wherein I couldn't get the AC_CHECK_LIB macro to work.
Thank you everyone for your input.
The fourth argument of AC_CHECK_HEADER is not a list of headers, but some C code that performs the include.
Maybe try something along the line of
AC_CHECK_HEADER([inky.h],
[],
[AC_MSG_ERROR([Couldn't find or include inky.h])],
[#include <dinky.h>
#include <plinky.h>
])
or even
AC_CHECK_HEADERS([dinky.h plinky.h inky.h],
[],
[AC_MSG_ERROR([Couldn't find or include this header])],
[#if HAVE_DINKY_H
# include <dinky.h>
#endif
#if HAVE_PLINKY_H
# include <plinky.h>
#endif
])
The details about why this test is failing are in config.log. My guess is though, that:
Since you're not adding the path found with AC_CHECK_FILE to CPPFLAGS or INCLUDES or whatever autoconf is using these days.
AC_CHECK_HEADER does not find the header using preprocessor compilation (for another reason than the header being missing in CPPFLAGS includes).