I'm trying to use make install, and I get error:
cannot find -lcurses
In my /usr/lib/curses/ I have two files: libcurses.so and libcurses.a.
So I do have that library, gcc just doesn't see it. I've read almost everything I can find but still couldn't make this work.
Any help would be appreciated.
This is output:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'samtools' failed
make: *** [samtools] Error 1
Note: I've read every similar topic on this website, so please, don't mark this as duplicate.
The linker says:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: \
skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
You are performing a 64-bit build, but the the only libcurses.so the linker
can find is 32-bit, so it is skipped.
It is unclear from your several postings how this 32-bit /usr/lib/libcurses.so got
there. The official latest openSUSE
curses runtime package is libncurses5-5.9-53.4.x86_64.rpm. The official latest developent package is ncurses-devel-5.9-53.4.x86_64.rpm.
If you install either of these packages, they do not place any 32-bit binaries under /usr/lib, so I surmise
that your /usr/lib/libcurses.so got there in some unorthodox way.
Delete this /usr/lib/libcurses.so. Install the ncurses-devel rpm from your distribution's package manager,
e.g.zypper install ncurses-devel. To make sure you have done it successfully, check that /usr/lib64/libncurses.so exists afterwards.
Then in your makefile change:
LIBCURSES= -lcurses
to:
LIBCURSES= -lncurses
You will find that this change is described in paragraph 3 of the samtools INSTALL file.
You need a development library for ncurses installed, i.e., ncurses-devel (for SuSE).
Without the development library, the shared libraries for ncurses are only present as runtime files.
The ncurses development package installs files or symbolic links to make these options work: -lcurses, -lncurses (since the former is standard). It also installs the file to make -lncursesw link, but OP is not using that.
That message
skipping incompatible /usr/lib/libcurses.so
makes it seem as if OP copied files from some other system rather than installing OpenSuSE packages.
The extra question in SuperUser (GCC ld: can't find -lcurses) gives more information, but not enough to see why the file /usr/lib/libcurses.so is incompatible. It may be conflicting with the development package, however.
Related
I am trying to install a program and when I run make or make -f Makefile (following the installation instructions) I get the following output:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
dyld: Symbol not found: ___keymgr_global
Referenced from: /usr/local/bin/g77
Expected in: /usr/lib/libSystem.B.dylib
make: *** [prep_output.o] Abort trap: 6
I am working on a macOS Mojave 10.14.6. Following some other proposed solutions in similar problems, I've already installed Command line tools in my Xcode but that didn't do the trick. Any suggestions please??
Thanks in advance
EDIT:
I got rid of g77 and installed a compatible version of gcc (gcc8) through MacPorts. After running the make command I get the following:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
make: g77: No such file or directory
make: *** [prep_output.o] Error 1
So I guess the program still needs the g77 setup? This is the program btw ([http://www.cfht.hawaii.edu/~arnouts/LEPHARE/install.html]). Is there a way to rely to the gfortran compiler for building the program?
Thanks in advance
P.S. I noticed that when I install g77 I get the following error:
x usr/local/: Can't set user=0/group=0 for usr/local`
`tar: Error exit delayed from previous errors.
However it still installs g77..
The error message indicates that your installation of g77 is broken. This has nothing to do with make or the particular project you're trying to build, except inasmuch as the project is trying to use g77 in the first place. That is a bit surprising, actually, since g77 has been obsolete for years (gfortran is the current GNU Fortran compiler), but I'm uncertain what exactly to expect from XCode in this area.
On the other hand, since the full path to the binary is /usr/local/bin/g77, I'm further inclined to think that you're not using XCode for this at all. Possibly you've dumped a g77 built on some other system into your /usr/local/bin, and it's not compatible with your Mojave system.
Your best bet is probably to
Get rid of your broken g77 installation.
Install Fink or MacPorts, or a similar project.
Install the Fink / MacPorts / whatever package for gfortran (maybe gcc-gfortran or similar in some of those) to get a working Fortran compiler.
Rely on that compiler to build your project.
I use lapack in an exact diagonalization program.
Using otool -L V3.e I am told that I have linked to the library "/opt/local/lob/lapack/liblapack.3.dylib". In the very same directory is the library "liblapack.3.8.0.dylib". The implication here is that the latter is a new version of lapack and is therefore desirable.
I can't figure out how to link to one over the other. My current compiler flags for linking to this library is:
-0fast -I$(DIR) -L$(DIR) -llapack
Where $(DIR) is the directory shown above.
I don't have admin permission but can easily ask the person in charge of the MacPorts. So if the its possible to remove one of those libraries I can make that happen.
EDIT: In response to Gavin Portwood.
... -L$(DIR) -llapack3.8
For this one all module files compiled well but the linker failed with the following error:
ld: library not found for -llapack3.8
collect2: error: ld returned 1 exit status
make: *** [V3] Error 1
I tried a variant with 3.8.0 at the end instead of 3.8 and got the same result.
... -L$(DIR) -l:liblapack.3.dylib
Slightly confused about this one since I don't want to use the this library. But with this one I was given the same error as above. If I change it to `l:liblapack.3.8.0.dylib' I get the same error.
... -L$(DIR) /opt/local/lob/lapack/liblapack.3.dylib
This last one didn't give me an error but a warning. The warning is as follows:
warning: /opt/local/lib/lapack/liblapack.3.8.0.dylib: linker input file unused because linking not done
Note that I did correct your typo. The program seems to have run correctly but when I ran otool -L <exe> I was linking to liblapack.3.dylib. Also, my compiler is gfortran.
EDIT2: Directory contents /opt/local/lib/lapack/
cmake libcblas.3.dylib liblapacke.3.8.0.dylib
libblas.3.8.0.dylib libcblas.dylib liblapacke.3.dylib
libblas.3.dylib liblapack.3.8.0.dylib liblapacke.dylib
libblas.dylib liblapack.3.dylib pkgconfig
libcblas.3.8.0.dylib liblapack.dylib
EDITFINAL Turns out the directories were soft linked. See Comments on Gavin's answer.
Depending on your compiler and version, link with one of the following:
... -L$(DIR) -llapack3.8.0
... -L$(DIR) -l:liblapack.3.8.0.dylib
... -L$(DIR) /opt/local/lob/lapack/liblapack.3.8.0.dylib
Pantheios INSTALL.TXT says:
Open a command shell in the appropriate directory that matches your compiler: ...
My compiler is Clang:
> gcc --version
Apple LLVM version 5.1 (clang-503.0.40) ...
Target: x86_64-apple-darwin13.3.0
Which of the compiler settings files in Pantheios 1.0.1-beta214 is the most appropriate?
You can use homebrew to install an older version of gcc (e.g., gcc-4.2) and use the matching Pantheios makefile, like this:
brew install gcc42
make CC=gcc-4.2
However, as far as I have been able to tell, Pantheios is not going to be buildable on a recently-updated system. For example, as of today, building on OSX looks like this:
04:29:23 ~/src/pantheios-1.0.1-beta214/build/gcc42.unix$ make CC=gcc-4.2
Ensuring all STLSoft C source files are in UNIX format
sed: RE error: illegal byte sequence
make: *** [/Users/username/src/stlsoft-1.9.118/include/stlsoft/internal/dos2unix.has.been.performed] Error 1
I have also tried building on Windows as recently as 6 months ago and lost a good bit of time on it before giving up.
The library hasn't been updated in a very long time and the author has very little online activity since then. I call that "abandoned software". Building will very likely require a non-trivial amount of work on your part. I'd highly recommend severing the dependency on STLSoft if you do because it also appears to be abandoned.
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.
I want to build "gcc cross-compiler" to compile "c/c++" applications on "Linux" environment but for "Windows" target.
I have made this so far:
Installed the necessary tools and packages for building GCC listed on "Prerequisites for GCC" page.
Downloaded required sources:
"gcc-core-4.4.1", "gcc-g++-4.4.1", "binutils-2.19.1", "w32api-3.13-mingw32", "mingwrt-3.16-mingw32"
Created this directory hierarchy:
"${HOME}/gcc/" - for final cross-compiler
"${HOME}/src/" - for sources
"${HOME}/src/build-binutils/i386-mingw32/" - for building binutils to "i386-mingw32" target
"${HOME}/src/build-gcc/i386-mingw32/" - for building gcc to "i386-mingw32" target
Builded binutils package:
cd "${HOME}/src/build-binutils/i386-mingw32/"
../../binutils-2.19.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --disable-nls
make
make install
Copied "w32api" and "mingwrt" headers to the install directory:
cp -R "${HOME}/src/w32api-3.13-mingw32/include" "${HOME}/gcc/i386-mingw32"
cp -R "${HOME}/src/mingwrt-3.16-mingw32/include" "${HOME}/gcc/i386-mingw32"
And now when I am trying to build the "c (only) cross-compiler":
cd "${HOME}/src/build-gcc/i386-mingw32/"
../../gcc-4.4.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --enable-languages=c --with-headers="${HOME}/gcc/i386-mingw32/include" --disable-nls
make<br>
it was building something about 4 minutes and then gives me these errors:
${HOME}/gcc/i386-mingw32/bin/ld: dllcrt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[2]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32/i386-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32'
make: *** [all] Error 2
From that error message I really don't know what to do now :-((( .
Does anybody know where is the problem?
Thanks.
That's actually OK: the way things go, you need to
build binutils
install headers
build the a partial C compiler: enough to create object files, but not enough to link
build the win32api and mingw runtime (which includes your missing dllcrt2.o)
build a complete C compiler (and other front-ends, such as C++, Fortran, Ada, whatever, if you want them)
You have successful performed step 3 above; it fails building libgcc (which is a GCC support library), but that means the C compiler core is functionnal (although it won't be able to link, it can still create valid object files). You can check that by looking at the gcc/xgcc file in your GCC build directory.
So, you need to go to the next step, not worrying about your current failure.
(To actuall install the partial C compiler, you should run make with the -k option, to have it do it best, even in the face of errors. For example, use make -k install.)
There are precompiled cross-compilers of MinGW-w64 available.
This allows to compile native 32- and 64-bit Windows binaries from Linux, a two minute tutorial is available at http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/
Just in case you don't want to spend a lot of time trying to build it yourself.
I grepped through the MinGW sources, and found that dllcrt2.o is something built off the mingwrt package. I assume you have to compile and install that, not just copy the headers?