Re: [Kicad-developers] [PATCH] correct some snprintf usage
On 22 February 2015 at 03:00, Mark Roszko mark.ros...@gmail.com wrote: Fixes some cases where n-1 bytes was used as a size but snprintf protects against that internally. Also some hardcoded constant sizes changed to sizeof() And made a case where sprintf was used into snprintf as the path input as aUserPluginsPath could in theory be very stupid long if someone has a very stupid filesystem. Would be best if there was error handling if it exceeds ( snprintf will return greater than sizeof(buf) ) but I have no clue how that section needs cleanup. The MinGW compiler uses the Microsoft system version of snprintf which is not C99 compliant. I've attached a fix so that we can use snprintf as per the C99 spec as per your patch. I can't commit it until I can do a test compile to check everything works okay with it. I'll have to wait until I'm home tonight. The proper use of snprintf is much more sane! The MS version is a real pain, it returns -1 if the contents do not fit in the buffer and more importantly it does NOT guarantee to NULL terminate even if it returns a positive result!! Best Regards, Brian. === modified file 'CMakeLists.txt' --- CMakeLists.txt 2015-02-20 13:46:12 + +++ CMakeLists.txt 2015-02-23 11:04:26 + @@ -223,6 +223,10 @@ endif() endif() +# The MinGW compiler can use the microsoft system snprintf as standard and it has a broken +# API with respect to the C99 standard, so make sure we force it to use its own compliant +# snprintf +add_definitions(-D__USE_MINGW_ANSI_STDIO=1) else() # We build DLL/DSOs from static libraries, so create position independent # code for all cases, since we do not have DLL/DSO specific static ___ 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] Mac OS X nightlies are up!
Hello Adam, Garth, and Bernhard, first, the build of last night (r5447) still crashes on my system with the same report pointing towards libpixman. My system is an older Mac Book Pro (middle 2010) with the following base specs: Modellname: MacBook Pro Modell-Identifizierung: MacBookPro7,1 Prozessortyp: Intel Core 2 Duo Prozessorgeschwindigkeit: 2,4 GHz Anzahl der Prozessoren: 1 Gesamtanzahl der Kerne: 2 L2-Cache: 3 MB With libpixman obviously being the source of trouble, I looked for differences between my own working build system and Adam's nightlies: On my machine, pixman comes as a dependency for cairo, which I also installed via Homebrew, but built with the option --without-x11. pixman itself was installed bottled, e.g. as a precompiled binary. Seeing that I am obviously the only one having troubles like this with the nightlies, I will build the current Kicad source tree myself again this afternoon, and see if pcbnew will then crash again or not. Best, Johannes Am 23.02.2015 um 01:41 schrieb Adam Wolf adamw...@feelslikeburning.com: So when I reinstalled it, it installed a binary version without downloading, which means that's very likely what was installed on there before. I forced it to reinstall from source--but that is probably going to be different than the binary version. I will send the build log for pixman over when it is finished, but we will need the affected users to test out tonight's nightlies to make sure they're still affected. Adam Wolf On Sun, Feb 22, 2015 at 6:36 PM, Garth Corral gcor...@abode.com wrote: Yeah, not shipped with OS X. It would be something that was built. Presuming that the new build configured exactly like the old build it would be interesting to see. Garth On Feb 22, 2015, at 3:48 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Interesting. Is this something that comes with OS X? If not, I installed it with brew. I can uninstall it and reinstall it, and capture that log. Let me know. Adam Wolf On Feb 22, 2015 5:47 PM, Garth Corral gcor...@abode.com wrote: More interesting would be the build log for pixman which, according to the attached log, is coming from /usr/local/lib. Garth On Feb 22, 2015, at 3:31 PM, Adam Wolf adamw...@feelslikeburning.com wrote: The builds are being done on a Mac Mini. Model Name: Mac mini Model Identifier: Macmini6,1 Processor Name: Intel Core i5 Processor Speed: 2.5 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Memory: 16 GB The official Mac name for it is Mac Mini (late 2012). Attached is the full build log from Jenkins. Note, I cleanly rebuild *everything* every time, including wx and boost and everything, so the log is quite long. Adam Wolf Cofounder and Engineer WL On Sun, Feb 22, 2015 at 4:13 PM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Sounds reasonable… from a quick look into the source pixman seems to check for MMX/SSE2/SSE3 and some non-x86 things during configure. Maybe the same problem here: https://bugs.launchpad.net/kicad/+bug/1424406 @Adam: What is your build machine/cluster? Regards, Bernhard On 22 Feb 2015, at 21:12, Garth Corral gcor...@abode.com wrote: I can only speculate, but by the looks of that stack, I’m going to guess that somewhere in the pixman rendering code there is conditionally compiled instruction extensions, such as SSE*, that your cpu does not support. The nightly builds probably compile this in based on some configuration test, and your builds do not. What is the cpu type and age of your system? Garth On Feb 22, 2015, at 11:14 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, OK, didn’t get that. From my side there is really not much more to help. The only thing that I could imagine is if Wayne could do a Debug-Build for you and then you could check if you still get that crash and if there is some other information we could get from that. The bundle is self contained, so apart from the system libraries (which should be the same on each 10.10.2) there is in theory nothing on your machine that should break it. What machine is it? Something special about it that could cause pixman to crash on start? Did you have any special pixman version/configuration with your build? Regards, Bernhard On 22.02.2015, at 20:06, Johannes Maibaum jmaib...@gmail.com wrote: Hi Bernard, sorry, I wasn't clear enough, I think. The version information I provided with my last email was *not* from the nightlies. It was from a working built on my machine, e.g. a build that does *not* crash. I thought to provide this information a starting point for further analysis of the crash with the nightly which is of course built with Boost 1.54, and from r5441.
Re: [Kicad-developers] Rendering issues with line drawing
That’s correct, at a minimum (if you want to do your own builds), you need at least wxGTK3 from my copr build (and wxPython3 if you want WXPYTHON enabled). wxGTK3 in the copr build is built against gtk2, which will fix your issue with drawing for now. Now that you’re on f21 you should be able to use that copr repo. Miguel Ángel Ajo On Saturday, 21 de February de 2015 at 10:48, Nick Østergaard wrote: 2015-02-20 23:14 GMT+01:00 Rick Walker wal...@omnisterra.com (mailto:wal...@omnisterra.com): Hi Miguel, But you say need at least fc20 I saw you're running f19. Btw f21 works quite well. Thanks for the suggestion. I used fedup to upgrade from 19 to 21 this morning. I still have the same rendering problem with version 5041. Should I try switching from Normal View to OpenGL as Lorenzo suggested? How do I do this? See the options in the View menu, and try the hotkey F11. But this only fixes it in pcbnew, eeschema will still be buggy. So if you want to use kicad, I reccomend the copr build. If you're on fedora, you have the relevant packages here: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ This will be my project for the afternoon. I'll install the mangelajo build and let you know what happened. The default STABLE build and the default Fedora21 bits don't seem to work properly on my laptop. kind regards, -- Rick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto: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 (mailto: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] [PATCH] correct some snprintf usage
On 2/23/2015 6:07 AM, Brian Sidebotham wrote: On 22 February 2015 at 03:00, Mark Roszko mark.ros...@gmail.com wrote: Fixes some cases where n-1 bytes was used as a size but snprintf protects against that internally. Also some hardcoded constant sizes changed to sizeof() And made a case where sprintf was used into snprintf as the path input as aUserPluginsPath could in theory be very stupid long if someone has a very stupid filesystem. Would be best if there was error handling if it exceeds ( snprintf will return greater than sizeof(buf) ) but I have no clue how that section needs cleanup. The MinGW compiler uses the Microsoft system version of snprintf which is not C99 compliant. I've attached a fix so that we can use snprintf as per the C99 spec as per your patch. I can't commit it until I can do a test compile to check everything works okay with it. I'll have to wait until I'm home tonight. The proper use of snprintf is much more sane! The MS version is a real pain, it returns -1 if the contents do not fit in the buffer and more importantly it does NOT guarantee to NULL terminate even if it returns a positive result!! Best Regards, Brian. Good catch Brian. I knew there was a reason I used sizeof() - 1 and set the last byte to null. It's been a long time since I've looked at the MS documentation for printf and friends. It's hard to believe that bit of information is still rattling around in my head. We probably should just use wxString::Format() and let it take care of the memory management issues in places where performance isn't an issue. Cheers, Wayne ___ 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] Mac OS X nightlies are up!
Hi, I don't know if it helps... I am building pixman with MacPorts, and I used to have it compiled with X11, but I recently switched to use the --without-x11. For me both work, I don't see what the difference is (apart from less X11-libraries needed in the bundle when compiling with --without-x11). SSE-wise Core2Duo and i5 should be the same. But maybe pixman builds with some specific i5 -march/-mcpu settings that don't work on Core2Duo? But, obviously Adam pulled in a prebuilt binary for this nightly that also doesn't work for you. As far as I know homebrew bottled packages should have generic CFLAGS, so this should have worked then (if the binary really was bottled with generic CFLAGS). Regards, Bernhard On 2015-02-23 12:40, Johannes Maibaum wrote: Hello Adam, Garth, and Bernhard, first, the build of last night (r5447) still crashes on my system with the same report pointing towards libpixman. My system is an older Mac Book Pro (middle 2010) with the following base specs: Modellname: MacBook Pro Modell-Identifizierung: MacBookPro7,1 Prozessortyp: Intel Core 2 Duo Prozessorgeschwindigkeit: 2,4 GHz Anzahl der Prozessoren: 1 Gesamtanzahl der Kerne: 2 L2-Cache: 3 MB With libpixman obviously being the source of trouble, I looked for differences between my own working build system and Adam's nightlies: On my machine, pixman comes as a dependency for cairo, which I also installed via Homebrew, but built with the option --without-x11. pixman itself was installed bottled, e.g. as a precompiled binary. Seeing that I am obviously the only one having troubles like this with the nightlies, I will build the current Kicad source tree myself again this afternoon, and see if pcbnew will then crash again or not. Best, Johannes Am 23.02.2015 um 01:41 schrieb Adam Wolf adamw...@feelslikeburning.com: So when I reinstalled it, it installed a binary version without downloading, which means that's very likely what was installed on there before. I forced it to reinstall from source--but that is probably going to be different than the binary version. I will send the build log for pixman over when it is finished, but we will need the affected users to test out tonight's nightlies to make sure they're still affected. Adam Wolf On Sun, Feb 22, 2015 at 6:36 PM, Garth Corral gcor...@abode.com wrote: Yeah, not shipped with OS X. It would be something that was built. Presuming that the new build configured exactly like the old build it would be interesting to see. Garth On Feb 22, 2015, at 3:48 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Interesting. Is this something that comes with OS X? If not, I installed it with brew. I can uninstall it and reinstall it, and capture that log. Let me know. Adam Wolf On Feb 22, 2015 5:47 PM, Garth Corral gcor...@abode.com wrote: More interesting would be the build log for pixman which, according to the attached log, is coming from /usr/local/lib. Garth On Feb 22, 2015, at 3:31 PM, Adam Wolf adamw...@feelslikeburning.com wrote: The builds are being done on a Mac Mini. Model Name: Mac mini Model Identifier: Macmini6,1 Processor Name: Intel Core i5 Processor Speed: 2.5 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Memory: 16 GB The official Mac name for it is Mac Mini (late 2012). Attached is the full build log from Jenkins. Note, I cleanly rebuild *everything* every time, including wx and boost and everything, so the log is quite long. Adam Wolf Cofounder and Engineer WL On Sun, Feb 22, 2015 at 4:13 PM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Sounds reasonable… from a quick look into the source pixman seems to check for MMX/SSE2/SSE3 and some non-x86 things during configure. Maybe the same problem here: https://bugs.launchpad.net/kicad/+bug/1424406 @Adam: What is your build machine/cluster? Regards, Bernhard On 22 Feb 2015, at 21:12, Garth Corral gcor...@abode.com wrote: I can only speculate, but by the looks of that stack, I’m going to guess that somewhere in the pixman rendering code there is conditionally compiled instruction extensions, such as SSE*, that your cpu does not support. The nightly builds probably compile this in based on some configuration test, and your builds do not. What is the cpu type and age of your system? Garth On Feb 22, 2015, at 11:14 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, OK, didn’t get that. From my side there is really not much more to help. The only thing that I could imagine is if Wayne could do a Debug-Build for you and then you could check if you still get that crash and if there is some other information we could get from that. The bundle is self contained, so apart from the system libraries (which should be the same on each 10.10.2) there is in theory nothing on your
Re: [Kicad-developers] Mac OS X nightlies are up!
Hi, my own build of r5447 just finished and pcbnew does *not* crash. I decided to change my build flags to match Adam's more closely, e.g. building without Scripting, here is what the version information *from my own build* gives now: Application: kicad Version: (2015-02-22 BZR 5447)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.57.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF So, the only differences between my setup and the nightly should be, for now: - Boost being 1.57.0 here instead of 1.54.0 - cairo built --without-x11 instead of with X11 support. I think that pixmap should be technically the same on my machine and on Adam's build server, as they both got installed precompiled from Homebrew. But, what came to my mind just now: I built with CMAKE_OSX_DEPLOYMENT_TARGET set to 10.9 (wxWidgets being built with the 10.9 option from the osx_build_wx script as well), so it should be linked to the newer C++ libraries from Apple, right? Could this be another hint? I expect Adam to build for a lower OSX Version, like 10.7 or so, right? Best, Johannes Am 23.02.2015 um 13:54 schrieb Bernhard Stegmaier stegma...@sw-systems.de: Hi, I don't know if it helps... I am building pixman with MacPorts, and I used to have it compiled with X11, but I recently switched to use the --without-x11. For me both work, I don't see what the difference is (apart from less X11-libraries needed in the bundle when compiling with --without-x11). SSE-wise Core2Duo and i5 should be the same. But maybe pixman builds with some specific i5 -march/-mcpu settings that don't work on Core2Duo? But, obviously Adam pulled in a prebuilt binary for this nightly that also doesn't work for you. As far as I know homebrew bottled packages should have generic CFLAGS, so this should have worked then (if the binary really was bottled with generic CFLAGS). Regards, Bernhard On 2015-02-23 12:40, Johannes Maibaum wrote: Hello Adam, Garth, and Bernhard, first, the build of last night (r5447) still crashes on my system with the same report pointing towards libpixman. My system is an older Mac Book Pro (middle 2010) with the following base specs: Modellname: MacBook Pro Modell-Identifizierung: MacBookPro7,1 Prozessortyp: Intel Core 2 Duo Prozessorgeschwindigkeit: 2,4 GHz Anzahl der Prozessoren: 1 Gesamtanzahl der Kerne: 2 L2-Cache: 3 MB With libpixman obviously being the source of trouble, I looked for differences between my own working build system and Adam's nightlies: On my machine, pixman comes as a dependency for cairo, which I also installed via Homebrew, but built with the option --without-x11. pixman itself was installed bottled, e.g. as a precompiled binary. Seeing that I am obviously the only one having troubles like this with the nightlies, I will build the current Kicad source tree myself again this afternoon, and see if pcbnew will then crash again or not. Best, Johannes Am 23.02.2015 um 01:41 schrieb Adam Wolf adamw...@feelslikeburning.com: So when I reinstalled it, it installed a binary version without downloading, which means that's very likely what was installed on there before. I forced it to reinstall from source--but that is probably going to be different than the binary version. I will send the build log for pixman over when it is finished, but we will need the affected users to test out tonight's nightlies to make sure they're still affected. Adam Wolf On Sun, Feb 22, 2015 at 6:36 PM, Garth Corral gcor...@abode.com wrote: Yeah, not shipped with OS X. It would be something that was built. Presuming that the new build configured exactly like the old build it would be interesting to see. Garth On Feb 22, 2015, at 3:48 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Interesting. Is this something that comes with OS X? If not, I installed it with brew. I can uninstall it and reinstall it, and capture that log. Let me know. Adam Wolf On Feb 22, 2015 5:47 PM, Garth Corral gcor...@abode.com wrote: More interesting would be the build log for pixman which, according to the attached log, is coming from /usr/local/lib. Garth On Feb 22, 2015, at 3:31 PM, Adam Wolf adamw...@feelslikeburning.com wrote: The builds are being done on a Mac Mini. Model Name: Mac mini Model Identifier: Macmini6,1 Processor Name: Intel Core i5 Processor Speed: 2.5 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Memory: 16
Re: [Kicad-developers] [PATCH] correct some snprintf usage
You would think that would be the default behavior for a compiler used for cross compilation to avoid opening security holes without realizing. ___ 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] Mac OS X nightlies are up!
The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the same machine you would not see this. In this case there appears at the crash location in _pixman_setup_combiner_functions_32 of libpixman.dylib: 0001092avmovq %r8, %xmm0 0001092fvpunpcklqdq %xmm0, %xmm0, %xmm0 ## xmm0 = xmm0[0,0] These are AVX (AVX2) instructions, which aren't supported in your Core 2 CPU. I don’t use brew so I can’t say for sure, but I’m guessing that it's passing -march=native (or more specific) to the compiler, which because the Core i5 of the build machine supports AVX, is including those instructions. Garth On Feb 23, 2015, at 5:21 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, my own build of r5447 just finished and pcbnew does *not* crash. I decided to change my build flags to match Adam's more closely, e.g. building without Scripting, here is what the version information *from my own build* gives now: Application: kicad Version: (2015-02-22 BZR 5447)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.57.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF So, the only differences between my setup and the nightly should be, for now: - Boost being 1.57.0 here instead of 1.54.0 - cairo built --without-x11 instead of with X11 support. I think that pixmap should be technically the same on my machine and on Adam's build server, as they both got installed precompiled from Homebrew. But, what came to my mind just now: I built with CMAKE_OSX_DEPLOYMENT_TARGET set to 10.9 (wxWidgets being built with the 10.9 option from the osx_build_wx script as well), so it should be linked to the newer C++ libraries from Apple, right? Could this be another hint? I expect Adam to build for a lower OSX Version, like 10.7 or so, right? Best, Johannes Am 23.02.2015 um 13:54 schrieb Bernhard Stegmaier stegma...@sw-systems.de: Hi, I don't know if it helps... I am building pixman with MacPorts, and I used to have it compiled with X11, but I recently switched to use the --without-x11. For me both work, I don't see what the difference is (apart from less X11-libraries needed in the bundle when compiling with --without-x11). SSE-wise Core2Duo and i5 should be the same. But maybe pixman builds with some specific i5 -march/-mcpu settings that don't work on Core2Duo? But, obviously Adam pulled in a prebuilt binary for this nightly that also doesn't work for you. As far as I know homebrew bottled packages should have generic CFLAGS, so this should have worked then (if the binary really was bottled with generic CFLAGS). Regards, Bernhard On 2015-02-23 12:40, Johannes Maibaum wrote: Hello Adam, Garth, and Bernhard, first, the build of last night (r5447) still crashes on my system with the same report pointing towards libpixman. My system is an older Mac Book Pro (middle 2010) with the following base specs: Modellname: MacBook Pro Modell-Identifizierung: MacBookPro7,1 Prozessortyp: Intel Core 2 Duo Prozessorgeschwindigkeit: 2,4 GHz Anzahl der Prozessoren: 1 Gesamtanzahl der Kerne: 2 L2-Cache: 3 MB With libpixman obviously being the source of trouble, I looked for differences between my own working build system and Adam's nightlies: On my machine, pixman comes as a dependency for cairo, which I also installed via Homebrew, but built with the option --without-x11. pixman itself was installed bottled, e.g. as a precompiled binary. Seeing that I am obviously the only one having troubles like this with the nightlies, I will build the current Kicad source tree myself again this afternoon, and see if pcbnew will then crash again or not. Best, Johannes Am 23.02.2015 um 01:41 schrieb Adam Wolf adamw...@feelslikeburning.com: So when I reinstalled it, it installed a binary version without downloading, which means that's very likely what was installed on there before. I forced it to reinstall from source--but that is probably going to be different than the binary version. I will send the build log for pixman over when it is finished, but we will need the affected users to test out tonight's nightlies to make sure they're still affected. Adam Wolf On Sun, Feb 22, 2015 at 6:36 PM, Garth Corral gcor...@abode.com wrote: Yeah, not shipped with OS X. It would be something
Re: [Kicad-developers] Mac OS X nightlies are up!
What's the best arch I should pass for compatibility reasons--I can do this across the board for the brew dependencies. Adam Wolf On Mon, Feb 23, 2015 at 10:04 AM, Garth Corral gcor...@abode.com wrote: The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the same machine you would not see this. In this case there appears at the crash location in _pixman_setup_combiner_functions_32 of libpixman.dylib: 0001092avmovq %r8, %xmm0 0001092fvpunpcklqdq %xmm0, %xmm0, %xmm0 ## xmm0 = xmm0[0,0] These are AVX (AVX2) instructions, which aren't supported in your Core 2 CPU. I don’t use brew so I can’t say for sure, but I’m guessing that it's passing -march=native (or more specific) to the compiler, which because the Core i5 of the build machine supports AVX, is including those instructions. Garth On Feb 23, 2015, at 5:21 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, my own build of r5447 just finished and pcbnew does *not* crash. I decided to change my build flags to match Adam's more closely, e.g. building without Scripting, here is what the version information *from my own build* gives now: Application: kicad Version: (2015-02-22 BZR 5447)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.57.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF So, the only differences between my setup and the nightly should be, for now: - Boost being 1.57.0 here instead of 1.54.0 - cairo built --without-x11 instead of with X11 support. I think that pixmap should be technically the same on my machine and on Adam's build server, as they both got installed precompiled from Homebrew. But, what came to my mind just now: I built with CMAKE_OSX_DEPLOYMENT_TARGET set to 10.9 (wxWidgets being built with the 10.9 option from the osx_build_wx script as well), so it should be linked to the newer C++ libraries from Apple, right? Could this be another hint? I expect Adam to build for a lower OSX Version, like 10.7 or so, right? Best, Johannes Am 23.02.2015 um 13:54 schrieb Bernhard Stegmaier stegma...@sw-systems.de: Hi, I don't know if it helps... I am building pixman with MacPorts, and I used to have it compiled with X11, but I recently switched to use the --without-x11. For me both work, I don't see what the difference is (apart from less X11-libraries needed in the bundle when compiling with --without-x11). SSE-wise Core2Duo and i5 should be the same. But maybe pixman builds with some specific i5 -march/-mcpu settings that don't work on Core2Duo? But, obviously Adam pulled in a prebuilt binary for this nightly that also doesn't work for you. As far as I know homebrew bottled packages should have generic CFLAGS, so this should have worked then (if the binary really was bottled with generic CFLAGS). Regards, Bernhard On 2015-02-23 12:40, Johannes Maibaum wrote: Hello Adam, Garth, and Bernhard, first, the build of last night (r5447) still crashes on my system with the same report pointing towards libpixman. My system is an older Mac Book Pro (middle 2010) with the following base specs: Modellname: MacBook Pro Modell-Identifizierung: MacBookPro7,1 Prozessortyp: Intel Core 2 Duo Prozessorgeschwindigkeit: 2,4 GHz Anzahl der Prozessoren: 1 Gesamtanzahl der Kerne: 2 L2-Cache: 3 MB With libpixman obviously being the source of trouble, I looked for differences between my own working build system and Adam's nightlies: On my machine, pixman comes as a dependency for cairo, which I also installed via Homebrew, but built with the option --without-x11. pixman itself was installed bottled, e.g. as a precompiled binary. Seeing that I am obviously the only one having troubles like this with the nightlies, I will build the current Kicad source tree myself again this afternoon, and see if pcbnew will then crash again or not. Best, Johannes Am 23.02.2015 um 01:41 schrieb Adam Wolf adamw...@feelslikeburning.com: So when I reinstalled it, it installed a binary version without downloading, which means that's very likely what was installed on there before. I forced it to reinstall from source--but that is probably going to be different than the binary version. I will send the build log for pixman over
Re: [Kicad-developers] Mac OS X nightlies are up!
2015-02-23 19:17 GMT+01:00 Bob Gustafson bob...@rcn.com: I wonder whether the idea of the Nightlies is being torn between two goals: 1) Having a system that more or less 'all' Mac users can use. 2) Doing bleeding edge build/tests on the latest repository changes. Those can easily coexist. Tell me why a user installer can't use latest features of the product branch. Doing nightlies is not to test the depends of the system, it is to test features in _kicad_. Testing compatability with different versions of the depends, that is what the diverse group of users (also including those who build themselves, likely with another versiuon of the depends) do and the feedback channel is the bugtracker or mailing list. No conflict of interest here. Also the ci.kicad-pcb.org tries to ensure that at least the latest commits build, and if not alert the developers. Just an observation. Bob G On 02/23/2015 11:42 AM, Adam Wolf wrote: Homebrew has a feature built in for building for oldestmac. I need to figure it out, but this should be fixed in our nightlies in the next few days. I'll let everyone know when our Core 2 users should retest. Thanks everyone! Adam Wolf On Feb 23, 2015 11:31 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: In my Gentoo days I always used -march=core2 (and nothing else except -O2) for CFLAGS on my old Core2Duo machine. There is more to tweak if you want to squeeze out every last option, but in general it should be pretty much OK to use I guess. I never was sure though, if passing a “-march=xxx” via CFLAGS will prevent additional checks used in some configure.sh to use something that the real CPU allows but “-march=xxx” wouldn’t (and you would have to supply additional —disable-xxx flags to configure.sh). Regards, Bernhard On 23 Feb 2015, at 17:58, Adam Wolf adamw...@feelslikeburning.com wrote: More details: https://github.com/Homebrew/homebrew/issues/21778 On Mon, Feb 23, 2015 at 10:56 AM, Adam Wolf adamw...@feelslikeburning.com wrote: I am fine building for Core Duo--but it'll be more than just changing -march, it looks like I'll also have to set the other optional flags as well, like SSE et al at the bottom of: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb Does anyone on this list own a Core Duo mac? If so I'd like to just steal the flags that system uses... Adam Wolf On Mon, Feb 23, 2015 at 10:53 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, sounds all reasonable and clear, Garth. Thank you for the explanation! Personally, I have no problem in building my own version from the sources, but I think there are still quite a bunch of Core2s in Apple machines out there, so perhaps the nightlies should go for a more backwards compatibility than i5 and siblings. Looking here, https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb it seems that Homebrew indeed makes different choices for -march depending on the CPU type found. So, I think the best arch for compatibility then would probably be the oldest intel CPU found there, which seems to be Core Duo. Another solution would of course be to simply state in the README that the nightlies won't work on machines lower than i5. As I said, I have no problem in building Kicad myself. I just wanted to report my experience with the nightlies, which are nonetheless a great improvement for new, unexperienced Mac OSX users. So again, thank you all for your great work and help! Best, Johannes Am 23.02.2015 um 17:22 schrieb Adam Wolf adamw...@feelslikeburning.com: What's the best arch I should pass for compatibility reasons--I can do this across the board for the brew dependencies. Adam Wolf On Mon, Feb 23, 2015 at 10:04 AM, Garth Corral gcor...@abode.com wrote: The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the same machine you would not see this. In this case there appears at the crash location in _pixman_setup_combiner_functions_32 of libpixman.dylib: 0001092avmovq %r8, %xmm0 0001092fvpunpcklqdq %xmm0, %xmm0, %xmm0 ## xmm0 = xmm0[0,0] These are AVX (AVX2) instructions, which aren't supported in your Core 2 CPU. I don’t use brew so I can’t say for sure, but I’m guessing that it's passing -march=native (or more specific) to the compiler, which because the Core i5 of the build machine supports AVX, is including those instructions. Garth On Feb 23, 2015, at 5:21 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, my own build of r5447 just finished and pcbnew does *not* crash. I decided to change my build flags to match Adam's more closely, e.g.
[Kicad-developers] eeschema Preferences
Hi all, I am trying to understand how eeschema gets its preferences (i.e., libraries and library path) on a completely fresh machine that has never seen KiCad before. From the code, I guess it should find a kicad.pro in the default search paths eeschema still uses and shall copy it to some location (common/project.cpp, PROJECT::configCreate): ... // No suitable pro file was found, either does not exist, or not readable. // Use the template kicad.pro file. Find it by using caller's SEARCH_STACK. copy_pro_file_template( aSList, cur_pro_fn ); … If I am right then cur_pro_fn is always an empty string (default parameter from definition), so copy_pro_file_template just does nothing. Then, some default wxFileConfig seems to be created. If I start eeschema on a fresh OS X and add some libraries it seems to creates a file ~/Library/Preferences/eeschema Preferences which looks like a kicad.pro file and has the usual stuff in it (with the added libraries). I don’t know who sets this name “eeschema Preferences”. I didn’t find anything in KiCad and assume it is done by wxWidgets wxFileConfig. First, it is bad that this “eeschema Preferences” file is not in ~/Library/Preferences/kicad where all other KiCad configs are. Second, with my previous installs some kicad.pro file was used, which now doesn’t work any longer (I tried putting it in various paths of the search stack). So, how is initial eeschema preferences supposed to be created and where? I haven’t set any environment variables for KiCad. 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
[Kicad-developers] Thanks to the devs, especially the OS X guys
I just wanted to say thanks to all of the developers working hard on Kicad. I lurk on this list and do as much OS X testing as possible (I do daily builds on two different machines), so I don't contribute as much as the rest of you. I just sent the design files for the second design I've done in Kicad out for fab. The first design came back as expected, and I have no doubt the second design will be fine. Both are two-layer 100 mm x 120 mm boards (fitting into a Hammond extrusion) and were made by Accutrace (pcb4u.com). The next design is a four-layer larger design. It's mostly done (gotta sort out ARM peripheral pin-out assignments still). So just a status report. Keep up the good work -- it is very appreciated. -a ___ 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] Mac OS X nightlies are up!
Hi Johannes, Can you try the build here: http://downloads.kicad-pcb.org/osx/DEBUG/ Please let me know if it is the exact same crash, a different one, or if by some miracle it works :) Thanks! Adam Wolf On Mon, Feb 23, 2015 at 1:00 PM, Nick Østergaard oe.n...@gmail.com wrote: 2015-02-23 19:17 GMT+01:00 Bob Gustafson bob...@rcn.com: I wonder whether the idea of the Nightlies is being torn between two goals: 1) Having a system that more or less 'all' Mac users can use. 2) Doing bleeding edge build/tests on the latest repository changes. Those can easily coexist. Tell me why a user installer can't use latest features of the product branch. Doing nightlies is not to test the depends of the system, it is to test features in _kicad_. Testing compatability with different versions of the depends, that is what the diverse group of users (also including those who build themselves, likely with another versiuon of the depends) do and the feedback channel is the bugtracker or mailing list. No conflict of interest here. Also the ci.kicad-pcb.org tries to ensure that at least the latest commits build, and if not alert the developers. Just an observation. Bob G On 02/23/2015 11:42 AM, Adam Wolf wrote: Homebrew has a feature built in for building for oldestmac. I need to figure it out, but this should be fixed in our nightlies in the next few days. I'll let everyone know when our Core 2 users should retest. Thanks everyone! Adam Wolf On Feb 23, 2015 11:31 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: In my Gentoo days I always used -march=core2 (and nothing else except -O2) for CFLAGS on my old Core2Duo machine. There is more to tweak if you want to squeeze out every last option, but in general it should be pretty much OK to use I guess. I never was sure though, if passing a “-march=xxx” via CFLAGS will prevent additional checks used in some configure.sh to use something that the real CPU allows but “-march=xxx” wouldn’t (and you would have to supply additional —disable-xxx flags to configure.sh). Regards, Bernhard On 23 Feb 2015, at 17:58, Adam Wolf adamw...@feelslikeburning.com wrote: More details: https://github.com/Homebrew/homebrew/issues/21778 On Mon, Feb 23, 2015 at 10:56 AM, Adam Wolf adamw...@feelslikeburning.com wrote: I am fine building for Core Duo--but it'll be more than just changing -march, it looks like I'll also have to set the other optional flags as well, like SSE et al at the bottom of: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb Does anyone on this list own a Core Duo mac? If so I'd like to just steal the flags that system uses... Adam Wolf On Mon, Feb 23, 2015 at 10:53 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, sounds all reasonable and clear, Garth. Thank you for the explanation! Personally, I have no problem in building my own version from the sources, but I think there are still quite a bunch of Core2s in Apple machines out there, so perhaps the nightlies should go for a more backwards compatibility than i5 and siblings. Looking here, https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb it seems that Homebrew indeed makes different choices for -march depending on the CPU type found. So, I think the best arch for compatibility then would probably be the oldest intel CPU found there, which seems to be Core Duo. Another solution would of course be to simply state in the README that the nightlies won't work on machines lower than i5. As I said, I have no problem in building Kicad myself. I just wanted to report my experience with the nightlies, which are nonetheless a great improvement for new, unexperienced Mac OSX users. So again, thank you all for your great work and help! Best, Johannes Am 23.02.2015 um 17:22 schrieb Adam Wolf adamw...@feelslikeburning.com: What's the best arch I should pass for compatibility reasons--I can do this across the board for the brew dependencies. Adam Wolf On Mon, Feb 23, 2015 at 10:04 AM, Garth Corral gcor...@abode.com wrote: The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the same machine you would not see this. In this case there appears at the crash location in _pixman_setup_combiner_functions_32 of libpixman.dylib: 0001092avmovq %r8, %xmm0 0001092fvpunpcklqdq %xmm0, %xmm0, %xmm0 ## xmm0 = xmm0[0,0] These are AVX (AVX2) instructions, which aren't supported in your Core 2 CPU. I don’t use brew so I can’t say for sure, but I’m
Re: [Kicad-developers] 3D Viewer crushes whole KiCAD with this file
On Mon, Feb 23, 2015 at 1:20 AM, Wayne Stambaugh stambau...@gmail.com wrote: COPYRIGHT.txt was meant to be a convenience for devs to copy and paste the license into new source files. If it doesn't match what is in our source files then we should update COPYRIGHT.txt accordingly. I thought it was the same but if not I will update it when I get a chance. COPYRIGHT.txt contains a GPL2-only header. I hope nobody is taking that and pasting it into source files, because that would essentially make distribution of KiCad binaries illegal, since there would be a mix of GPL2-only, GPL2+ and GPL3+ code used to make them. GPL2-only code can only be linked with other GPL2-only code. Cheers, Javier ___ 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] Mac OS X nightlies are up!
On Sat, Feb 21, 2015 at 6:29 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Thanks everyone! Even though this was a lot of work from us at Wayne and Layne, what we did was only a drop in the bucket compared to what has already been done by the dev team and the OS X devs! Adam, congratulations to you and the rest of OS X devs. What you guys have done is amazing, and very useful to many people. Cheers, Javier ___ 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] Mac OS X nightlies are up!
Awesome job!!! ;) Miguel Ángel Ajo On Monday, 23 de February de 2015 at 09:57, Javier Serrano wrote: On Sat, Feb 21, 2015 at 6:29 PM, Adam Wolf adamw...@feelslikeburning.com (mailto:adamw...@feelslikeburning.com) wrote: Thanks everyone! Even though this was a lot of work from us at Wayne and Layne, what we did was only a drop in the bucket compared to what has already been done by the dev team and the OS X devs! Adam, congratulations to you and the rest of OS X devs. What you guys have done is amazing, and very useful to many people. Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto: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] Mac OS X nightlies are up!
Hi Adam, I just tried your build, and it works like a charm. I'm now looking forward to regularly using the Kicad OSX nightlies. Again, thank you for all your effort improving the Kicad experience for OSX users! Best, Johannes Am 23.02.2015 um 22:48 schrieb Adam Wolf adamw...@feelslikeburning.com: Hi Johannes, Can you try the build here: http://downloads.kicad-pcb.org/osx/DEBUG/ Please let me know if it is the exact same crash, a different one, or if by some miracle it works :) Thanks! Adam Wolf On Mon, Feb 23, 2015 at 1:00 PM, Nick Østergaard oe.n...@gmail.com wrote: 2015-02-23 19:17 GMT+01:00 Bob Gustafson bob...@rcn.com: I wonder whether the idea of the Nightlies is being torn between two goals: 1) Having a system that more or less 'all' Mac users can use. 2) Doing bleeding edge build/tests on the latest repository changes. Those can easily coexist. Tell me why a user installer can't use latest features of the product branch. Doing nightlies is not to test the depends of the system, it is to test features in _kicad_. Testing compatability with different versions of the depends, that is what the diverse group of users (also including those who build themselves, likely with another versiuon of the depends) do and the feedback channel is the bugtracker or mailing list. No conflict of interest here. Also the ci.kicad-pcb.org tries to ensure that at least the latest commits build, and if not alert the developers. Just an observation. Bob G On 02/23/2015 11:42 AM, Adam Wolf wrote: Homebrew has a feature built in for building for oldestmac. I need to figure it out, but this should be fixed in our nightlies in the next few days. I'll let everyone know when our Core 2 users should retest. Thanks everyone! Adam Wolf On Feb 23, 2015 11:31 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: In my Gentoo days I always used -march=core2 (and nothing else except -O2) for CFLAGS on my old Core2Duo machine. There is more to tweak if you want to squeeze out every last option, but in general it should be pretty much OK to use I guess. I never was sure though, if passing a “-march=xxx” via CFLAGS will prevent additional checks used in some configure.sh to use something that the real CPU allows but “-march=xxx” wouldn’t (and you would have to supply additional —disable-xxx flags to configure.sh). Regards, Bernhard On 23 Feb 2015, at 17:58, Adam Wolf adamw...@feelslikeburning.com wrote: More details: https://github.com/Homebrew/homebrew/issues/21778 On Mon, Feb 23, 2015 at 10:56 AM, Adam Wolf adamw...@feelslikeburning.com wrote: I am fine building for Core Duo--but it'll be more than just changing -march, it looks like I'll also have to set the other optional flags as well, like SSE et al at the bottom of: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb Does anyone on this list own a Core Duo mac? If so I'd like to just steal the flags that system uses... Adam Wolf On Mon, Feb 23, 2015 at 10:53 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, sounds all reasonable and clear, Garth. Thank you for the explanation! Personally, I have no problem in building my own version from the sources, but I think there are still quite a bunch of Core2s in Apple machines out there, so perhaps the nightlies should go for a more backwards compatibility than i5 and siblings. Looking here, https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb it seems that Homebrew indeed makes different choices for -march depending on the CPU type found. So, I think the best arch for compatibility then would probably be the oldest intel CPU found there, which seems to be Core Duo. Another solution would of course be to simply state in the README that the nightlies won't work on machines lower than i5. As I said, I have no problem in building Kicad myself. I just wanted to report my experience with the nightlies, which are nonetheless a great improvement for new, unexperienced Mac OSX users. So again, thank you all for your great work and help! Best, Johannes Am 23.02.2015 um 17:22 schrieb Adam Wolf adamw...@feelslikeburning.com: What's the best arch I should pass for compatibility reasons--I can do this across the board for the brew dependencies. Adam Wolf On Mon, Feb 23, 2015 at 10:04 AM, Garth Corral gcor...@abode.com wrote: The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the same machine you would not see this. In this case there appears at the crash location in
[Kicad-developers] before filing a bug report/improvement suggestion
I am here to ask for a suggestion before (if ever) filing a bug that could be a matter of personal taste. I found strange tha the kicad project manager have not a hotkey list. I mean, whenever I see a toolbar I think that I do not want to leave the keyboard to just press a button on the screen, having many key under the hands already. I would suggest to create a hotkey for every button on the toolbar, such as p for pcb, c for cvpcb, g for gerberview, e for eeschema and so on. And ? for the hotkey list window, as in the other kicad ancillary programs. And the hotkey window should be (i18n) translated, as it is missing it all the kicad programs, but for this I already filed a bug report, this: https://bugs.launchpad.net/bugs/1424946 what do you think about? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Mac OS X nightlies are up!
Hi folks, We have a user in IRC who tried the debug build I made after installing dependencies with brew with --build-bottle (which forces them to build with older CPU settings), and it works for them. The regular nightlies tonight will pick those up as well. Thanks everyone for the insights! Adam Wolf Cofounder and Engineer WL On Mon, Feb 23, 2015 at 3:48 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Hi Johannes, Can you try the build here: http://downloads.kicad-pcb.org/osx/DEBUG/ Please let me know if it is the exact same crash, a different one, or if by some miracle it works :) Thanks! Adam Wolf On Mon, Feb 23, 2015 at 1:00 PM, Nick Østergaard oe.n...@gmail.com wrote: 2015-02-23 19:17 GMT+01:00 Bob Gustafson bob...@rcn.com: I wonder whether the idea of the Nightlies is being torn between two goals: 1) Having a system that more or less 'all' Mac users can use. 2) Doing bleeding edge build/tests on the latest repository changes. Those can easily coexist. Tell me why a user installer can't use latest features of the product branch. Doing nightlies is not to test the depends of the system, it is to test features in _kicad_. Testing compatability with different versions of the depends, that is what the diverse group of users (also including those who build themselves, likely with another versiuon of the depends) do and the feedback channel is the bugtracker or mailing list. No conflict of interest here. Also the ci.kicad-pcb.org tries to ensure that at least the latest commits build, and if not alert the developers. Just an observation. Bob G On 02/23/2015 11:42 AM, Adam Wolf wrote: Homebrew has a feature built in for building for oldestmac. I need to figure it out, but this should be fixed in our nightlies in the next few days. I'll let everyone know when our Core 2 users should retest. Thanks everyone! Adam Wolf On Feb 23, 2015 11:31 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: In my Gentoo days I always used -march=core2 (and nothing else except -O2) for CFLAGS on my old Core2Duo machine. There is more to tweak if you want to squeeze out every last option, but in general it should be pretty much OK to use I guess. I never was sure though, if passing a “-march=xxx” via CFLAGS will prevent additional checks used in some configure.sh to use something that the real CPU allows but “-march=xxx” wouldn’t (and you would have to supply additional —disable-xxx flags to configure.sh). Regards, Bernhard On 23 Feb 2015, at 17:58, Adam Wolf adamw...@feelslikeburning.com wrote: More details: https://github.com/Homebrew/homebrew/issues/21778 On Mon, Feb 23, 2015 at 10:56 AM, Adam Wolf adamw...@feelslikeburning.com wrote: I am fine building for Core Duo--but it'll be more than just changing -march, it looks like I'll also have to set the other optional flags as well, like SSE et al at the bottom of: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb Does anyone on this list own a Core Duo mac? If so I'd like to just steal the flags that system uses... Adam Wolf On Mon, Feb 23, 2015 at 10:53 AM, Johannes Maibaum jmaib...@gmail.com wrote: Hi, sounds all reasonable and clear, Garth. Thank you for the explanation! Personally, I have no problem in building my own version from the sources, but I think there are still quite a bunch of Core2s in Apple machines out there, so perhaps the nightlies should go for a more backwards compatibility than i5 and siblings. Looking here, https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb it seems that Homebrew indeed makes different choices for -march depending on the CPU type found. So, I think the best arch for compatibility then would probably be the oldest intel CPU found there, which seems to be Core Duo. Another solution would of course be to simply state in the README that the nightlies won't work on machines lower than i5. As I said, I have no problem in building Kicad myself. I just wanted to report my experience with the nightlies, which are nonetheless a great improvement for new, unexperienced Mac OSX users. So again, thank you all for your great work and help! Best, Johannes Am 23.02.2015 um 17:22 schrieb Adam Wolf adamw...@feelslikeburning.com: What's the best arch I should pass for compatibility reasons--I can do this across the board for the brew dependencies. Adam Wolf On Mon, Feb 23, 2015 at 10:04 AM, Garth Corral gcor...@abode.com wrote: The issue here isn’t with pixman, per se, it is down to the fact that it is being configured and built on one machine with support for some newer vector instructions, and run on another who’s cpu does not support those instructions. So long as it’s built and run on the
Re: [Kicad-developers] Thanks to the devs, especially the OS X guys
Thanks everyone! On Mon, Feb 23, 2015 at 4:30 PM, Andy Peters de...@latke.net wrote: I just wanted to say thanks to all of the developers working hard on Kicad. I lurk on this list and do as much OS X testing as possible (I do daily builds on two different machines), so I don't contribute as much as the rest of you. I just sent the design files for the second design I've done in Kicad out for fab. The first design came back as expected, and I have no doubt the second design will be fine. Both are two-layer 100 mm x 120 mm boards (fitting into a Hammond extrusion) and were made by Accutrace (pcb4u.com). The next design is a four-layer larger design. It's mostly done (gotta sort out ARM peripheral pin-out assignments still). So just a status report. Keep up the good work -- it is very appreciated. -a ___ 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
