Re: [Fink-users] Problem compiling Python 2.6
On 2/15/13 5:04 PM, Robert Jansen wrote: > Error message on OS X 1.7 with Xcode 4.6: > .. snip > > > > /sw/include/ncursesw/ncurses.h:209:34: note: expanded from macro > 'NCURSES_CAST' > #define NCURSES_CAST(type,value) (type)(value) > ^ > 1 warning generated. > ld: warning: directory not found for option '-L/usr/X11R6/lib64' > > Failed to find the necessary bits to build these modules: > bsddb185 dl imageop > linuxaudiodev ossaudiodevspwd > sunaudiodev > To find the necessary bits, look in setup.py in detect_modules() for > the module's name. > (Fink package build should have 7 missing) > > > Failed to build these modules: > readline > > make: *** [sharedmods] Error 1 > ### execution of /tmp/fink.MEabl failed, exit code 2 > ### execution of /tmp/fink.fG47z failed, exit code 2 > Removing runtime build-lock... > Removing build-lock package... > /sw/bin/dpkg-lockwait -r fink-buildlock-python26-2.6.8-2 > (Reading database ... 46031 files and directories currently installed.) > Removing fink-buildlock-python26-2.6.8-2 ... > Reading buildlock packages... > All buildlocks accounted for. > /sw/bin/dpkg-lockwait -i > /sw/fink/dists/stable/main/binary-darwin-x86_64/libs/libffi_3.0.9-5_darwin-x86_64.deb > Selecting previously deselected package libffi. > (Reading database ... 46030 files and directories currently installed.) > Unpacking libffi (from .../libffi_3.0.9-5_darwin-x86_64.deb) ... > Setting up libffi (3.0.9-5) ... > Clearing dependency_libs of .la files being installed > * libffi: (libffi). Portable foreign-function interface library. > install-info(/sw/share/info/libffi.info): creating new section > `Development' > > Failed: phase compiling: python26-2.6.8-2 failed > > Before reporting any errors, please run "fink selfupdate" and try > again. > Also try using "fink configure" to set your maximum build jobs to 1 and > attempt to build the package again. > If you continue to have issues, please check to see if the FAQ on > Fink's > website solves the problem. If not, ask on one (not both, please) of > these mailing lists: > > The Fink Users List > The Fink Beginners List , > > with a carbon copy to the maintainer: > > Daniel Macks > > Note that this is preferable to emailing just the maintainer directly, > since most fink package maintainers do not have access to all possible > hardware and software configurations. > > Please try to include the complete error message in your report. This > generally consists of a compiler line starting with e.g. "gcc" or "g++" > followed by the actual error output from the compiler. > > Also include the following system information: > Package manager version: 0.34.5 > Distribution version: selfupdate-rsync Sat Feb 16 00:55:55 2013, 10.7, > x86_64 > Trees: local/main stable/main stable/crypto unstable/main > unstable/crypto local/injected > Xcode.app: 4.6 > Xcode command-line tools: 4.5.0.0.1.1249367152 > Max. Fink build jobs: 8 > > Any ideas ? > > > TIA > > Robert > You've got a mismatched Xcode.app and command-line tools, but that's not the problem. You snipped out the actual error, which is: ... gcc -L/sw/lib/system-openssl/lib -L/sw/lib -o python \ Modules/python.o \ libpython2.6.dylib -ldl -Wl,-framework,CoreFoundation /sw/src/fink.build/python26-2.6.8-2/Python-2.6.8/Modules/datetimemodule.c:616:19: warning: expression result unused [-Wunused-value] PyObject_INIT(self, type); ~~^~~ /sw/src/fink.build/python26-2.6.8-2/Python-2.6.8/./Include/objimpl.h:157:69: note: expanded from macro 'PyObject_INIT' ( Py_TYPE(op) = (typeobj), _Py_NewReference((PyObject *)(op)), (op) ) ^ /sw/src/fink.build/python26-2.6.8-2/Python-2.6.8/Modules/datetimemodule.c:631:19: warning: expression result unused [-Wunused-value] PyObject_INIT(self, type); ~~^~~ /sw/src/fink.build/python26-2.6.8-2/Python-2.6.8/./Include/objimpl.h:157:69: note: expanded from macro 'PyObject_INIT' ( Py_TYPE(op) = (typeobj), _Py_NewReference((PyObject *)(op)), (op) ) ^ 2 warnings generated. ld: warning: directory not found for option '-L/usr/lib/termcap' ld: in /usr/lib/libncurses.5.dylib, file was built for unsupported file format ( 0xce 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 0 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): /usr/lib/libncurses.5.dylib for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) This is something for the maintainer to fix. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ --
[Fink-users] Problem compiling Python 2.6
Error message on OS X 1.7 with Xcode 4.6: .. snip /sw/include/ncursesw/ncurses.h:209:34: note: expanded from macro 'NCURSES_CAST' #define NCURSES_CAST(type,value) (type)(value) ^ 1 warning generated. ld: warning: directory not found for option '-L/usr/X11R6/lib64' Failed to find the necessary bits to build these modules: bsddb185 dl imageop linuxaudiodev ossaudiodevspwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. (Fink package build should have 7 missing) Failed to build these modules: readline make: *** [sharedmods] Error 1 ### execution of /tmp/fink.MEabl failed, exit code 2 ### execution of /tmp/fink.fG47z failed, exit code 2 Removing runtime build-lock... Removing build-lock package... /sw/bin/dpkg-lockwait -r fink-buildlock-python26-2.6.8-2 (Reading database ... 46031 files and directories currently installed.) Removing fink-buildlock-python26-2.6.8-2 ... Reading buildlock packages... All buildlocks accounted for. /sw/bin/dpkg-lockwait -i /sw/fink/dists/stable/main/binary-darwin-x86_64/libs/libffi_3.0.9-5_darwin-x86_64.deb Selecting previously deselected package libffi. (Reading database ... 46030 files and directories currently installed.) Unpacking libffi (from .../libffi_3.0.9-5_darwin-x86_64.deb) ... Setting up libffi (3.0.9-5) ... Clearing dependency_libs of .la files being installed * libffi: (libffi). Portable foreign-function interface library. install-info(/sw/share/info/libffi.info): creating new section `Development' Failed: phase compiling: python26-2.6.8-2 failed Before reporting any errors, please run "fink selfupdate" and try again. Also try using "fink configure" to set your maximum build jobs to 1 and attempt to build the package again. If you continue to have issues, please check to see if the FAQ on Fink's website solves the problem. If not, ask on one (not both, please) of these mailing lists: The Fink Users List The Fink Beginners List , with a carbon copy to the maintainer: Daniel Macks Note that this is preferable to emailing just the maintainer directly, since most fink package maintainers do not have access to all possible hardware and software configurations. Please try to include the complete error message in your report. This generally consists of a compiler line starting with e.g. "gcc" or "g++" followed by the actual error output from the compiler. Also include the following system information: Package manager version: 0.34.5 Distribution version: selfupdate-rsync Sat Feb 16 00:55:55 2013, 10.7, x86_64 Trees: local/main stable/main stable/crypto unstable/main unstable/crypto local/injected Xcode.app: 4.6 Xcode command-line tools: 4.5.0.0.1.1249367152 Max. Fink build jobs: 8 Any ideas ? TIA Robert -- -- Brussels University Pleinlaan 2 Computer Center VUB/ULB (VUBnet) Ing. Robert Jansen B-1050 Brussels Belgium (Europe) email: rjan...@vub.ac.be Tel: +32-2-650.36.94 Secr: +32-2-650.37.38 Fax: +32-2-650.37.40 -- -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On Sat, Feb 16, 2013 at 12:49:44AM +0100, Martin Costabel wrote: > On 15/02/13 15:20, Jack Howarth wrote: > [] >> This bug is quite bizarre. It is still quite unclear why removing >> -Wl,-search_paths_first had any impact as the linker >> in Xcode 4 is supposed to be defaulting to this option already. Also, this >> problem was entirely reproducible earlier. >> Now if I build packaging with the hack omitted for adding -L%p/lib, the >> problem doesn't reoccur. > > Do you have ccache-default installed? This kind of behavior smells of > ccache, although I don't quite see how it could get into this state in > the first place. Martin, Yes. I suspect it got on my machine from testing fangism's llvm32 packaging. Did any one check with the original reporter of this issue to see if he had ccache installed? If so, we probably should just BuildConflicts: ccache like we do in gettext.info. Jack > > -- > Martin > -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On 15/02/13 15:20, Jack Howarth wrote: [] > This bug is quite bizarre. It is still quite unclear why removing > -Wl,-search_paths_first had any impact as the linker > in Xcode 4 is supposed to be defaulting to this option already. Also, this > problem was entirely reproducible earlier. > Now if I build packaging with the hack omitted for adding -L%p/lib, the > problem doesn't reoccur. Do you have ccache-default installed? This kind of behavior smells of ccache, although I don't quite see how it could get into this state in the first place. -- Martin -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On 14/02/13 23:23, Martin Costabel wrote: [] > Pure voodoo. It is inoffensive (a no-op), so if it contributes to > someone's peace of mind, leave it there. OK, I take this back, after the new thread on -beginners: Voodoo *can* be harmful. It is not quite a no-op. -- Martin -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On Fri, Feb 15, 2013 at 10:58:57AM +0100, Peter Dyballa wrote: > > Am 15.02.2013 um 09:09 schrieb Martin Costabel: > > > It is an indication that at that time, the header file /sw/include/iconv.h > > was not included correctly. > > GCC offers -idirafter. The argument following, a directory with C header > files, is then searched last. Using > > -idirafter /usr/include > > should guarantee that the system's iconv.h is not used when Fink's version of > this file exists. This worked well quite a few times for me. > > Besides, adding -H to CPPFLAGS or CFLAGS should reveal which header file is > actually used during compilation. This bug is quite bizarre. It is still quite unclear why removing -Wl,-search_paths_first had any impact as the linker in Xcode 4 is supposed to be defaulting to this option already. Also, this problem was entirely reproducible earlier. Now if I build packaging with the hack omitted for adding -L%p/lib, the problem doesn't reoccur. > > -- > Greetings > > Pete > > If all else fails read the instructions. > - Donald Knuth -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On Fri, Feb 15, 2013 at 09:09:51AM +0100, Martin Costabel wrote: > On 15/02/13 01:06, Jack Howarth wrote: > [] >> On x86_64 10.6 fink, I ran into the following build failure... >> >> /usr/bin/make -f Makefile.doxygenPERL=/usr/bin/perl all >> c++ -c -pipe -D__FreeBSD__=6 -DYY_TYPEDEF_YY_SIZE_T -Dyy_size_t=int -Wall -W >> -Wno-deprecated-declarations -O2 -I../qtools -I../libmd5 -I. -I/sw/include >> -o ../ >> objects/main.o main.cpp >> c++ -Wl,-search_paths_first -o ../bin/doxygen ../objects/main.o -L../lib >> -L/sw/lib -ldoxygen -ldoxycfg -lqtools -lmd5 -lpthread -liconv -framework >> CoreServic >> es >> Undefined symbols for architecture x86_64: >>"_iconv_open", referenced from: >>_portable_iconv_open in libdoxycfg.a(portable_c.o) > > You see that -L/sw/lib is already on the linker line. The error is not > in some dylib or other, it is that the linker is asked to resolve the > symbol "_iconv_open" and not, as it should be, "_libiconv_open". This > mistake happened at the compilation of portable_c.c. It is an indication > that at that time, the header file /sw/include/iconv.h was not included > correctly. Now why this should have been the case is not clear. > [] >> I initially worked around that by changing doxygen.patch from... > > By "worked around", you mean when you did not do this, you got the error > reproducibly, and when you did it, you did not get the error? > By worked around, I mean that dropping the "-Wl,-search_paths_first" flag was sufficient to eliminate the linkage error. >> @@ -36,7 +36,7 @@ >> >> TMAKE_LINK = c++ >> TMAKE_LINK_SHLIB = c++ >> -TMAKE_LFLAGS = -Wl,-search_paths_first -arch i386 -arch ppc >> +TMAKE_LFLAGS = -Wl,-search_paths_first -arch @FINK_ARCH@ >> TMAKE_LFLAGS_RELEASE = >> TMAKE_LFLAGS_DEBUG = >> TMAKE_LFLAGS_SHLIB = -shared >> >> to >> >> @@ -36,7 +36,7 @@ >> >> TMAKE_LINK = c++ >> TMAKE_LINK_SHLIB = c++ >> -TMAKE_LFLAGS = -Wl,-search_paths_first -arch i386 -arch ppc >> +TMAKE_LFLAGS = -arch @FINK_ARCH@ >> TMAKE_LFLAGS_RELEASE = >> TMAKE_LFLAGS_DEBUG = >> TMAKE_LFLAGS_SHLIB = -shared > > The -Wl,-search_paths_first is employed because the static libs > ../libdoxycfg.a etc that were just built are being used for linking. > When -Wl,-search_paths_first is not there, then any old libdoxycfg.dylib > that might be found anywhere, for example in /usr/local/lib, would take > precedence. According to the error message, this was not the case here, > however. So it is not clear how this could have had any effect. > >> which led me to search for other instances of this failure. I found MacPort's >> hack which solved the problem without changing the doxygen.patch. >> Jack > > -- > Martin > -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
Am 15.02.2013 um 09:09 schrieb Martin Costabel: > It is an indication that at that time, the header file /sw/include/iconv.h > was not included correctly. GCC offers -idirafter. The argument following, a directory with C header files, is then searched last. Using -idirafter /usr/include should guarantee that the system's iconv.h is not used when Fink's version of this file exists. This worked well quite a few times for me. Besides, adding -H to CPPFLAGS or CFLAGS should reveal which header file is actually used during compilation. -- Greetings Pete If all else fails read the instructions. - Donald Knuth -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On 15/02/13 01:18, Alexander Hansen wrote: [] > Of course, the actual solution that worked for Fabio Diaolio following > the lead of Stephen Butler was "fink reinstall libiconv-dev libiconv-bin > libiconv", and I don't have a convincing argument for why that should > have done anything to solve the problem. Well, it *could* have repaired a faulty /sw/include/iconv.h. But we'll never know what the status of that file was prior to the reinstall. I am wondering how reproducible this error was, anyway. Maybe a restart of the build of doxygen, after applying whichever "fix", was enough. -- Martin -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Problem: compiling doxygen-1.8.3.1-1 failed
On 15/02/13 01:06, Jack Howarth wrote: [] > On x86_64 10.6 fink, I ran into the following build failure... > > /usr/bin/make -f Makefile.doxygenPERL=/usr/bin/perl all > c++ -c -pipe -D__FreeBSD__=6 -DYY_TYPEDEF_YY_SIZE_T -Dyy_size_t=int -Wall -W > -Wno-deprecated-declarations -O2 -I../qtools -I../libmd5 -I. -I/sw/include -o > ../ > objects/main.o main.cpp > c++ -Wl,-search_paths_first -o ../bin/doxygen ../objects/main.o -L../lib > -L/sw/lib -ldoxygen -ldoxycfg -lqtools -lmd5 -lpthread -liconv -framework > CoreServic > es > Undefined symbols for architecture x86_64: >"_iconv_open", referenced from: >_portable_iconv_open in libdoxycfg.a(portable_c.o) You see that -L/sw/lib is already on the linker line. The error is not in some dylib or other, it is that the linker is asked to resolve the symbol "_iconv_open" and not, as it should be, "_libiconv_open". This mistake happened at the compilation of portable_c.c. It is an indication that at that time, the header file /sw/include/iconv.h was not included correctly. Now why this should have been the case is not clear. [] > I initially worked around that by changing doxygen.patch from... By "worked around", you mean when you did not do this, you got the error reproducibly, and when you did it, you did not get the error? > @@ -36,7 +36,7 @@ > > TMAKE_LINK = c++ > TMAKE_LINK_SHLIB = c++ > -TMAKE_LFLAGS = -Wl,-search_paths_first -arch i386 -arch ppc > +TMAKE_LFLAGS = -Wl,-search_paths_first -arch @FINK_ARCH@ > TMAKE_LFLAGS_RELEASE = > TMAKE_LFLAGS_DEBUG = > TMAKE_LFLAGS_SHLIB = -shared > > to > > @@ -36,7 +36,7 @@ > > TMAKE_LINK = c++ > TMAKE_LINK_SHLIB = c++ > -TMAKE_LFLAGS = -Wl,-search_paths_first -arch i386 -arch ppc > +TMAKE_LFLAGS = -arch @FINK_ARCH@ > TMAKE_LFLAGS_RELEASE = > TMAKE_LFLAGS_DEBUG = > TMAKE_LFLAGS_SHLIB = -shared The -Wl,-search_paths_first is employed because the static libs ../libdoxycfg.a etc that were just built are being used for linking. When -Wl,-search_paths_first is not there, then any old libdoxycfg.dylib that might be found anywhere, for example in /usr/local/lib, would take precedence. According to the error message, this was not the case here, however. So it is not clear how this could have had any effect. > which led me to search for other instances of this failure. I found MacPort's > hack which solved the problem without changing the doxygen.patch. > Jack -- Martin -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
