repl/test-repl-glibc.py Failure on Ubuntu


(Joe Bell) #1

Howdy,

I've mentioned this once before and didn't get any feedback; I thought I'd
give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0 package on
Ubuntu? The compile, link, packaging steps all complete successfully, but
then the repl/test-repl-glibc.py fails. The failure is that the REPL
doesn't interact (the underlying script is using pexpect to send/expect)
properly:

  2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which is a
greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

Thanks,
Joe

···

---
http://dev.iachieved.it/iachievedit/
@iachievedit


(Ryan Lovelett) #2

Howdy,

I've mentioned this once before and didn't get any feedback; I thought
I'd give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0
package on Ubuntu? The compile, link, packaging steps all complete
successfully, but then the repl/test-repl-glibc.py fails. The failure
is that the REPL doesn't interact (the underlying script is using
pexpect to send/expect) properly:

2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please
use #sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated,
please use #sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which
is a greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just on a
different list) [1]. I suggest you go vote for SR-1109 [2] which is the
bug report for this issue.

I think this is show stopper. Not for the REPL break but because it also
breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?) might
have introduced this regression. Kate Stone mentioned that she thinks
this issue was introduced sometime after the 3-16 snapshot. I'm trying
to corroborate that.

[1] https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

···

On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit
_________________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Joe Bell) #3

Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
reproduce as well.

I think now its clear why the 14.04 and 15.10 packaging tests are passing,
and that's because they aren't running the tests that leverage pexpect, if
you look at the console log for the 14.04 test:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText

lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related
tests

Perhaps pexpect should be added to the CI server so these tests can begin
failing properly.

···

On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev < swift-dev@swift.org> wrote:

On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Howdy,

I've mentioned this once before and didn't get any feedback; I thought I'd
give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0 package
on Ubuntu? The compile, link, packaging steps all complete successfully,
but then the repl/test-repl-glibc.py fails. The failure is that the REPL
doesn't interact (the underlying script is using pexpect to send/expect)
properly:

  2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated, please
use #sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which is a
greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just on a
different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug
report for this issue.

I think this is show stopper. Not for the REPL break but because it also
breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?) might
have introduced this regression. Kate Stone mentioned that she thinks this
issue was introduced sometime after the 3-16 snapshot. I'm trying to
corroborate that.

[1]
https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit
*_______________________________________________*
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit


(Jordan Rose) #4

+swift-lldb-dev

···

On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift-dev@swift.org> wrote:

Ryan, thanks. I've voted on SR-1109 and will add the steps I use to reproduce as well.

I think now its clear why the 14.04 and 15.10 packaging tests are passing, and that's because they aren't running the tests that leverage pexpect, if you look at the console log for the 14.04 test: https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText

lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related tests

Perhaps pexpect should be added to the CI server so these tests can begin failing properly.

On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Howdy,

I've mentioned this once before and didn't get any feedback; I thought I'd give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0 package on Ubuntu? The compile, link, packaging steps all complete successfully, but then the repl/test-repl-glibc.py fails. The failure is that the REPL doesn't interact (the underlying script is using pexpect to send/expect) properly:

  2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please use #sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated, please use #sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which is a greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just on a different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug report for this issue.

I think this is show stopper. Not for the REPL break but because it also breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?) might have introduced this regression. Kate Stone mentioned that she thinks this issue was introduced sometime after the 3-16 snapshot. I'm trying to corroborate that.

[1] https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Ryan Lovelett) #5

I've played around with `git bisect` and I think I've tracked it down to
this commit [1]. Which came from PR #1704 [2]. I've also updated the
issue, SR-1109, to include this information.

c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
commit c6121d56b19305cf59148d46af54c06b771f3180
Author: Brian Gesiak <bgesiak@fb.com>

[Un-revert][Glibc] Configure modulemap for target, not host

This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
commit needed to be reverted because of an issue in which install
targets were added to OS X builds that did not target Linux. This
addresses that issue by guarding all the Linux-only CMake logic with a
check for the SDK being built.

:040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
:90062ad44050a19fc0d5bc846409945e83619b01 M lib
:040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
:1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
:040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
:41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools

[1] https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
[2] https://github.com/apple/swift/pull/1704

···

Date: Wed Mar 16 13:29:42 2016 -0400

On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:

+swift-lldb-dev

On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift- >> dev@swift.org> wrote:

Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
reproduce as well.

I think now its clear why the 14.04 and 15.10 packaging tests are
passing, and that's because they aren't running the tests that
leverage pexpect, if you look at the console log for the 14.04 test:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText

lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping
related tests

Perhaps pexpect should be added to the CI server so these tests can
begin failing properly.

On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev <swift- >> dev@swift.org> wrote:

__

On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Howdy,

I've mentioned this once before and didn't get any feedback; I
thought I'd give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0
package on Ubuntu? The compile, link, packaging steps all complete
successfully, but then the repl/test-repl-glibc.py fails. The
failure is that the REPL doesn't interact (the underlying script is
using pexpect to send/expect) properly:

2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please
use #sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated,
please use #sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of
which is a greenfield VM with all of the prerequisites/clang-3.6
installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just
on a different list) [1]. I suggest you go vote for SR-1109 [2]
which is the bug report for this issue.

I think this is show stopper. Not for the REPL break but because it
also breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?)
might have introduced this regression. Kate Stone mentioned that she
thinks this issue was introduced sometime after the 3-16 snapshot.
I'm trying to corroborate that.

[1] https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit

_________________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Dmitri Gribenko) #6

+Brian

···

On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev <swift-dev@swift.org> wrote:

I've played around with `git bisect` and I think I've tracked it down to
this commit [1]. Which came from PR #1704 [2]. I've also updated the issue,
SR-1109, to include this information.

c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
commit c6121d56b19305cf59148d46af54c06b771f3180
Author: Brian Gesiak <bgesiak@fb.com>
Date: Wed Mar 16 13:29:42 2016 -0400

    [Un-revert][Glibc] Configure modulemap for target, not host

    This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
    commit needed to be reverted because of an issue in which install
    targets were added to OS X builds that did not target Linux. This
    addresses that issue by guarding all the Linux-only CMake logic with a
    check for the SDK being built.

:040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
90062ad44050a19fc0d5bc846409945e83619b01 M lib
:040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
:040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools

[1]
https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
[2] https://github.com/apple/swift/pull/1704

On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:

+swift-lldb-dev

On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift-dev@swift.org> > wrote:

Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
reproduce as well.

I think now its clear why the 14.04 and 15.10 packaging tests are passing,
and that's because they aren't running the tests that leverage pexpect, if
you look at the console log for the 14.04 test:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText

lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related
tests

Perhaps pexpect should be added to the CI server so these tests can begin
failing properly.

On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev > <swift-dev@swift.org> wrote:

On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Howdy,

I've mentioned this once before and didn't get any feedback; I thought I'd
give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0 package on
Ubuntu? The compile, link, packaging steps all complete successfully, but
then the repl/test-repl-glibc.py fails. The failure is that the REPL
doesn't interact (the underlying script is using pexpect to send/expect)
properly:

  2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which is a
greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just on a
different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug
report for this issue.

I think this is show stopper. Not for the REPL break but because it also
breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?) might have
introduced this regression. Kate Stone mentioned that she thinks this issue
was introduced sometime after the 3-16 snapshot. I'm trying to corroborate
that.

[1]
https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Ryan Lovelett) #7

I've tried reverting c6121d56b19305cf59148d46af54c06b771f3180 just to
see if doing that will restore functionality to lldb/repl.

Unfortunately too many things have changed in the build system since
that commit for a revert to make sense anymore.

Can anyone provide documentation/explain the mechanics of what happens
when I type "import Glibc" into the REPL/lldb?

···

On Thu, Apr 14, 2016, at 05:47 PM, Dmitri Gribenko wrote:

+Brian

On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev > <swift-dev@swift.org> wrote:
> I've played around with `git bisect` and I think I've tracked it down to
> this commit [1]. Which came from PR #1704 [2]. I've also updated the issue,
> SR-1109, to include this information.
>
> c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
> commit c6121d56b19305cf59148d46af54c06b771f3180
> Author: Brian Gesiak <bgesiak@fb.com>
> Date: Wed Mar 16 13:29:42 2016 -0400
>
> [Un-revert][Glibc] Configure modulemap for target, not host
>
> This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
> commit needed to be reverted because of an issue in which install
> targets were added to OS X builds that did not target Linux. This
> addresses that issue by guarding all the Linux-only CMake logic with a
> check for the SDK being built.
>
> :040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
> 90062ad44050a19fc0d5bc846409945e83619b01 M lib
> :040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
> 1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
> :040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
> 41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools
>
> [1]
> https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
> [2] https://github.com/apple/swift/pull/1704
>
>
> On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:
>
> +swift-lldb-dev
>
>
> On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift-dev@swift.org> > > wrote:
>
> Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
> reproduce as well.
>
> I think now its clear why the 14.04 and 15.10 packaging tests are passing,
> and that's because they aren't running the tests that leverage pexpect, if
> you look at the console log for the 14.04 test:
> https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText
>
> lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related
> tests
>
> Perhaps pexpect should be added to the CI server so these tests can begin
> failing properly.
>
>
> On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev > > <swift-dev@swift.org> wrote:
>
>
>
> On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:
>
> Howdy,
>
> I've mentioned this once before and didn't get any feedback; I thought I'd
> give it one more shot.
>
> Has anyone out there tried building, from scratch, the Swift 3.0 package on
> Ubuntu? The compile, link, packaging steps all complete successfully, but
> then the repl/test-repl-glibc.py fails. The failure is that the REPL
> doesn't interact (the underlying script is using pexpect to send/expect)
> properly:
>
> 2> import Glibc
> warning: <REPL>:1:1: warning: #line directive is deprecated, please use
> #sourceLocation instead
> #line 2 "repl.swift"
> ^~~~~
> #sourceLocation
>
> warning: repl.swift:3:1: warning: #line directive is deprecated, please use
> #sourceLocation instead
> #line
> ^~~~~
> #sourceLocation
>
> error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
> import Glibc
>
> This is occurring on two separate Ubuntu 14.04 systems, one of which is a
> greenfield VM with all of the prerequisites/clang-3.6 installed.
>
> Stumped on this one and was just curious if anyone can reproduce.
>
>
>
> I can also reproduce. I actually broght this up yesterday too (just on a
> different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug
> report for this issue.
>
> I think this is show stopper. Not for the REPL break but because it also
> breaks the debugger on Linux as well.
>
> Right now I'm trying to bisect the repos to see which commit(s?) might have
> introduced this regression. Kate Stone mentioned that she thinks this issue
> was introduced sometime after the 3-16 snapshot. I'm trying to corroborate
> that.
>
> [1]
> https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
> [2] https://bugs.swift.org/browse/SR-1109
>
>
>
>
> Thanks,
> Joe
>
>
>
> ---
> http://dev.iachieved.it/iachievedit/
> @iachievedit
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
>
>
> --
> ---
> http://dev.iachieved.it/iachievedit/
> @iachievedit
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Joe Bell) #8

+Mishal, while Ryan et al are looking at the broken REPL, would it make
sense to update the CI servers with the Python pexpect module so that the
test-repl-glibc.py will fail the build?

···

On Fri, Apr 15, 2016 at 10:19 AM, Ryan Lovelett <swift-dev@ryan.lovelett.me> wrote:

I've tried reverting c6121d56b19305cf59148d46af54c06b771f3180 just to
see if doing that will restore functionality to lldb/repl.

Unfortunately too many things have changed in the build system since
that commit for a revert to make sense anymore.

Can anyone provide documentation/explain the mechanics of what happens
when I type "import Glibc" into the REPL/lldb?

On Thu, Apr 14, 2016, at 05:47 PM, Dmitri Gribenko wrote:
> +Brian
>
> On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev > > <swift-dev@swift.org> wrote:
> > I've played around with `git bisect` and I think I've tracked it down
to
> > this commit [1]. Which came from PR #1704 [2]. I've also updated the
issue,
> > SR-1109, to include this information.
> >
> > c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
> > commit c6121d56b19305cf59148d46af54c06b771f3180
> > Author: Brian Gesiak <bgesiak@fb.com>
> > Date: Wed Mar 16 13:29:42 2016 -0400
> >
> > [Un-revert][Glibc] Configure modulemap for target, not host
> >
> > This reverts commit f2154ee94d, which reverted 04e1cd5bda. The
original
> > commit needed to be reverted because of an issue in which install
> > targets were added to OS X builds that did not target Linux. This
> > addresses that issue by guarding all the Linux-only CMake logic
with a
> > check for the SDK being built.
> >
> > :040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
> > 90062ad44050a19fc0d5bc846409945e83619b01 M lib
> > :040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
> > 1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
> > :040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
> > 41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools
> >
> > [1]
> >
https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
> > [2] https://github.com/apple/swift/pull/1704
> >
> >
> > On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:
> >
> > +swift-lldb-dev
> >
> >
> > On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev < > swift-dev@swift.org> > > > wrote:
> >
> > Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
> > reproduce as well.
> >
> > I think now its clear why the 14.04 and 15.10 packaging tests are
passing,
> > and that's because they aren't running the tests that leverage
pexpect, if
> > you look at the console log for the 14.04 test:
> >
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText
> >
> > lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping
related
> > tests
> >
> > Perhaps pexpect should be added to the CI server so these tests can
begin
> > failing properly.
> >
> >
> > On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev > > > <swift-dev@swift.org> wrote:
> >
> >
> >
> > On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:
> >
> > Howdy,
> >
> > I've mentioned this once before and didn't get any feedback; I thought
I'd
> > give it one more shot.
> >
> > Has anyone out there tried building, from scratch, the Swift 3.0
package on
> > Ubuntu? The compile, link, packaging steps all complete successfully,
but
> > then the repl/test-repl-glibc.py fails. The failure is that the REPL
> > doesn't interact (the underlying script is using pexpect to
send/expect)
> > properly:
> >
> > 2> import Glibc
> > warning: <REPL>:1:1: warning: #line directive is deprecated, please use
> > #sourceLocation instead
> > #line 2 "repl.swift"
> > ^~~~~
> > #sourceLocation
> >
> > warning: repl.swift:3:1: warning: #line directive is deprecated,
please use
> > #sourceLocation instead
> > #line
> > ^~~~~
> > #sourceLocation
> >
> > error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
> > import Glibc
> >
> > This is occurring on two separate Ubuntu 14.04 systems, one of which
is a
> > greenfield VM with all of the prerequisites/clang-3.6 installed.
> >
> > Stumped on this one and was just curious if anyone can reproduce.
> >
> >
> >
> > I can also reproduce. I actually broght this up yesterday too (just on
a
> > different list) [1]. I suggest you go vote for SR-1109 [2] which is
the bug
> > report for this issue.
> >
> > I think this is show stopper. Not for the REPL break but because it
also
> > breaks the debugger on Linux as well.
> >
> > Right now I'm trying to bisect the repos to see which commit(s?) might
have
> > introduced this regression. Kate Stone mentioned that she thinks this
issue
> > was introduced sometime after the 3-16 snapshot. I'm trying to
corroborate
> > that.
> >
> > [1]
> >
https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
> > [2] https://bugs.swift.org/browse/SR-1109
> >
> >
> >
> >
> > Thanks,
> > Joe
> >
> >
> >
> > ---
> > http://dev.iachieved.it/iachievedit/
> > @iachievedit
> >
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> >
> >
> > --
> > ---
> > http://dev.iachieved.it/iachievedit/
> > @iachievedit
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
>
>
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit


(Jim Ingham) #9

The REPL makes a swift compiler, in which it runs your code (obvious...) So when you do "import <some_module>" in the REPL, we need to load that module into our swift compiler. In the lldb REPL that is managed in SwiftExpressionParser::PerformAutoImport. This will call lldb's SwiftASTContext::FindAndLoadModule -> SwiftASTContext::LoadModule, which will then do three things: find & tell the swift compiler about the .swiftmodule, dlopen any underlying libraries the .swiftmodule needs. Finally, if the module imported C/ObjC code, the swift module doesn't describe the types coming from C but relies on types being in a clang module that can be imported into Swift. That means that the REPL must rebuild a clang module which matches the one originally used to build the swift module.

It's that final step that tends to be tricky, since Swift has to be convinced that the Clang module that the ClangImporter builds is compatible with the one that was originally used to build the swift module, and it is somewhat picky about this. All that checking goes on in swift, not lldb, and I'm not very familiar with how this is done.

One difficulty that comes up often is figuring out where the module map & headers that were used to build the ClangImporter when the Swift module was originally constructed are on the current system. On OS X the options that were used to build the ClangImporter are serialized in the swift module. So we just grab that blob and use it to initialize the ClangImporter. Construction this environment happens in SwiftASTContext::CreateInstance - for instance the call to loadFromSerializedAST is where we load the serialized options.

That wasn't the way it was done in the early Swift days, instead the DWARF for the swift module would have the compiler options used to create the swift compiler (including some that were for the importer) and lldb would try to parse them and extract whatever goodies it needed. That was fragile, and we switched to the serialization approach, but the code to parse up the DWARF is still there, as well as a bunch of assist functions so that we could add any extra information we might know (like what SDK's are being used.)

If you poke around in this code you'll see that we log pretty extensively the options we are using to make up both our Swift compiler and the ClangImporter. To see this in action in the REPL, turn on the "types" log:

> :log enable -f /tmp/lldb-types-log.txt lldb type

Then do your import. If this is getting auto-imported too early for you to turn on the log by hand, then just put the log command (without the ":") in your .lldbinit file, the REPL, being just a particular invocation of lldb, will read that file.

Hope this helps,

Jim

···

On Apr 15, 2016, at 8:19 AM, Ryan Lovelett via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:

I've tried reverting c6121d56b19305cf59148d46af54c06b771f3180 just to
see if doing that will restore functionality to lldb/repl.

Unfortunately too many things have changed in the build system since
that commit for a revert to make sense anymore

Can anyone provide documentation/explain the mechanics of what happens
when I type "import Glibc" into the REPL/lldb?

On Thu, Apr 14, 2016, at 05:47 PM, Dmitri Gribenko wrote:

+Brian

On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev >> <swift-dev@swift.org> wrote:

I've played around with `git bisect` and I think I've tracked it down to
this commit [1]. Which came from PR #1704 [2]. I've also updated the issue,
SR-1109, to include this information.

c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
commit c6121d56b19305cf59148d46af54c06b771f3180
Author: Brian Gesiak <bgesiak@fb.com>
Date: Wed Mar 16 13:29:42 2016 -0400

   [Un-revert][Glibc] Configure modulemap for target, not host

   This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
   commit needed to be reverted because of an issue in which install
   targets were added to OS X builds that did not target Linux. This
   addresses that issue by guarding all the Linux-only CMake logic with a
   check for the SDK being built.

:040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
90062ad44050a19fc0d5bc846409945e83619b01 M lib
:040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
:040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools

[1]
https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
[2] https://github.com/apple/swift/pull/1704

On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:

+swift-lldb-dev

On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift-dev@swift.org> >>> wrote:

Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
reproduce as well.

I think now its clear why the 14.04 and 15.10 packaging tests are passing,
and that's because they aren't running the tests that leverage pexpect, if
you look at the console log for the 14.04 test:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText

lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related
tests

Perhaps pexpect should be added to the CI server so these tests can begin
failing properly.

On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev >>> <swift-dev@swift.org> wrote:

On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:

Howdy,

I've mentioned this once before and didn't get any feedback; I thought I'd
give it one more shot.

Has anyone out there tried building, from scratch, the Swift 3.0 package on
Ubuntu? The compile, link, packaging steps all complete successfully, but
then the repl/test-repl-glibc.py fails. The failure is that the REPL
doesn't interact (the underlying script is using pexpect to send/expect)
properly:

2> import Glibc
warning: <REPL>:1:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line 2 "repl.swift"
^~~~~
#sourceLocation

warning: repl.swift:3:1: warning: #line directive is deprecated, please use
#sourceLocation instead
#line
^~~~~
#sourceLocation

error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
import Glibc

This is occurring on two separate Ubuntu 14.04 systems, one of which is a
greenfield VM with all of the prerequisites/clang-3.6 installed.

Stumped on this one and was just curious if anyone can reproduce.

I can also reproduce. I actually broght this up yesterday too (just on a
different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug
report for this issue.

I think this is show stopper. Not for the REPL break but because it also
breaks the debugger on Linux as well.

Right now I'm trying to bisect the repos to see which commit(s?) might have
introduced this regression. Kate Stone mentioned that she thinks this issue
was introduced sometime after the 3-16 snapshot. I'm trying to corroborate
that.

[1]
https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
[2] https://bugs.swift.org/browse/SR-1109

Thanks,
Joe

---
http://dev.iachieved.it/iachievedit/
@iachievedit

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
---
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev


(Ryan Lovelett) #10

Progress. Hat tip to William Dillon (@hpux735 on Twitter) for pointing
something out; `strace`

Ran `strace` on the REPL while trying to import Glibc. Noticed that it
was looking for a file: /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
which does not exist. However,
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap does exist.

Provided a symbolic link from
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

I'll start working on a patch in the morning (of course if someone beats
me to it I won't be mad; please). Just thought I'd update those
interested with a work around in the meantime.


(Ryan Lovelett) #11

Facepalm.

Progress. Hat tip to William Dillon (@hpux735 on Twitter) for pointing
something out; `strace`

Ran `strace` on the REPL while trying to import Glibc. Noticed that it
was looking for a file: /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
which does not exist. However,
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap does exist.

/usr/lib/swift/linux/x86_64/glibc.modulemap

Provided a symbolic link from
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

Provided a symbolic link from
/usr/lib/swift/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

I'll start working on a patch in the morning (of course if someone beats
me to it I won't be mad; please). Just thought I'd update those
interested with a work around in the meantime.

It is late. I'm clearly done for the day.

···

On Fri, Apr 15, 2016, at 11:11 PM, Ryan Lovelett wrote:


(Ryan Lovelett) #12

First I want to say wonderful help! Thank you.

The REPL makes a swift compiler, in which it runs your code (obvious...)
So when you do "import <some_module>" in the REPL, we need to load that
module into our swift compiler. In the lldb REPL that is managed in
SwiftExpressionParser::PerformAutoImport. This will call lldb's
SwiftASTContext::FindAndLoadModule -> SwiftASTContext::LoadModule, which
will then do three things: find & tell the swift compiler about the
.swiftmodule, dlopen any underlying libraries the .swiftmodule needs.
Finally, if the module imported C/ObjC code, the swift module doesn't
describe the types coming from C but relies on types being in a clang
module that can be imported into Swift. That means that the REPL must
rebuild a clang module which matches the one originally used to build the
swift module.

It's that final step that tends to be tricky, since Swift has to be
convinced that the Clang module that the ClangImporter builds is
compatible with the one that was originally used to build the swift
module, and it is somewhat picky about this. All that checking goes on
in swift, not lldb, and I'm not very familiar with how this is done.

One difficulty that comes up often is figuring out where the module map &
headers that were used to build the ClangImporter when the Swift module
was originally constructed are on the current system. On OS X the
options that were used to build the ClangImporter are serialized in the
swift module. So we just grab that blob and use it to initialize the
ClangImporter. Construction this environment happens in
SwiftASTContext::CreateInstance - for instance the call to
loadFromSerializedAST is where we load the serialized options.

Not sure if you'll find this interesting or not but
loadFromSerializedAST never actually gets reached when I'm debugging
(e.g., `b SwiftASTContext.cpp:1489` and `b SwiftASTContext.cpp:1809`)
based on what you've discussed here that seems to be counter to your
explanation.

I've devised a "work-around".

But I cannot seem to root out the code that is responsible for building
the path where it looks for the modulemap. Currently it is looking for
it in `/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap`. Which is not
where it gets installed.

I could make a patch for Swift that copies the module map to that
location during install. But that feels like a hack. I'd rather get into
the logic of how that path is constructed and resolve it there.

···

On Fri, Apr 15, 2016, at 06:01 PM, Jim Ingham wrote:

That wasn't the way it was done in the early Swift days, instead the
DWARF for the swift module would have the compiler options used to create
the swift compiler (including some that were for the importer) and lldb
would try to parse them and extract whatever goodies it needed. That was
fragile, and we switched to the serialization approach, but the code to
parse up the DWARF is still there, as well as a bunch of assist functions
so that we could add any extra information we might know (like what SDK's
are being used.)

If you poke around in this code you'll see that we log pretty extensively
the options we are using to make up both our Swift compiler and the
ClangImporter. To see this in action in the REPL, turn on the "types"
log:

> :log enable -f /tmp/lldb-types-log.txt lldb type

Then do your import. If this is getting auto-imported too early for you
to turn on the log by hand, then just put the log command (without the
":") in your .lldbinit file, the REPL, being just a particular invocation
of lldb, will read that file.

Hope this helps,

Jim

> On Apr 15, 2016, at 8:19 AM, Ryan Lovelett via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:
>
> I've tried reverting c6121d56b19305cf59148d46af54c06b771f3180 just to
> see if doing that will restore functionality to lldb/repl.
>
> Unfortunately too many things have changed in the build system since
> that commit for a revert to make sense anymore
>
> Can anyone provide documentation/explain the mechanics of what happens
> when I type "import Glibc" into the REPL/lldb?
>
> On Thu, Apr 14, 2016, at 05:47 PM, Dmitri Gribenko wrote:
>> +Brian
>>
>> On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev > >> <swift-dev@swift.org> wrote:
>>> I've played around with `git bisect` and I think I've tracked it down to
>>> this commit [1]. Which came from PR #1704 [2]. I've also updated the issue,
>>> SR-1109, to include this information.
>>>
>>> c6121d56b19305cf59148d46af54c06b771f3180 is the first bad commit
>>> commit c6121d56b19305cf59148d46af54c06b771f3180
>>> Author: Brian Gesiak <bgesiak@fb.com>
>>> Date: Wed Mar 16 13:29:42 2016 -0400
>>>
>>> [Un-revert][Glibc] Configure modulemap for target, not host
>>>
>>> This reverts commit f2154ee94d, which reverted 04e1cd5bda. The original
>>> commit needed to be reverted because of an issue in which install
>>> targets were added to OS X builds that did not target Linux. This
>>> addresses that issue by guarding all the Linux-only CMake logic with a
>>> check for the SDK being built.
>>>
>>> :040000 040000 e92829c16aa22f20edfdf95f3bb18bb15a3fa226
>>> 90062ad44050a19fc0d5bc846409945e83619b01 M lib
>>> :040000 040000 bbe94bf4af832e154065bc0bcafffab2dacb839e
>>> 1a8be73f86884bda848cde22885bcd72a17660b2 M stdlib
>>> :040000 040000 abf55068f67ee44e2bd52169aa8b988fb8aead28
>>> 41db0f8ddec3281f51c6798dd47c86675b7118b3 M tools
>>>
>>> [1]
>>> https://github.com/apple/swift/commit/c6121d56b19305cf59148d46af54c06b771f3180
>>> [2] https://github.com/apple/swift/pull/1704
>>>
>>>
>>> On Thu, Apr 14, 2016, at 12:36 PM, Jordan Rose wrote:
>>>
>>> +swift-lldb-dev
>>>
>>>
>>> On Apr 14, 2016, at 7:20 , Joseph Bell via swift-dev <swift-dev@swift.org> > >>> wrote:
>>>
>>> Ryan, thanks. I've voted on SR-1109 and will add the steps I use to
>>> reproduce as well.
>>>
>>> I think now its clear why the 14.04 and 15.10 packaging tests are passing,
>>> and that's because they aren't running the tests that leverage pexpect, if
>>> you look at the console log for the 14.04 test:
>>> https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/993/consoleText
>>>
>>> lit.py: lit.cfg:101: note: 'pexpect' module unavailable, skipping related
>>> tests
>>>
>>> Perhaps pexpect should be added to the CI server so these tests can begin
>>> failing properly.
>>>
>>>
>>> On Thu, Apr 14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev > >>> <swift-dev@swift.org> wrote:
>>>
>>>
>>>
>>> On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:
>>>
>>> Howdy,
>>>
>>> I've mentioned this once before and didn't get any feedback; I thought I'd
>>> give it one more shot.
>>>
>>> Has anyone out there tried building, from scratch, the Swift 3.0 package on
>>> Ubuntu? The compile, link, packaging steps all complete successfully, but
>>> then the repl/test-repl-glibc.py fails. The failure is that the REPL
>>> doesn't interact (the underlying script is using pexpect to send/expect)
>>> properly:
>>>
>>> 2> import Glibc
>>> warning: <REPL>:1:1: warning: #line directive is deprecated, please use
>>> #sourceLocation instead
>>> #line 2 "repl.swift"
>>> ^~~~~
>>> #sourceLocation
>>>
>>> warning: repl.swift:3:1: warning: #line directive is deprecated, please use
>>> #sourceLocation instead
>>> #line
>>> ^~~~~
>>> #sourceLocation
>>>
>>> error: repl.swift:2:8: error: missing required module 'SwiftGlibc'
>>> import Glibc
>>>
>>> This is occurring on two separate Ubuntu 14.04 systems, one of which is a
>>> greenfield VM with all of the prerequisites/clang-3.6 installed.
>>>
>>> Stumped on this one and was just curious if anyone can reproduce.
>>>
>>>
>>>
>>> I can also reproduce. I actually broght this up yesterday too (just on a
>>> different list) [1]. I suggest you go vote for SR-1109 [2] which is the bug
>>> report for this issue.
>>>
>>> I think this is show stopper. Not for the REPL break but because it also
>>> breaks the debugger on Linux as well.
>>>
>>> Right now I'm trying to bisect the repos to see which commit(s?) might have
>>> introduced this regression. Kate Stone mentioned that she thinks this issue
>>> was introduced sometime after the 3-16 snapshot. I'm trying to corroborate
>>> that.
>>>
>>> [1]
>>> https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160411/000106.html
>>> [2] https://bugs.swift.org/browse/SR-1109
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>>
>>> ---
>>> http://dev.iachieved.it/iachievedit/
>>> @iachievedit
>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ---
>>> http://dev.iachieved.it/iachievedit/
>>> @iachievedit
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>
>>
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
> _______________________________________________
> swift-lldb-dev mailing list
> swift-lldb-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev


(Joe Bell) #13

Hi all,

Has anyone looked further at getting the REPL working again on the master
branch builds? Or for that matter installed pexpect on the CI server to
properly fail the build?

Joe

···

On Fri, Apr 15, 2016 at 10:13 PM, Ryan Lovelett <swift-dev@ryan.lovelett.me> wrote:

Facepalm.

On Fri, Apr 15, 2016, at 11:11 PM, Ryan Lovelett wrote:
> Progress. Hat tip to William Dillon (@hpux735 on Twitter) for pointing
> something out; `strace`
>
> Ran `strace` on the REPL while trying to import Glibc. Noticed that it
> was looking for a file: /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
> which does not exist. However,
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap does exist.

/usr/lib/swift/linux/x86_64/glibc.modulemap

>
> Provided a symbolic link from
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
> now.

Provided a symbolic link from
/usr/lib/swift/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

>
> I'll start working on a patch in the morning (of course if someone beats
> me to it I won't be mad; please). Just thought I'd update those
> interested with a work around in the meantime.

It is late. I'm clearly done for the day.

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit


(Todd Fiala) #14

Hi Joseph,

I'll poke around at this today and see if I can get this rolling forward
(or at least figure out what we're waiting on).

Thanks for your patience!

-Todd

···

On Tue, Apr 19, 2016 at 8:00 AM, Joseph Bell via swift-lldb-dev < swift-lldb-dev@swift.org> wrote:

Hi all,

Has anyone looked further at getting the REPL working again on the master
branch builds? Or for that matter installed pexpect on the CI server to
properly fail the build?

Joe

On Fri, Apr 15, 2016 at 10:13 PM, Ryan Lovelett < > swift-dev@ryan.lovelett.me> wrote:

Facepalm.

On Fri, Apr 15, 2016, at 11:11 PM, Ryan Lovelett wrote:
> Progress. Hat tip to William Dillon (@hpux735 on Twitter) for pointing
> something out; `strace`
>
> Ran `strace` on the REPL while trying to import Glibc. Noticed that it
> was looking for a file: /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
> which does not exist. However,
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap does exist.

/usr/lib/swift/linux/x86_64/glibc.modulemap

>
> Provided a symbolic link from
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
> now.

Provided a symbolic link from
/usr/lib/swift/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

>
> I'll start working on a patch in the morning (of course if someone beats
> me to it I won't be mad; please). Just thought I'd update those
> interested with a work around in the meantime.

It is late. I'm clearly done for the day.

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

--
-Todd


(Mishal Shah) #15

Hi Joseph,

We are currently reviewing pexpect module with security team, once we have an approval I will install it on swift-ci system.

Thanks,
Mishal shah

···

On Apr 19, 2016, at 8:23 AM, Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:

Hi Joseph,

I'll poke around at this today and see if I can get this rolling forward (or at least figure out what we're waiting on).

Thanks for your patience!

-Todd

On Tue, Apr 19, 2016 at 8:00 AM, Joseph Bell via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
Hi all,

Has anyone looked further at getting the REPL working again on the master branch builds? Or for that matter installed pexpect on the CI server to properly fail the build?

Joe

On Fri, Apr 15, 2016 at 10:13 PM, Ryan Lovelett <swift-dev@ryan.lovelett.me <mailto:swift-dev@ryan.lovelett.me>> wrote:
Facepalm.

On Fri, Apr 15, 2016, at 11:11 PM, Ryan Lovelett wrote:
> Progress. Hat tip to William Dillon (@hpux735 on Twitter) for pointing
> something out; `strace`
>
> Ran `strace` on the REPL while trying to import Glibc. Noticed that it
> was looking for a file: /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
> which does not exist. However,
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap does exist.

/usr/lib/swift/linux/x86_64/glibc.modulemap

>
> Provided a symbolic link from
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
> now.

Provided a symbolic link from
/usr/lib/swift/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is importing
now.

>
> I'll start working on a patch in the morning (of course if someone beats
> me to it I won't be mad; please). Just thought I'd update those
> interested with a work around in the meantime.

It is late. I'm clearly done for the day.

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

--
-Todd
_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-lldb-dev


(Ryan Lovelett) #16

Hi all,

Has anyone looked further at getting the REPL working again on the
master branch builds? Or for that matter installed pexpect on the CI
server to properly fail the build?

@Joe,

Out of curiosity, did the work-around I proposed on Friday work for you?
I've built from master and created the symbolic links and restored
functionality to lldb and the REPL.

If that does work I think that gives me something to work towards for
fixing it permanently.

···

On Tue, Apr 19, 2016, at 11:00 AM, Joseph Bell wrote:

Joe

On Fri, Apr 15, 2016 at 10:13 PM, Ryan Lovelett <swift- > dev@ryan.lovelett.me> wrote:

Facepalm.

On Fri, Apr 15, 2016, at 11:11 PM, Ryan Lovelett wrote:
> Progress. Hat tip to William Dillon (@hpux735 on Twitter) for
> pointing something out; `strace`
>
> Ran `strace` on the REPL while trying to import Glibc. Noticed
> that it was looking for a file:
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap which does not
> exist. However, /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap
> does exist.

/usr/lib/swift/linux/x86_64/glibc.modulemap

>
> Provided a symbolic link from
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap to
> /usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is
> importing now.

Provided a symbolic link from
/usr/lib/swift/linux/x86_64/glibc.modulemap to
/usr/lib/lldb/clang/linux/x86_64/glibc.modulemap. Voila! It is
importing now.

>
> I'll start working on a patch in the morning (of course if someone
> beats me to it I won't be mad; please). Just thought I'd update
> those interested with a work around in the meantime.

It is late. I'm clearly done for the day.

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit