Estebanâs list of blocking issues for release Pharo 6.0
Hi, I wanted to share with you the list of blocking issues I see to do the release :) Image ===== - Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it. Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows). VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are: DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this. VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
I wanted to share with you the list of blocking issues I see to do the release :)
Image =====
- Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it.
Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows).
VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are:
DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne
This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths.
Really?? I thought I had solved that.
Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this.
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
On 24 Mar 2017, at 11:54, Max Leske <maxleske@gmail.com> wrote:
On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
I wanted to share with you the list of blocking issues I see to do the release :)
Image =====
- Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it.
Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows).
VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are:
DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne
This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths.
Really?? I thought I had solved that.
nope :( at the end, the only solution is to ensure those libs are first in âresolutionâ list, and thatâs with an LD_LIBRARY_PATH :( anyway, this is fixed, Iâm just testing it/adapting zeroconf, etc. :) Esteban
Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this.
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
On 24 Mar 2017, at 12:04, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 24 Mar 2017, at 11:54, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
Hi,
I wanted to share with you the list of blocking issues I see to do the release :)
Image =====
- Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it.
Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows).
VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are:
DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne
This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths.
Really?? I thought I had solved that.
nope :( at the end, the only solution is to ensure those libs are first in âresolutionâ list, and thatâs with an LD_LIBRARY_PATH :( anyway, this is fixed, Iâm just testing it/adapting zeroconf, etc. :)
Wow, that sucks! Thanks!
Esteban
Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this.
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes. Maybe this long lasting issue is solve⦠Alexandre
On 24 Mar 2017, at 13:27, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes.
Maybe this long lasting issue is solveâ¦
Iâm aware of this, that was my âsolution to testâ :) but if you can confirm it works, I will commit the image changes Eliot gave me :) Esteban
Alexandre
I will do a couple of more tests. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mar 24, 2017, at 9:53 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 24 Mar 2017, at 13:27, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes.
Maybe this long lasting issue is solveâ¦
Iâm aware of this, that was my âsolution to testâ :) but if you can confirm it works, I will commit the image changes Eliot gave me :)
Esteban
Alexandre
abergel wrote
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes.
Maybe this long lasting issue is solveâ¦
Alexandre
Where can I get this new VM? Is it on files.pharo.org yet? -- View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 24 Mar 2017, at 14:33, webwarrior <reg@webwarrior.ws> wrote:
abergel wrote
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes.
Maybe this long lasting issue is solveâ¦
Alexandre
Where can I get this new VM? Is it on files.pharo.org yet?
yes, if you download latest you should have the fixes. Esteban
-- View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
EstebanLM wrote
Where can I get this new VM? Is it on files.pharo.org yet?
yes, if you download latest you should have the fixes.
Esteban
Tried it. Now Pharo doesn't crash, but merely gives the following error in BitBlt>>copyBits method: Error: Bad BitBlt arg (Fraction?); proceed to convert. I don't see any Fractions, though destX and destY are Floats. If I proceed, image becomes kinda unresponsive, but can be interrupted using alt+. -- View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Try this one: https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_macos32x86_... <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_macos32x86_...> Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mar 24, 2017, at 10:33 AM, webwarrior <reg@webwarrior.ws> wrote:
abergel wrote
Hi!
Image =====
- Cairo surface crash.
I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes.
Maybe this long lasting issue is solveâ¦
Alexandre
Where can I get this new VM? Is it on files.pharo.org yet?
-- View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I wanted to share with you the list of blocking issues I see to do the release :)
Image =====
- Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it.
Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows).
VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are:
DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne
This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this.
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :)
Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files
- No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
Yes please, try stack VM for Win64. The bleeding edge pharo VM are automatically built by appveyor https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_ph...
On 24 Mar 2017, at 14:08, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: Hi,
I wanted to share with you the list of blocking issues I see to do the release :)
Image =====
- Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it.
Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows).
VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are:
DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne
This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this.
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files <https://bintray.com/opensmalltalk/vm/cog/201703222227#files>
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;) Esteban
- No VM for windows. Again, this is a know issue⦠but maybe I can add a StackVM for windows⦠I need to see how is working.
Yes please, try stack VM for Win64. The bleeding edge pharo VM are automatically built by appveyor https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog <https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog> https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_ph... <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_ph...>
On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :)
Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;)
Do you mean build libgit2 standalone? or as part of pharo-vm build? I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it. Standalone... 502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2 526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64 529 cmake --version cmake version 3.0.0 530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 Should I be testing something else? cheers -ben
2017-03-24 17:23 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the
one we are using) for macOS, which makes
impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :)
Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;)
Do you mean build libgit2 standalone? or as part of pharo-vm build?
I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it.
Standalone...
502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2
526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64
529 cmake --version cmake version 3.0.0
530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
Same for me here on OSX 10.11.6 El Capitan, libgit2 builds out of the box, same warning for RPATH Maybe we could reactivate on travis?
Should I be testing something else?
cheers -ben
On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-03-24 17:23 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :)
Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;)
Do you mean build libgit2 standalone? or as part of pharo-vm build?
I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it.
Standalone...
502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2
526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64
529 cmake --version cmake version 3.0.0
530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
Same for me here on OSX 10.11.6 El Capitan, libgit2 builds out of the box, same warning for RPATH Maybe we could reactivate on travis?
Is this relevant regarding using ssh with using libgit ? https://github.com/libgit2/libgit2/issues/2665 cheers -ben
On Sat, Mar 25, 2017 at 8:12 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-03-24 17:23 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :)
Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files
yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;)
Do you mean build libgit2 standalone? or as part of pharo-vm build?
I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it.
Standalone...
502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2
526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64
529 cmake --version cmake version 3.0.0
530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
Same for me here on OSX 10.11.6 El Capitan, libgit2 builds out of the box, same warning for RPATH Maybe we could reactivate on travis?
Is this relevant regarding using ssh with using libgit ? https://github.com/libgit2/libgit2/issues/2665
I'm having trouble with my mac-mini with extended pauses between shell commands so I've not been able to test whether this is relevant, but doing... $ cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur $ ./mvm I see==> tar x -f ../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C builddbg/third-party cd builddbg/third-party/libgit2-0.23.0 \ && cmake \ -DCMAKE_INSTALL_PREFIX=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64 \ -DUSE_SSH=ON \ -DCURL=ON \ -DBUILD_CLAR=OFF \ -DOPENSSL_FOUND=ON \ -DLIBSSH2_FOUND=ON \ -DLIBSSH2_INCLUDE_DIRS=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/include \ -DLIBSSH2_LIBRARIES=/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib \ -DCMAKE_C_FLAGS="-L/usr/lib -L/Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib -lssl -lcrypto -liconv" \ -DCMAKE_OSX_ARCHITECTURES=x86_64 \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-rpath,@executable_path:@executable_path/Plugins \ && make \ && make install -- The C compiler identification is AppleClang 6.0.0.6000056 ... -- checking for module 'libssh2' -- package 'libssh2' not found -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found ---------------- Trying again on its own in a clean dir... 533 cd ~/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party 534 rm -r libgit2-0.23.0 535 tar x -f ../../../../.thirdparty-cache/libgit2-v0.23.0.tar.gz -C . 536 cd libgit2-0.23.0/ 537 cmake ....same...params...as...above I get the same error, -- package 'libssh2' not found but if I up-arrow to run `cmake` again, that message doesn't appear. Maybe its caching the result from the next line from the -- Looking for libssh2_userauth_publickey_frommemory in /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib - found So does that mean SSH ended up found and cmake cached the result? $ make ==> Linking C shared library libgit2.dylib [100%] Built target git2 $ otool -L libgit2.dylib ==> /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/builddbg/third-party/libgit2-0.23.0/libgit2.23.dylib (compatibility version 23.0.0, current version 0.23.0) /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.16) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0) /Users/ben/Repos/PHAROVM/pharo-vm/opensmalltalk-vm/.thirdparty-cache/macOS/x86_64/lib/libssh2.1.dylib (compatibility version 2.0.0, current version 2.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) So does that look like libgit is set up to use ssh okay? ------ btw, I found a related topic... http://stackoverflow.com/questions/32744681/libgit2-and-libssh2-cmake-packag... and here is the quick reference diff... https://www.diffchecker.com/SOGHWKRC So I notice among other things that changes LIBSSH2_INCLUDE_DIRS to LIBSSH2_INCLUDE_DIR, and our build uses -DLIBSSH2_INCLUDE_DIRS thats all I got for now. cheers -ben
participants (6)
-
Alexandre Bergel -
Ben Coman -
Esteban Lorenzano -
Max Leske -
Nicolas Cellier -
webwarrior