I see that my build environment does not include some of these variables (CC, CFLAGS, LDFLAGS, etc.). It sets:
> :debug:build Environment:
> :debug:build CC_PRINT_OPTIONS='YES'
> :debug:build
> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/.CC_PRINT_OPTIONS'
> :debug:build CPATH='/opt/local/include'
> :debug:build DEVELOPER_DIR='/Library/Developer/CommandLineTools'
> :debug:build LIBRARY_PATH='/opt/local/lib'
> :debug:build MACOSX_DEPLOYMENT_TARGET='12.0'
> :debug:build MACPORTS_LEGACY_SUPPORT_DISABLED='1'
> :debug:build SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
This may be the cause of the build failure. How do I set the build environment
variables CC, CFLAGS, etc.?
I’ve added this command to the Portfile, but it doesn’t change the build
environment,
> build.env-append \
> "CC=${configure.cc}" \
> "CFLAGS=${configure.cflags}" \
> "CPATH=${compiler.cpath}" \
> "CPPFLAGS=${configure.cppflags}" \
> "CXX=${configure.cxx}" \
> "CXXFLAGS=${configure.cxxflags}" \
> "LDFLAGS=${configure.ldflags}"
> On Aug 30, 2022, at 9:05 PM, Steven Smith <[email protected]> wrote:
>
> I have successfully self-bootstrapped ghc 9.4.2 by hand.
>
> I now believe that the build failures are caused by some default MacPorts
> setting.
>
> Is someone able to suggest a Portfile setting that can recreate this
> successful build? I set (by hand) these basic MacPorts environment variables:
>
>> export CLANG=/usr/bin/clang
>> export CXX=/usr/bin/clang++
>> export CPATH='/opt/local/include'
>> export LIBRARY_PATH='/opt/local/lib'
>> export LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names
>> -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch
>> x86_64'
>> export CPPFLAGS='-I/opt/local/include
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
>
>
>
>> On Aug 28, 2022, at 7:34 PM, Steven Smith <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Also, I’m perplexed with this doesn’t just work with the default MacPorts
>> compiler.cpath and compiler.library_path settings.
>>
>> The file iconv.c has a straightforward #include <iconv.h> from
>>
>> https://github.com/ghc/ghc/blob/161a6f1fd62e797e978e7808a5f567fefa123f16/libraries/base/cbits/iconv.c#L4
>>
>> <https://github.com/ghc/ghc/blob/161a6f1fd62e797e978e7808a5f567fefa123f16/libraries/base/cbits/iconv.c#L4>
>>
>> this should just use these:
>>
>>> CPATH='/opt/local/include'
>>> LIBRARY_PATH='/opt/local/lib'
>>
>>
>>
>>
>>> On Aug 28, 2022, at 3:01 PM, Steven Smith <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Thanks.
>>>
>>>> you probably want to be using the libiconv port anyway?
>>>
>>> Unfortunately, that won’t work without some hackery. Note the different
>>> symbol names in MacPorts:
>>>
>>>> nm -gC
>>>> /opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/bootstrap/opt/local//lib/ghc-9.4.2/lib/x86_64-osx-ghc-9.4.2/base-4.17.0.0/libHSbase-4.17.0.0.a
>>>> /opt/local/lib/libiconv.dylib | grep iconv_open
>>>> 0000000000000000 T _hs_iconv_open
>>>> U _iconv_open
>>>> U _hs_iconv_open
>>>> 0000000000003e02 T _libiconv_open
>>>> 0000000000005375 T _libiconv_open_into
>>>
>>>
>>> Is there a way to hack this out to transform _iconv_open to _libiconv_open
>>> in the .a file?
>>>
>>>
>>>> On Aug 28, 2022, at 2:57 PM, Joshua Root <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> On 2022-8-29 04:42 , Steven Smith wrote:
>>>>> Re: https://gitlab.haskell.org/ghc/ghc/-/issues/22118
>>>>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22118>
>>>>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22118
>>>>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22118>>
>>>>> I'm self-bootstrapping ghc 9.4.2 using hadrian for deployment on MacPorts.
>>>>> Running hadrian -f binary-dist throws this error:
>>>>>> :info:build "_iconv_close", referenced from:
>>>>>> :info:build _hs_iconv_close in libHSbase-4.17.0.0.a(iconv.o)
>>>>>> :info:build (maybe you meant: _hs_iconv_close)
>>>>>> :info:build "_iconv", referenced from:
>>>>>> :info:build _hs_iconv in libHSbase-4.17.0.0.a(iconv.o)
>>>>> The archive file libHSbase-4.17.0.0.a in the ghc install uses the
>>>>> undefined symbol _iconv_close; however, macOS 12.5.1 no longer appears to
>>>>> provide a system libiconv:
>>>>>> ls /usr/lib/libiconv*
>>>>>> ls: /usr/lib/libiconv*: No such file or directory
>>>>> And port iconv provides the _libiconv_open symbol, not the _iconv_open
>>>>> symbol.
>>>>> Is anyone aware of a solution to a missing libconv.dylib on recent macOS?
>>>>
>>>> It's not actually missing, it just doesn't exist as a file in the
>>>> filesystem. All OS-supplied libraries now exist only in the shared dyld
>>>> cache. (The SDK, as you discovered, contains text-based stubs with just
>>>> enough information about exported symbols and whatnot to allow linking.)
>>>>
>>>> That does mean that all build systems that check for the existence of a
>>>> .dylib file to see if a library is available are broken. If checking is
>>>> really necessary, they need to check if they can link with the library
>>>> instead.
>>>>
>>>> For deployment in MacPorts though, you probably want to be using the
>>>> libiconv port anyway?
>>>>
>>>> - Josh
>>>
>>
>
smime.p7s
Description: S/MIME cryptographic signature
