REPL failed


(Thomas# Chiang) #1

Hi,

I built swift for Linux(openSUSE 13.2) from source code, by
"./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this
platform; use the LLDB-enhanced REPL instead."

since I always failed to build for Debug mode, I need some help to run
REPL,

Thanks.

ccw


(Dmitri Gribenko) #2

Hi Thomas,

To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.

Dmitri

···

On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users <swift-users@swift.org> wrote:

Hi,

I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."

since I always failed to build for Debug mode, I need some help to run REPL,

--
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>*/


(Daniel Dunbar) #3

Dmitri, this seems to be a common problem. What would you think about creating symlinks in the build tree (when building the appropriate projects), just to smooth over the development process?

- Daniel

···

On Dec 6, 2015, at 12:14 AM, Dmitri Gribenko via swift-users <swift-users@swift.org> wrote:

On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users > <swift-users@swift.org> wrote:

Hi,

I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."

since I always failed to build for Debug mode, I need some help to run REPL,

Hi Thomas,

To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.

Dmitri

--
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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Lane Schwartz) #4

I also hit this problem.

I compiled like so: ./swift/utils/build-script --lldb

I created a new directory to house the symlinks:

$ mkdir mybins; cd mybins

I created symlinks:

$ for i in $(ls -1 ../build/Ninja-DebugAssert/llvm-linux-x86_64/bin/*); do
ln -s $i; done
$ for i in $(ls -1 ../build/Ninja-DebugAssert/swift-linux-x86_64/bin/*); do
ln -s $i; done
$ for i in $(ls -1 ../build/Ninja-DebugAssert/lldb-linux-x86_64/bin/*); do
ln -s $i; done

So now there are symlinks in the same directory for lldb and swift.

$ ./swift

LLVM ERROR: Compiler-internal integrated REPL unimplemented for this
platform; use the LLDB-enhanced REPL instead.

And I still get the error. Any thoughts?

Thanks,
Lane

>
> Hi,
>
> I built swift for Linux(openSUSE 13.2) from source code, by

"./utils/build-script -R" command.

> It works for run test.swift file, but can not run on REPL mode,
> the error message is:
> "LLVM ERROR: Compiler-internal integrated REPL unimplemented for this

platform; use the LLDB-enhanced REPL instead."

>
> since I always failed to build for Debug mode, I need some help to run

REPL,

···

On Sun, Dec 6, 2015 at 2:14 AM, Dmitri Gribenko via swift-users < swift-users@swift.org> wrote:

On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users > <swift-users@swift.org> wrote:

Hi Thomas,

To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.

Dmitri

--
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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

--
When a place gets crowded enough to require ID's, social collapse is not
far away. It is time to go elsewhere. The best thing about space travel
is that it made it possible to go elsewhere.
                -- R.A. Heinlein, "Time Enough For Love"


(Daniel Dunbar) #5

Actually, I am retracting this suggestion in favor of what I think is a better one:

What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).

This has a number of benefits:

- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).

Thoughts?

- Daniel

···

On Dec 10, 2015, at 8:43 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

Dmitri, this seems to be a common problem. What would you think about creating symlinks in the build tree (when building the appropriate projects), just to smooth over the development process?

- Daniel

On Dec 6, 2015, at 12:14 AM, Dmitri Gribenko via swift-users <swift-users@swift.org> wrote:

On Sun, Dec 6, 2015 at 12:10 AM, Thomas# Chiang via swift-users >> <swift-users@swift.org> wrote:

Hi,

I built swift for Linux(openSUSE 13.2) from source code, by "./utils/build-script -R" command.
It works for run test.swift file, but can not run on REPL mode,
the error message is:
"LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform; use the LLDB-enhanced REPL instead."

since I always failed to build for Debug mode, I need some help to run REPL,

Hi Thomas,

To run the REPL, the 'swift' and 'lldb' binaries need to be next to
each other. This is not the case in the build tree. Either create a
symlink, or build the package using 'build-script
--preset=buildbot_linux_1404 installable_package=/tmp/swift.tar.gz
install_destdir=/tmp/swift-install', and try again from the package.

Dmitri

--
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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Dmitri Gribenko) #6

My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).

Dmitri

···

On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

Actually, I am retracting this suggestion in favor of what I think is a better one:

What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).

This has a number of benefits:

- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).

Thoughts?

--
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>*/


(Daniel Dunbar) #7

Actually, I am retracting this suggestion in favor of what I think is a better one:

What if we change the build process to build up a "composed package" as part of the regular build. We would clear this at the start of each build, and then build up the installed compiler + libraries + package manager as each project completed its build (basically just using the same install logic into a side location).

This has a number of benefits:

- At the end of the build, we have a "build/<config>/bin" directory which has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for example, the package manager can build with the compiler + xctest as they are expected to look in a package. This would reduce some complexity in our build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into the build process (it just means pointing at a different composed package).

Thoughts?

My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).

My thought here was to use rsync and its options for creating hard links where possible. This makes the copying very cheap...

- Daniel

···

On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:

Dmitri

--
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 <mailto:gribozavr@gmail.com>>*/


(Dmitri Gribenko) #8

How would you implement it in practice? CMake does not know how to
use rsync for its 'install' target, IIRC.

Dmitri

···

On Sun, Dec 20, 2015 at 12:03 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Dec 10, 2015, at 11:07 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Dec 10, 2015 at 9:59 AM, Daniel Dunbar <daniel_dunbar@apple.com> > wrote:

Actually, I am retracting this suggestion in favor of what I think is a
better one:

What if we change the build process to build up a "composed package" as part
of the regular build. We would clear this at the start of each build, and
then build up the installed compiler + libraries + package manager as each
project completed its build (basically just using the same install logic
into a side location).

This has a number of benefits:

- At the end of the build, we have a "build/<config>/bin" directory which
has a functioning compiler.
- Each project in the chain can use the composed build to work with. So for
example, the package manager can build with the compiler + xctest as they
are expected to look in a package. This would reduce some complexity in our
build process, and be more maintainable.
- This solution scales better if/when we add more projects.
- This solution also lets the build easily sub in an "prebuilt package" into
the build process (it just means pointing at a different composed package).

Thoughts?

My concern is that copying files around will significantly increase
the build time for everyone because of I/O. Debug builds of Swift are
quite large (> 700 Mb IIRC).

My thought here was to use rsync and its options for creating hard links
where possible. This makes the copying very cheap...

--
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>*/