I am trying to add some files to GCC source code, but after running
autoreconf --install --force
i get that error
libtool: definition of this LT_INIT comes from libtool 2.2.7a.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6 Debian-2.4.6-14
libtool: and run autoconf again.
even without any source files added if i reconfigure i get the same error.
that's very important as i am adding new functionality to gcc
Using autoreconf --install --force instead of just autoreconf is a bit questionable in this case, but maybe it's for the best. I am surprised that it did not take care of aclocal.m4 for you automatically, but that's a generated file. If everything else is ok then you ought to be able to simply delete the current aclocal.m4 and run autoreconf to generate a new one.
If you have an autom4te.cache subdirectory then it would probably be best to delete that first (it will be regenerated by autoreconf, too).
Related
I'm trying to compile a package called Kraken on my M1 Mac running Big Sur.
MacOS fails to compile: clang gets upset. I installed gcc from Homebrew (twice) and $ brew doctor says I'm ready to go.
My path is now:
/usr/local/opt/llvm/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/opt/homebrew/bin.
The gcc-11 etc files exist at /opt/homebrew/bin
But /usr/local/bin does not exist!
MacOS does not update the command alias for gcc:
$ rm gcc
then
$ ln -s /opt/homebrew/bin/gcc-11 gcc
return no error
but then
$ which gcc
returns
/usr/bin/gcc
I'm lost and gather this compiler-pointing has been a mess; is there any new insight here? I've seen a bunch of entries but nothing I've tried has worked.
Hoping this is a stupid newbie (me) problem, I thank you for any help you can give.
Michael
Homebrew avoids linking binaries with the same name as system binaries like gcc(appleclang). ln -s /opt/homebrew/bin/gcc-11 /opt/homebrew/bin/gcc or tell your configurator to explicitly use gcc-11 via CC= etc. and the same for g++-11 if C++ is used.
If it's a ./configure script, you can try calling CC=/opt/homebrew/bin/gcc-11 CXX=/opt/homebrew/bin/g++-11 ./configure
if cmake then use cmake .. -DCMAKE_C_COMPILER=/opt/homebrew/bin/gcc-11 -DCMAKE_CXX_COMPILER=/opt/homebrew/gcc++-11
Also, try seeing where the homebrew gcc link points ls -l /opt/homebrew/bin/gcc
I need to compile openssl 1.0.1f version with afl-fuzz and then use it in an application to find heartbleed bug. I have done so far;
Go to openssl1.0.1f directory and run following command
./config CC="afl-gcc" CXX="afl-g++"
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
make && make install
Everything works fine but during compilation I see gcc -I commands compiling files rather than afl-gcc and I donot see Instrumentation details at the end as I see it in simple programs I compile with afl-fuzz. I am not sure openssl has compiled with gcc or afl-gcc. I have also replaced gcc with afl-gcc in Makefile but no result.
Can someone please explain as in all blogs about openssl and afl-fuzz, I have found these commands only.
Thanks.
I was making a simple mistake of calling ./configure after manually making changes to Makefile. Each ./configure command overwrites previous Makefile. So my step should be in following order.
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
Manually replace every occurrence of `gcc`to `afl-gcc` in Makefile
make && make install
Thanks.
Unfortunately I'm forced to use gcc-4.1 and I'm using debian wheezy. Since gcc-4.1 is not in repository I'm trying to build gcc from sources.
But I'm getting compiling error:
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crti.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crtn.o' is incompatible with i386 output
It looks that ld is picking wrong version of libraries, but I checked my /usr/lib32 and /usr/lib/x86_64-linux-gnu/ and it contains those files:
/usr/lib32/libc.a
/usr/lib32/libc.so
/usr/lib32/crtn.o
/usr/lib32/crti.o
/usr/lib/x86_64-linux-gnu/libc.a
/usr/lib/x86_64-linux-gnu/libc.so
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/crti.o
And ld should have access to them
~$ echo $LIBRARY_PATH
/usr/lib/x86_64-linux-gnu:/usr/lib32/
So I have no idea where the problem is.
I managed to work around the problem.
Run configure with:
./configure --disable-multilib ...
But than I encountered another problem with makeinfo, if you have newer version >=4.10 than it might not be found by configure. So simple fix in generated makefile worked for me:
Change this line:
MAKEINFO = /home/lecopivo/Downloads/gcc412/gcc412/gcc-4.1.2/missing makeinfo
To this:
MAKEINFO = makeinfo
I found this helpful.
LD_LIBRARY_PATH is only for running programs already linked.
You probably need to set LDFLAGS when you configure gcc:
./configure LDFLAGS="-L/usr/lib32" .....
It might be LDFLAGS_FOR_HOST or LIBS or something like that though.
I had this problem recently and finally solved it this way:
ln -s /usr/lib32 /usr/lib/i386-linux-gnu
Notes:
I assumed you do not have /usr/lib/i386-linux-gnu directory in your 64bit linux. If this directory exists and is empty, please delete it and make the above link.
If the directory already exists and is not empty, you have to make links inside it for (32bit) libraries which cause build error one by one; e.g.:
ln -s /usr/lib32/crti.o /usr/lib/i386-linux-gnu/crti.o
ln -s /usr/lib32/crtn.o /usr/lib/i386-linux-gnu/crtn.o
...
If 32bit development libraries are not installed, you may have to install them first. I've searched different forums and found that installing following set of packages in ubuntu will provide them:
libc6-dev libc6-dev-i386
gcc-multilib g++-multilib
zlib1g-dev lib32z1-dev
libncurses5-dev lib32ncurses5-dev libncursesw5-dev lib32ncursesw5-dev
Also adjust LD_LIBRARY_PATH and LIBRARY_PATH variables so that they contain /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (i.e. multiarch lib-dirs). I am not sure which one of above variables is effective, so I adjust both of them the same.
If you use ./configure --disable-multilib as it is frequently suggested on web, though gcc will be built, but when you want to use that gcc for compiling e.g. legacy grub, you probably get error of "gcc cannot build executable" (or such).
Optionally, you can make similar linking for these pair of libdirs:
ln -s /lib32 /lib/i386-linux-gnu
Doing so, I managed to compile gcc-3.4.6 in a Ubuntu 16.04.6-amd64 used for compiling old 32bit programs like SDL 1.2 and legacy GRUB4DOS 0.4.4.
Also take a look at my answer to similar (though opposite) error here.
Good luck.
When i use this command pecl install imagick to install imagick for php i got this error message :
libtool: Version mismatch error. This is libtool 2.2.6b, 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.6b
libtool: and run autoconf again.
make: *** [imagick_file.lo] Erreur 63
I found the solution another question with the same error but different application install, but it still not working : libtool version mismatch error
How to fixed this, please ?
This solution seems to fix this problem. Seen in Bug #58979
wget http://pecl.php.net/get/imagick
tar xvzf imagick
cd ./imagick-3.2.0RC1
phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make && make install
There's an ebuild available. I'd give it a try:
$ eix imagick
* dev-php/pecl-imagick
Available versions: 3.0.1-r1 3.1.0_rc2 ~3.1.2 ~3.2.0_rc1 {examples PHP_TARGETS="php5-3 php5-4 php5-5"}
Homepage: http://pecl.php.net/imagick
Description: PHP wrapper for the ImageMagick library.
Look into the gentoo bugzilla if there's a bug report and try not to install packages from outside of portage as it tends to break stuff! Usually there are at least some hacks around to get the ebuild working.
If not, just give it a day or two...
When running configure it fails with
checking for leptonica... yes
checking for pixCreate in -llept... no
configure: error: leptonica library missing
But I have leptonica 1.69 built (downloaded source and ran ./configure && make install)
Edit
I think configure: error: leptonica library missing is a bit misleading, please note that it first says checking for leptonica... yes, and then fails on checking for pixCreate in -llept... no. So maybe the problem is not that the library is missing, but something else.
I finally managed to make it compile, after reading this and this thread. The proper steps for were:
./autogen.sh
export LIBLEPT_HEADERSDIR=/local/include
./configure --with-extra-libraries=/local/lib
make install
for leptonica 1.69, lib renamed to .libs, so, parameters are
export LIBLEPT_HEADERSDIR=<your_path>/leptonica-1.69/src
./autogen.sh
./configure --prefix= --with-extra-libraries=<your_path>/leptonica-1.69/src/.libs
and so on
Maybe this could solve the issue:
export LIBLEPT_HEADERSDIR=/usr-or-other/local/include
I am working on redhat linux 7.2 . None of the solution worked for me I was getting following errors in config.log. Package lept was not found in the pkg-config search path.
Perhaps you should add the directory containing `lept.pc'
to the PKG_CONFIG_PATH environment variable PKG_CONFIG_PATH
configure script uses pkg-config utility to check for packages . It was not able to find lept package ( although i had installed leptonica seperately ) By setting PKG_CONFIG_PATH pointing to the directory where lept.pc is present , i was able to resolve the issue . export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
The FAQ addresses this issue and worked for me with tesseract 3.02.02 on Mac OSX 10.6.8.
Apart from the Leptonica library, png, jpeg, tiff libraries had to passed to the configure script with CXX and CPP flags.
To run configure as non-root -
1. LIBLEPT_HEADERSDIR=; export LIBLEPT_HEADERSDIR;
2. CXXFLAGS="-ltiff -lpng -ljpeg" CPPFLAGS="-ltiff -lpng -ljpeg" ./configure --prefix= --with-extra-libraries=
In my case, this issue was caused by a missing compiler. Searching config.log revealed the following:
./configure:17287: g++ -o conftest -I/Usr/local/include/leptonica -L/usr/local/lib conftest.cpp -llept >&5
./configure: line 2040: g++ command not found
Running apt-get install g++ solved the problem. There is an issue in the tesseract issue tracker about this.
In my case (for Ubuntu/Debian) I downloaded the latest leptonica version and the error was not fixed.
To fix it I removed the package "leptonica-dev" with sudo apt-get remove libleptonica-dev and then tesseract found the leptonica version installed from the source code.
Hope it helps!
The answer is going to be slightly different for everyone, depending on the state of your system.
At a high level, the pkg-config software needs to know that leptonica is installed. It searches paths for a .pc file that has the definition for the leptonica package. That file will be in different locations for different people.
You can find it using the Linux locate utility at the command line. locate lept.pc. (If you've done some recent installing/uninstalling, you may need to refresh the locate utilities database with the command updatedb.)
Whichever directory locate finds the file in, export PKG_CONFIG_PATH as that directory (export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig for example).
Then you can continue your configure/build.
i had a similar problem with trying to compile from source, but did not experience it with
apt-get to install tesseract
sudo apt-get install tesseract-ocr
export LIBLEPT_HEADERSDIR=$dir/letonica168/include
./autogen.sh
./configure --prefix=$anotherdir --with-extra-libraries=/$dir/letonica168/lib
make
make install