Re: [Kicad-developers] OSX Red Blob Bug
Hi Adam, The patch worked fine, and wxWidgets 3.0.2 was built without any trouble on my Macbook Pro with Retina Display and OS X Yosemite. I just finished to build Boost 1.57, so I am going to try to build KiCad with external boost. I wil let you know the result when I have time to run the KiCad build. Thanks again, Jean-Paul AC9GH On Nov 21, 2014, at 11:00 PM, Adam Wolf adamww...@gmail.com wrote: Hi Wayne, If you could replace the patch in the patches directory with the patch in the message I am replying to, that'd be great. Please let me know if you have any questions. Thanks! Adam Wolf On Sun, Nov 16, 2014 at 11:44 AM, Adam Wolf adamww...@gmail.com wrote: Alright. Third time's the charm, folks. This patch is the actual file that belongs inside of patches/. There's probably a good adage for easy things being harder than hard things. It's applicable here :) Adam Wolf Cofounder and Engineer WL On Sun, Nov 16, 2014 at 11:36 AM, Adam Wolf adamww...@gmail.com wrote: I have 20 minutes before I have to head out--let's see if third time's the charm. Adam Wolf On Sun, Nov 16, 2014 at 11:35 AM, Jean-Paul Louis lou...@yahoo.com wrote: Thank you Adam and Bernhard. I will start upgrading to Yosemite, so I might not be checking the list for a while. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 12:32 PM, Adam Wolf adamww...@gmail.com wrote: I have been building and using Kicad on 10.10 for a few weeks now. There's one patch that needs to be added, that may or may not be properly added into the tree--I need to doublecheck again. Adam Wolf On Sun, Nov 16, 2014 at 11:29 AM, Jean-Paul Louis lou...@yahoo.com wrote: Hi Bernhard, I plan to upgrade my OS X to Yosemite. Can you confirm that KiCad will build properly under OS X 10.10? Is there anything that I need to be aware of when upgrading the toolchain? Any advice is welcome as I am nowhere near an OS X guru. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 11:34 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, I would change things in a way that the builtin CMAKE_OSX_DEPLOYMENT_TARGET variable of CMake is used everywhere and that it has to be set during configuration. So, everybody can set things as he/she wants… The only thing that everyone has to take care is that all dependencies are built wit matching settings… but that’s something that cannot be tackled by KiCad build process anyway. Regards, Bernhard On 16.11.2014, at 17:27, Adam Wolf adamww...@gmail.com wrote: Awesome work folks! 1) I think it's silly to try to debug this further if I can fix it by setting a package for 10.7 and newer. 2) I believe 10.6 no longer gets security updates as of Feb. Do we really need to make one for 10.6? My gut feelings says I should make my packages for 10.7 and newer, and if people complain and want a package for 10.6, maybe investigate making one then. I don't know if any of the devs have a 10.6 machine to test on--I certainly don't! Thoughts? (This may be the last blocker bug of any difficulty. Docs and libraries included are the last two I know of, but they will be straightforward. Great work!) On Nov 16, 2014 5:10 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier
[Kicad-developers] OSX Red Blob Bug
Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So, can anyone confirm (1) if problem is still there with latest revision? (2) it goes away if you rebuild KiCad wxWidgets and change every “-mmacosx-min-version=10.5” in KiCad CMake files to something more recent (probably 10.9 or 10.10, AFAIK libc++ was default starting with 10.8) and remove any -stdlib=libstdc++” (it used when configuring wxWidgets if you use the supplied script)? If it is confirmed that this is due to mixing libc++/libstdc++ I will change build process in a way that you can specify which OSX version is targeted… Regards, Bernhard ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OSX Red Blob Bug
Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So, can anyone confirm (1) if problem is still there with latest revision? (2) it goes away if you rebuild KiCad wxWidgets and change every “-mmacosx-min-version=10.5” in KiCad CMake files to something more recent (probably 10.9 or 10.10, AFAIK libc++ was default starting with 10.8) and remove any -stdlib=libstdc++” (it used when configuring wxWidgets if you use the supplied script)? If it is confirmed that this is due to mixing libc++/libstdc++ I will change build process in a way that you can specify which OSX version is targeted… Regards, Bernhard ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OSX Red Blob Bug
Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So, can anyone confirm (1) if problem is still there with latest revision? (2) it goes away if you rebuild KiCad wxWidgets and change every “-mmacosx-min-version=10.5” in KiCad CMake files to something more recent (probably 10.9 or 10.10, AFAIK libc++ was default starting with 10.8) and remove any -stdlib=libstdc++” (it used when configuring wxWidgets if you use the supplied script)? If it is confirmed that this is due to mixing libc++/libstdc++ I will change build process in a way that you can specify which OSX version is targeted… Regards, Bernhard ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OSX Red Blob Bug
Hi, I would change things in a way that the builtin CMAKE_OSX_DEPLOYMENT_TARGET variable of CMake is used everywhere and that it has to be set during configuration. So, everybody can set things as he/she wants… The only thing that everyone has to take care is that all dependencies are built wit matching settings… but that’s something that cannot be tackled by KiCad build process anyway. Regards, Bernhard On 16.11.2014, at 17:27, Adam Wolf adamww...@gmail.com wrote: Awesome work folks! 1) I think it's silly to try to debug this further if I can fix it by setting a package for 10.7 and newer. 2) I believe 10.6 no longer gets security updates as of Feb. Do we really need to make one for 10.6? My gut feelings says I should make my packages for 10.7 and newer, and if people complain and want a package for 10.6, maybe investigate making one then. I don't know if any of the devs have a 10.6 machine to test on--I certainly don't! Thoughts? (This may be the last blocker bug of any difficulty. Docs and libraries included are the last two I know of, but they will be straightforward. Great work!) On Nov 16, 2014 5:10 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com mailto:gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So, can anyone confirm (1) if problem is still there with latest revision? (2) it goes away if you rebuild KiCad wxWidgets and change every “-mmacosx-min-version=10.5” in KiCad CMake files to something more recent (probably 10.9 or 10.10, AFAIK libc++ was default starting with 10.8) and remove any -stdlib=libstdc++” (it used when configuring wxWidgets if you use the supplied script)? If it is confirmed that this is due to mixing libc++/libstdc++ I will change build process in a way that you can specify which OSX version is targeted… Regards, Bernhard ___ Mailing list: https://launchpad.net/~kicad-developers https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe :
Re: [Kicad-developers] OSX Red Blob Bug
Hi Bernhard, I plan to upgrade my OS X to Yosemite. Can you confirm that KiCad will build properly under OS X 10.10? Is there anything that I need to be aware of when upgrading the toolchain? Any advice is welcome as I am nowhere near an OS X guru. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 11:34 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, I would change things in a way that the builtin CMAKE_OSX_DEPLOYMENT_TARGET variable of CMake is used everywhere and that it has to be set during configuration. So, everybody can set things as he/she wants… The only thing that everyone has to take care is that all dependencies are built wit matching settings… but that’s something that cannot be tackled by KiCad build process anyway. Regards, Bernhard On 16.11.2014, at 17:27, Adam Wolf adamww...@gmail.com wrote: Awesome work folks! 1) I think it's silly to try to debug this further if I can fix it by setting a package for 10.7 and newer. 2) I believe 10.6 no longer gets security updates as of Feb. Do we really need to make one for 10.6? My gut feelings says I should make my packages for 10.7 and newer, and if people complain and want a package for 10.6, maybe investigate making one then. I don't know if any of the devs have a 10.6 machine to test on--I certainly don't! Thoughts? (This may be the last blocker bug of any difficulty. Docs and libraries included are the last two I know of, but they will be straightforward. Great work!) On Nov 16, 2014 5:10 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So, can anyone confirm (1) if problem is still there with latest revision? (2) it goes away if you rebuild KiCad wxWidgets and change every “-mmacosx-min-version=10.5” in KiCad CMake files to something more recent (probably 10.9 or 10.10, AFAIK libc++ was default starting with 10.8) and remove any -stdlib=libstdc++” (it used when configuring wxWidgets if you use the supplied script)? If it is confirmed that this is due to mixing libc++/libstdc++ I will change build process in a way that you can specify which OSX version is targeted… Regards, Bernhard
Re: [Kicad-developers] OSX Red Blob Bug
Me, too. No problems except for the one patch for wxWidgets Adam mentioned. Adam, the patch is still broken in the tree… I tried yesterday and it doesn’t work. Regards, Bernhard On 16.11.2014, at 18:32, Adam Wolf adamww...@gmail.com wrote: I have been building and using Kicad on 10.10 for a few weeks now. There's one patch that needs to be added, that may or may not be properly added into the tree--I need to doublecheck again. Adam Wolf On Sun, Nov 16, 2014 at 11:29 AM, Jean-Paul Louis lou...@yahoo.com mailto:lou...@yahoo.com wrote: Hi Bernhard, I plan to upgrade my OS X to Yosemite. Can you confirm that KiCad will build properly under OS X 10.10? Is there anything that I need to be aware of when upgrading the toolchain? Any advice is welcome as I am nowhere near an OS X guru. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 11:34 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: Hi, I would change things in a way that the builtin CMAKE_OSX_DEPLOYMENT_TARGET variable of CMake is used everywhere and that it has to be set during configuration. So, everybody can set things as he/she wants… The only thing that everyone has to take care is that all dependencies are built wit matching settings… but that’s something that cannot be tackled by KiCad build process anyway. Regards, Bernhard On 16.11.2014, at 17:27, Adam Wolf adamww...@gmail.com mailto:adamww...@gmail.com wrote: Awesome work folks! 1) I think it's silly to try to debug this further if I can fix it by setting a package for 10.7 and newer. 2) I believe 10.6 no longer gets security updates as of Feb. Do we really need to make one for 10.6? My gut feelings says I should make my packages for 10.7 and newer, and if people complain and want a package for 10.6, maybe investigate making one then. I don't know if any of the devs have a 10.6 machine to test on--I certainly don't! Thoughts? (This may be the last blocker bug of any difficulty. Docs and libraries included are the last two I know of, but they will be straightforward. Great work!) On Nov 16, 2014 5:10 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com mailto:gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything
Re: [Kicad-developers] OSX Red Blob Bug
Thank you Adam and Bernhard. I will start upgrading to Yosemite, so I might not be checking the list for a while. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 12:32 PM, Adam Wolf adamww...@gmail.com wrote: I have been building and using Kicad on 10.10 for a few weeks now. There's one patch that needs to be added, that may or may not be properly added into the tree--I need to doublecheck again. Adam Wolf On Sun, Nov 16, 2014 at 11:29 AM, Jean-Paul Louis lou...@yahoo.com wrote: Hi Bernhard, I plan to upgrade my OS X to Yosemite. Can you confirm that KiCad will build properly under OS X 10.10? Is there anything that I need to be aware of when upgrading the toolchain? Any advice is welcome as I am nowhere near an OS X guru. Regards, Jean-Paul AC9GH On Nov 16, 2014, at 11:34 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, I would change things in a way that the builtin CMAKE_OSX_DEPLOYMENT_TARGET variable of CMake is used everywhere and that it has to be set during configuration. So, everybody can set things as he/she wants… The only thing that everyone has to take care is that all dependencies are built wit matching settings… but that’s something that cannot be tackled by KiCad build process anyway. Regards, Bernhard On 16.11.2014, at 17:27, Adam Wolf adamww...@gmail.com wrote: Awesome work folks! 1) I think it's silly to try to debug this further if I can fix it by setting a package for 10.7 and newer. 2) I believe 10.6 no longer gets security updates as of Feb. Do we really need to make one for 10.6? My gut feelings says I should make my packages for 10.7 and newer, and if people complain and want a package for 10.6, maybe investigate making one then. I don't know if any of the devs have a 10.6 machine to test on--I certainly don't! Thoughts? (This may be the last blocker bug of any difficulty. Docs and libraries included are the last two I know of, but they will be straightforward. Great work!) On Nov 16, 2014 5:10 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Yes, sounds reasonable… I was wrong about 10.8, libc++ seems to be there since 10.7. I found a report of one guy having problems with a binary linked against libstdc++ because some system libs pulled in libc++. He was able to find out the exact class/type which caused the problem. He reported it to Apple, it was considered a bug because it should be compatible, and it got fixed quite some while later. Doing the same will be quite painful I guess, because we have so many (foreign) things using C++… wxWidgets, boost, etc. So, I guess the easiest way to fix this for now is to ensure everything is built with the same min version (or standard C++ lib I guess). Moreover… I guess that at some point in time Apple probably will drop libstdc++ support anyway… so the effort of providing in worst case two packages (one for 10.7 and another for 10.7) will be much less than trying to fix that now. That’s something that has most impact on Adam and the upcoming automated builds... Regards, Bernhard On 16.11.2014, at 10:43, Garth Corral gcor...@abode.com wrote: Interesting. When I had replied in the past that I was unable to reproduce this, I had been building with a local patch that set macosx-version-min to 10.7 for everything. When I read this I tried building again without that patch and sure enough, red blob. When I rebuilt with version-min set to 10.7 it went away again. Garth On Nov 16, 2014, at 12:41 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi OSX guys, do you still see the red blob bug” in latest revisions (since yesterday)? I still had it in all the builds I made, the last revision I built was 5263, and it was in there. When I switched to external boost for the avhttp tests (this build has the red blob problem) I noticed that my boost (from MacPorts) was compiled against libc++, whereas wxWidgets and KiCad itself was built against libstdc++. This is how it is forced in KiCad CMake (via —mmacosx-min-version which implicitly sets used C++ standard library) and in the wxWidgets configuration I use. Although common sense seems to be “if it compiles/links fine, it will work” I know from problems at work that mixing standard C++ libraries in one binary can lead to very weird problems. Mixing libs is often not obvious, because different versions can be pulled in by any indirect library dependency in the whole dependency chain. So, I pulled to head yesterday and made some small changes to build everything (KiCad and wxWidgets) with minimum OSX version 10.9 which selects libc++… just to see what happens. Built fine, I did my usual tests and I was quite surprised that the red blob problem was gone! So,
