On Sun, Jul 9, 2017 at 12:25 AM Alain O'Dea <[email protected]> wrote:

> On Sat, Jul 8, 2017 at 2:23 PM Alain O'Dea <[email protected]> wrote:
>
>> On Sat, Jul 8, 2017 at 10:41 AM Alain O'Dea <[email protected]> wrote:
>>
>>> I've got the build from GHC 7.6.3 in PKGSRC thru GHC 7.10.3 up to GHC
>>> 8.0.2 (latest stable) working with manual builds.
>>>
>>> I've been working in a PKGSRC 2017Q1 sandbox on the latest pkgbuild
>>> image to make it package-friendly.
>>>
>>> Here's my plan:
>>> 1. Create wip/ghc7x which builds GHC 7.10.3 by build depending on
>>> lang/ghc
>>> 2. Create wip/ghc8 which builds GHC 8.0.2 by build depending on wip/ghc7x
>>>
>>> I ran into an odd issue with the GHC 7.10.3 I built. It is a 64-bit
>>> binary, but is somehow linked against some 32-bit libraries (ncurses,
>>> iconv, gmp) and won't run.
>>>
>>> [root@ghc-builder-x86-64-smartos ~]# ghc
>>> ld.so.1: ghc: fatal: /opt/local/lib//libncurses.so.6: wrong ELF class:
>>> ELFCLASS32
>>> Killed
>>> [root@ghc-builder-x86-64-smartos ~]# ldd
>>> /opt/local/lib/ghc-7.10.3/bin/ghc
>>>         libncurses.so.6 =>       /opt/local/lib//libncurses.so.6  -
>>> wrong ELF class: ELFCLASS32
>>>         libiconv.so.2 =>         /opt/local/lib//libiconv.so.2  - wrong
>>> ELF class: ELFCLASS32
>>>         libgmp.so.10 =>  /opt/local/lib//libgmp.so.10  - wrong ELF
>>> class: ELFCLASS32
>>>         libm.so.2 =>     /usr/lib/amd64/libm.so.2
>>>         librt.so.1 =>    /usr/lib/amd64/librt.so.1
>>>         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
>>>         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
>>>         libssp.so.0 =>   /usr/lib/amd64/libssp.so.0
>>>         libssp.so.0 (LIBSSP_1.0) =>      (version not found)
>>>         libc.so.1 =>     /usr/lib/amd64/libc.so.1
>>>         libgcc_s.so.1 =>         /usr/lib/64/libgcc_s.so.1
>>>
>>
>> I also found this:
>> => Checking for work-directory references in ghc-7.10.3b
>> ERROR: /opt/local/lib/ghc-7.10.3/settings:       ("readelf command",
>> "/home/pbulk/build/wip/ghc7x/work/.tools/bin/readelf"),
>> ERROR: *** The above files still have references to the build directory.
>> ERROR:     This is possibly an error that should be fixed by unwrapping
>> ERROR:     the files or adding missing tools to the package makefile!
>> *** Error code 1
>>
>> It originates in GHC's aclocal.m4. It is somehow picking up the sandbox
>> tools instead of the platform tools. This came up unrelated to SmartOS on
>> #ghc as well last night and I regrettably missed the opportunity to engage
>> their core team.
>>
>> I fix it directly by including a patch for settings.in which disregards
>> the ar, ld, and readelf detected by their autoconf and put in correct
>> /opt/local/bin (ar and readelf) or /usr/bin (only for ld) equivalents. I
>> also fix the libssp link errors seen in compiling client code with GHC by
>> including -lssp in the linker options configs in settings.in.
>>
>> PKGSRC support for GHC 7.10.3 is pretty close to releasable now. The
>> pkgbuild image is an outstanding workbench for this, so thank you Jonathan
>> for putting that together.
>>
>
> Still getting broken binaries out of the build:
>
> [root@ghc-builder-x86-64-smartos /opt/local]# ghci
> ld.so.1: ghc: fatal: /opt/local/lib//libncurses.so.6: wrong ELF class:
> ELFCLASS32
> Killed
> [root@ghc-builder-x86-64-smartos /opt/local]# ghc
> ld.so.1: ghc: fatal: /opt/local/lib//libncurses.so.6: wrong ELF class:
> ELFCLASS32
> Killed
> [root@ghc-builder-x86-64-smartos /opt/local]# ldd
> /opt/local/lib/ghc-7.10.3/bin/ghc
>         libssp.so.0 =>   /usr/lib/amd64/libssp.so.0
>         libssp.so.0 (LIBSSP_1.0) =>      (version not found)
>         libncurses.so.6 =>       /opt/local/lib//libncurses.so.6  - wrong
> ELF class: ELFCLASS32
>         libiconv.so.2 =>         /opt/local/lib//libiconv.so.2  - wrong
> ELF class: ELFCLASS32
>         libgmp.so.10 =>  /opt/local/lib//libgmp.so.10  - wrong ELF class:
> ELFCLASS32
>         libm.so.2 =>     /usr/lib/amd64/libm.so.2
>         librt.so.1 =>    /usr/lib/amd64/librt.so.1
>         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
>         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
>         libc.so.1 =>     /usr/lib/amd64/libc.so.1
>         libgcc_s.so.1 =>         /usr/lib/64/libgcc_s.so.1
>
> The ghc binary looks fine in the pkgbuild work .destdir:
> --<root@pkgbuild
> >-(/data/chroot/dev-2017Q1-x86_64)-</home/pbulk/build/wip/ghc7x/work>--
> -> ldd .destdir/opt/local/lib/ghc-7.10.3/bin/ghc
>         libssp.so.0 =>
> /opt/local/gcc49/x86_64-sun-solaris2.11/lib/amd64/libssp.so.0
>         libncurses.so.6 =>       /opt/local/lib//libncurses.so.6
>         libiconv.so.2 =>         /opt/local/lib//libiconv.so.2
>         libgmp.so.10 =>  /opt/local/lib//libgmp.so.10
>         libm.so.2 =>     /usr/lib/amd64/libm.so.2
>         librt.so.1 =>    /usr/lib/amd64/librt.so.1
>         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
>         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
>         libc.so.1 =>     /usr/lib/amd64/libc.so.1
>         libgcc_s.so.1 =>
> /opt/local/gcc49/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1
>         libumem.so.1 =>  /lib/64/libumem.so.1
>
> I'm not sure why libcurses, libiconv, and libgmp come out wrong, while
> libm, librt, libdl, libpthread, libc, and libgcc_s all come out fine. I
> really have no idea why ldd shows a second libssp in the base-multiarch
> 17.1.0 zone I extracted
> /data/packages/SmartOS/2017Q1/x86_64/All/ghc-7.10.3b.tgz into.
>
> I think it's an issue with how I'm building my sandbox. I'm using
> `run-sandbox 2017Q1-x86_64`.
>
> When I run my package on base-64 17.1.0, it appears to work. I can compile
> hello.hs:
> main = putStrLn "Hello, World"
>
> but ghci segfaults:
> [root@ghc-builder-x86-64-smartos /opt/local]# ghci
> GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
> Segmentation Fault (core dumped)
>
> I ran ghci with truss and got this tail:
> /2:     setcontext(0xFFFFFD7FFEEBE4B0)
> /2:         Received signal #14, SIGALRM, in lwp_park() [caught]
> /2:           siginfo: SIG#0
> /2:     lwp_park(0x00000000, 0)                         Err#91 ERESTART
> /2:     lwp_sigmask(SIG_SETMASK, 0x00002000, 0x00000000, 0x00000000,
> 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
> /2:     setcontext(0xFFFFFD7FFEEBE4B0)
> /1:         Incurred fault #6, FLTBOUNDS  %pc = 0x0432FE0C
> /1:           siginfo: SIGSEGV SEGV_ACCERR addr=0x0432FE0C
> /1:         Received signal #11, SIGSEGV [default]
> /1:           siginfo: SIGSEGV SEGV_ACCERR addr=0x0432FE0C
>
> It's not clear what ghci is attempting when it segfaults. When I build
> manually external to PKGSRC it works.
>
> I wondering if the extra slash in the lib paths is causing grief.
>
> I have a branch with my WIP on it:
> https://github.com/AlainODea/pkgsrc-wip/blob/ao-ghc7x/ghc7x/Makefile
>

New strategy. I took pkgsrc-wip/ghc as a basis (much cleaner) and used it's
bootstrap to build GHC 7.10.3.

Still getting segfaults, but I have decent details documented:
https://gist.github.com/AlainODea/c9a1da84efc8e22e3ba637af8a3f53c2

I'm out of my depth here. I've tried some basic mdb hacking to figure out
what happened, but I'm not getting far with that.

I think I have it located in foreignExportStablePtr, but I'm not sure.

Has anyone seen seg faults in GHCi after building GHC on SmartOS recently?



-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Reply via email to