Closed dstern closed 7 years ago
tzwahlen
commented
7 years ago Same problem here :( I'd really appreciate some help.
Plus I already have several versions of libpng installed in various places. I do not get how this ./configure works or what options to use to fix this.
andypohl
commented
7 years ago You can install a library without headers. In linux for example, and let's take RedHat/Centos as a more specific example, separate RPM packaging is done for libraries (usually static and shared) and "devel" libraries, which include the compiled libraries but also have header files. If you have libpng installed in /usr/lib, png.h would be expected to be in /usr/include somewhere. If it's not, "-I" needs to be specified in the CFLAGS. How exactly was libpng installed?
dstern
commented
7 years ago Thanks for your suggestions. I installed libpng from source (libpng-1.6.32) libnpg is installed in /usr/lib and png.h is found in /usr/include
sternd-lm2:~ sternd$ ls /usr/include
libpng16 png.h pngconf.h pnglibconf.h
sternd-lm2:~ sternd$
./configure still fails because can’t find png.h
checking png.h usability... no
checking png.h presence... no
checking for png.h... no
configure: error:
On Sep 20, 2017, at 2:52 PM, Andy Pohl notifications@github.com wrote:
You can install a library without headers. In linux for example, and let's take RedHat/Centos as a more specific example, separate RPM packaging is done for libraries (usually static and shared) and "devel" libraries, which include the compiled libraries but also have header files. If you have libpng installed in /usr/lib, png.h would be expected to be in /usr/include somewhere. If it's not, "-I" needs to be specified in the CFLAGS. How exactly was libpng installed? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/CRG-Barcelona/libbeato","title":"CRG-Barcelona/libbeato","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/CRG-Barcelona/libbeato"}},"updates":{"snippets":[{"icon":"PERSON","message":"@andypohl in #4: You can install a library without headers. In linux for example, and let's take RedHat/Centos as a more specific example, separate RPM packaging is done for libraries (usually static and shared) and \"devel\" libraries, which include the compiled libraries but also have header files. If you have libpng installed in /usr/lib, png.h would be expected to be in /usr/include somewhere. If it's not, \"-I\" needs to be specified in the CFLAGS. How exactly was libpng installed?"}],"action":{"name":"View Issue","url":"https://github.com/CRG-Barcelona/libbeato/issues/4#issuecomment-330946733"}}}
David Stern
Group Leader
Janelia Research Campus
19700 Helix Drive
Ashburn, VA 20147
www.janelia.org/lab/stern-lab
HowToGiveATalk.com
@David_L_Stern
andypohl
commented
7 years ago OK. Maybe recent MacOS updates broke configure somehow. I have MacOS 10.12.6 and I'll try to reproduce the error and fix it. Something like this might be able to be fixed by autoreconf'ing with a newer autotools.
andypohl
commented
7 years ago Maybe try again. I added some ifdefs to the kent code, so hopefully it won't require libpng if it doesn't find it.
tzwahlen
commented
7 years ago Works for me, thanks a lot!
andypohl
commented
7 years ago I'm not sure the best way to get to the bottom of this. When I try:
[laptop:~]$ clang -Wp,-v -E -
clang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.it seems to indicate /usr/include is 4th on the search list. When I do:
[laptop:~]$ cpp -v
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 278.4 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0 -I /usr/include -fdebug-compilation-dir /Users/andy/test/bwtool -ferror-limit 19 -fmessage-length 129 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c -
clang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0
ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.I get more information, including a hint that clang (Apple's LLVM) may be forcefully bypassing /usr/include because it's a so-called duplicate directory.
Something prevented me from installing libpng into /usr myself. I got an error saying it wasn't allowed, despite being an Admin, using sudo. I'm afraid I'm just not an expert about what makes OS X and Linux different from the perspective of installing stuff like this. Sorry, I think there may be permissions differences in our respective setups that I'm hesitant to alter just for the purposes of reproducing the exact problem.
I will mention that what I have noticed is a convention to avoid /usr by OS X-based package managers. Homebrew uses /usr/local, and MacPorts uses /opt/local by default. In Linux, the longstanding convention is to install compiled programs and libraries into /usr/local, while programs and libraries installed by system-level package managers like yum and apt-get will often go into /usr. I think Homebrew avoids /usr because it is not a system-level package manager, and probably considers this Apple's territory in the installation domain.
I don't mean to question the idea of installing into /usr in OS X, I'm just sort of cautioning against it. The default installation path for this library and bwtool is /usr/local, e.g.
[laptop:libbeato]$ ./configure &> /dev/null
[laptop:libbeato]$ grep "^prefix" Makefile
prefix = /usr/local
[laptop:libbeato]$ ./configure --prefix=/usr &> /dev/null
[laptop:libbeato]$ grep "^prefix" Makefile
prefix = /usrI'm not sure I actually like that default for OS X, because on my computer that's Homebrew's place, but I'm under the impression you're overriding the default with --prefix=/usr. If the following doesn't work:
[laptop:compile]$ git clone https://github.com/CRG-Barcelona/libbeato.git
[laptop:compile]$ cd libbeato/
[laptop:libbeato]$ ./configure --prefix=/usr
[laptop:libbeato]$ make
[laptop:libbeato]$ sudo make install
[laptop:libbeato]$ cd ../
[laptop:compile]$ git clone https://github.com/CRG-Barcelona/bwtool.git
[laptop:compile]$ cd bwtool/
[laptop:bwtool]$ ./configure --prefix=/usr CFLAGS="-I/usr/include" LDFLAGS="-L/usr/lib"
[laptop:bwtool]$ make
[laptop:bwtool]$ sudo make installI'm having trouble understanding what could be preventing that.
dstern
commented
7 years ago I too was able to get libbeato installed (I think), but it installed in /usr/local/lib
For bwtool, I was able to get conigure to run with the following flag
./configure LDFLAGS=-L/usr/local/lib
But, this doesn’t compile.
$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in tests
make[2]: Nothing to be done for `all'.
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT aggregate.o -MD -MP -MF .deps/aggregate.Tpo -c -o aggregate.o aggregate.c
aggregate.c:7:10: fatal error: 'jkweb/common.h' file not found
^
1 error generated.
make[2]: *** [aggregate.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
On Sep 21, 2017, at 2:47 PM, Andy Pohl notifications@github.com wrote:
I'm not sure the best way to get to the bottom of this. When I try: [laptop:~]$ clang -Wp,-v -E - clang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0
/usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list.
it seems to indicate /usr/include is 4th on the search list. When I do: [laptop:~]$ cpp -v Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 278.4 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0 -I /usr/include -fdebug-compilation-dir /Users/andy/test/bwtool -ferror-limit 19 -fmessage-length 129 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c - clang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0 ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory
/usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list.
I get more information, including a hint that clang (Apple's LLVM) may be forcefully bypassing /usr/include because it's a so-called duplicate directory. Something prevented me from installing libpng into /usr myself. I got an error saying it wasn't allowed, despite being an Admin, using sudo. I'm afraid I'm just not an expert about what makes OS X and Linux different from the perspective of installing stuff like this. Sorry, I think there may be permissions differences in our respective setups that I'm hesitant to alter just for the purposes of reproducing the exact problem. I will mention that what I have noticed is a convention to avoid /usr by OS X-based package managers. Homebrew uses /usr/local, and MacPorts uses /opt/local by default. In Linux, the longstanding convention is to install compiled programs and libraries into /usr/local, while programs and libraries installed by system-level package managers like yum and apt-get will often go into /usr. I think Homebrew avoids /usr because it is not a system-level package manager, and probably considers this Apple's territory in the installation domain. I don't mean to question the idea of installing into /usr in OS X, I'm just sort of cautioning against it. The default installation path for this library and bwtool is /usr/local, e.g. [laptop:libbeato]$ ./configure &> /dev/null [laptop:libbeato]$ grep "^prefix" Makefile prefix = /usr/local [laptop:libbeato]$ ./configure --prefix=/usr &> /dev/null [laptop:libbeato]$ grep "^prefix" Makefile prefix = /usr
I'm not sure I actually like that default for OS X, because on my computer that's Homebrew's place, but I'm under the impression you're overriding the default with --prefix=/usr. If the following doesn't work: [laptop:compile]$ git clone https://github.com/CRG-Barcelona/libbeato.git [laptop:compile]$ cd libbeato/ [laptop:libbeato]$ ./configure --prefix=/usr [laptop:libbeato]$ make [laptop:libbeato]$ sudo make install [laptop:libbeato]$ cd ../ [laptop:compile]$ git clone https://github.com/CRG-Barcelona/bwtool.git [laptop:compile]$ cd bwtool/ [laptop:bwtool]$ ./configure --prefix=/usr CFLAGS="-I/usr/include" LDFLAGS="-L/usr/lib" [laptop:bwtool]$ make [laptop:bwtool]$ sudo make install
I'm having trouble understanding what could be preventing that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/CRG-Barcelona/libbeato","title":"CRG-Barcelona/libbeato","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/CRG-Barcelona/libbeato"}},"updates":{"snippets":[{"icon":"PERSON","message":"@andypohl in #4: I'm not sure the best way to get to the bottom of this. When I try:\r\n\r\n[laptop:~]$ clang -Wp,-v -E -\r\nclang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0\r\n#include \"...\" search starts here:\r\n#include \u003c...\u003e search starts here:\r\n /usr/local/include\r\n /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include\r\n /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include\r\n /usr/include\r\n /System/Library/Frameworks (framework directory)\r\n /Library/Frameworks (framework directory)\r\nEnd of search list.\r\n\r\nit seems to indicate /usr/include is 4th on the search list. When I do:\r\n\r\n[laptop:~]$ cpp -v\r\nApple LLVM version 8.1.0 (clang-802.0.42)\r\nTarget: x86_64-apple-darwin16.7.0\r\nThread model: posix\r\nInstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin\r\n \"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang\" -cc1 -triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 278.4 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0 -I /usr/include -fdebug-compilation-dir /Users/andy/test/bwtool -ferror-limit 19 -fmessage-length 129 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c -\r\nclang -cc1 version 8.1.0 (clang-802.0.42) default target x86_64-apple-darwin16.7.0\r\nignoring duplicate directory \"/usr/include\"\r\n as it is a non-system directory that duplicates a system directory\r\n#include \"...\" search starts here:\r\n#include \u003c...\u003e search starts here:\r\n /usr/local/include\r\n /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include\r\n /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include\r\n /usr/include\r\n /System/Library/Frameworks (framework directory)\r\n /Library/Frameworks (framework directory)\r\nEnd of search list.\r\n\r\nI get more information, including a hint that clang (Apple's LLVM) may be forcefully bypassing /usr/include because it's a so-called duplicate directory. \r\n\r\nSomething prevented me from installing libpng into /usr myself. I got an error saying it wasn't allowed, despite being an Admin, using sudo. I'm afraid I'm just not an expert about what makes OS X and Linux different from the perspective of installing stuff like this. Sorry, I think there may be permissions differences in our respective setups that I'm hesitant to alter just for the purposes of reproducing the exact problem. \r\n\r\nI will mention that what I have noticed is a convention to avoid /usr by OS X-based package managers. [Homebrew](https://brew.sh/) uses /usr/local, and [MacPorts](https://www.macports.org/) uses /opt/local by default. In Linux, the longstanding convention is to install compiled programs and libraries into /usr/local, while programs and libraries installed by system-level package managers like yum and apt-get will often go into /usr. I think Homebrew avoids /usr because it is not a system-level package manager, and probably considers this Apple's territory in the installation domain.\r\n\r\nI don't mean to question the idea of installing into /usr in OS X, I'm just sort of cautioning against it. The default installation path for this library and bwtool is /usr/local, e.g.\r\n\r\n[laptop:libbeato]$ ./configure \u0026\u003e /dev/null\r\n[laptop:libbeato]$ grep \"^prefix\" Makefile\r\nprefix = /usr/local\r\n[laptop:libbeato]$ ./configure --prefix=/usr \u0026\u003e /dev/null\r\n[laptop:libbeato]$ grep \"^prefix\" Makefile\r\nprefix = /usr\r\n\r\nI'm not sure I actually like that default for OS X, because on my computer that's Homebrew's place, but I'm under the impression you're overriding the default with --prefix=/usr. If the following doesn't work:\r\n\r\n[laptop:compile]$ git clone <a href="https://github.com/CRG-Barcelona/libbeato.git\r\n[laptop:compile]$" class="">https://github.com/CRG-Barcelona/libbeato.git\r\n[laptop:compile]$</a> cd libbeato/\r\n[laptop:libbeato]$ ./configure --prefix=/usr\r\n[laptop:libbeato]$ make\r\n[laptop:libbeato]$ sudo make install\r\n[laptop:libbeato]$ cd ../\r\n[laptop:compile]$ git clone <a href="https://github.com/CRG-Barcelona/bwtool.git\r\n[laptop:compile]$" class="">https://github.com/CRG-Barcelona/bwtool.git\r\n[laptop:compile]$</a> cd bwtool/\r\n[laptop:bwtool]$ ./configure --prefix=/usr CFLAGS=\"-I/usr/include\" LDFLAGS=\"-L/usr/lib\"\r\n[laptop:bwtool]$ make\r\n[laptop:bwtool]$ sudo make install\r\n\r\nI'm having trouble understanding what could be preventing that. \r\n\r\n\r\n\r\n\r\n"}],"action":{"name":"View Issue","url":"https://github.com/CRG-Barcelona/libbeato/issues/4#issuecomment-331247071"}}}
David Stern
Group Leader
Janelia Research Campus
19700 Helix Drive
Ashburn, VA 20147
www.janelia.org/lab/stern-lab
HowToGiveATalk.com
@David_L_Stern
andypohl
commented
7 years ago Did you try
$ ./configure CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib? If you need to set an LD path, you'll probably also have to set an include path. I think you may want to run bwtool through a Docker container instead on installing it. I'll set up an image.
dstern
commented
7 years ago Thanks. That seems to have done the trick.
On Sep 25, 2017, at 12:39 PM, Andy Pohl notifications@github.com wrote:
Did you try $ ./configure CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
? If you need to set an LD path, you'll probably also have to set an include path. I think you may want to run bwtool through a Docker container instead on installing it. I'll set up an image. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/CRG-Barcelona/libbeato","title":"CRG-Barcelona/libbeato","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/CRG-Barcelona/libbeato"}},"updates":{"snippets":[{"icon":"PERSON","message":"@andypohl in #4: Did you try\r\n\r\n$ ./configure CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib\r\n\r\n? If you need to set an LD path, you'll probably also have to set an include path. I think you may want to run bwtool through a Docker container instead on installing it. I'll set up an image."}],"action":{"name":"View Issue","url":"https://github.com/CRG-Barcelona/libbeato/issues/4#issuecomment-331939737"}}}
David Stern
Group Leader
Janelia Research Campus
19700 Helix Drive
Ashburn, VA 20147
www.janelia.org/lab/stern-lab
HowToGiveATalk.com
@David_L_Stern
I'm trying to install libbeato (in prep for bwtools) on Mac 10.12.6. Getting stuck at ./configure
checking png.h usability... no checking png.h presence... no checking for png.h... no configure: error:
Unable to find png.h or libpng for libjkweb.a. Install this and run ./configure with the appropriate LDFLAGS/CFLAGS/etc. See the INSTALL for examples.
I installed libpng on my system (in /usr/lib/), but configure still doesn't recognize it. Do I need to install libpng in a specific location on the system?