#48224: ghc @7.8.3_2: setting compiler.cpath and compiler.library_path is potential no-op ------------------------------------+------------------- Reporter: howarth.at.macports@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: Port: ghc | ------------------------------------+------------------- Changes (by larryv@…): * owner: macports-tickets@… => cal@… Old description:
While adapting the MacPorts ghc-bootstrap/ghc to create matching fink packages to build ghc from source for adding rootless support to 7.8.3, I noticed what appears to be a thinko in the current ghc Portfile. Specially, the section...
# OK so because the bootstrap binary has been prebuilt for libraries # in /usr/lib we search these before macports stuff to prevent # link errors, ghc _should_ actually compile itself in stage2 # using paths from the command line arguments compiler.cpath /usr/include compiler.library_path /usr/lib
seems to be a pointless no-op since it adds those directories to the search list *after* the -I and -L entries are processed. In the fink packaging, it was desired to mimic the upstream ghc binaries as closely as possible so...
--with-iconv-includes=/usr/include \ --with-iconv-libraries=/usr/lib \
was used in concert with
NoSetCPPFLAGS: true NoSetLDFLAGS: true
Interestingly this still required a BuildConflicts on the fink libiconv- dev to prevent a build issue with ghc-pandoc-types...
[57 of 57] Compiling Text.Pandoc ( src/Text/Pandoc.hs, dist/build/Text/Pandoc.o ) In-place registering pandoc-1.12.4.2... Preprocessing executable 'pandoc' for pandoc-1.12.4.2... [1 of 1] Compiling Main ( pandoc.hs, dist/build/pandoc /pandoc-tmp/Main.o ) Linking dist/build/pandoc/pandoc ... Undefined symbols for architecture x86_64: "_libiconv", referenced from: _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) "_libiconv_close", referenced from: _hs_iconv_close in libHSbase-4.7.0.1.a(iconv.o) "_libiconv_open", referenced from: _hs_iconv_open in libHSbase-4.7.0.1.a(iconv.o) ld: symbol(s) not found for architecture x86_64
In the MacPorts case, since you using...
--with-iconv-includes=${prefix}/include \ --with-iconv-libraries=${prefix}/lib \
and are leaving -I${prefix}/include on configure.cppflags and -L${prefix}/lib on configure.ldflags, the use of...
compiler.cpath /usr/include compiler.library_path /usr/lib
is pointless dead code in the Portfile
New description: While adapting the MacPorts ghc-bootstrap/ghc to create matching fink packages to build ghc from source for adding rootless support to 7.8.3, I noticed what appears to be a thinko in the current ghc Portfile. Specially, the section... {{{ # OK so because the bootstrap binary has been prebuilt for libraries # in /usr/lib we search these before macports stuff to prevent # link errors, ghc _should_ actually compile itself in stage2 # using paths from the command line arguments compiler.cpath /usr/include compiler.library_path /usr/lib }}} seems to be a pointless no-op since it adds those directories to the search list *after* the -I and -L entries are processed.\\ In the fink packaging, it was desired to mimic the upstream ghc binaries as closely as possible so... {{{ --with-iconv-includes=/usr/include \ --with-iconv-libraries=/usr/lib \ }}} was used in concert with {{{ NoSetCPPFLAGS: true NoSetLDFLAGS: true }}} Interestingly this still required a BuildConflicts on the fink libiconv- dev to prevent a build issue with ghc-pandoc-types... {{{ [57 of 57] Compiling Text.Pandoc ( src/Text/Pandoc.hs, dist/build/Text/Pandoc.o ) In-place registering pandoc-1.12.4.2... Preprocessing executable 'pandoc' for pandoc-1.12.4.2... [1 of 1] Compiling Main ( pandoc.hs, dist/build/pandoc/pandoc- tmp/Main.o ) Linking dist/build/pandoc/pandoc ... Undefined symbols for architecture x86_64: "_libiconv", referenced from: _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) "_libiconv_close", referenced from: _hs_iconv_close in libHSbase-4.7.0.1.a(iconv.o) "_libiconv_open", referenced from: _hs_iconv_open in libHSbase-4.7.0.1.a(iconv.o) ld: symbol(s) not found for architecture x86_64 }}} In the MacPorts case, since you using... {{{ --with-iconv-includes=${prefix}/include \ --with-iconv-libraries=${prefix}/lib \ }}} and are leaving -I${prefix}/include on configure.cppflags and -L${prefix}/lib on configure.ldflags, the use of... {{{ compiler.cpath /usr/include compiler.library_path /usr/lib }}} is pointless dead code in the Portfile -- -- Ticket URL: <https://trac.macports.org/ticket/48224#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X