| 00:19.54 | *** join/#brlcad infobot (ibot@rikers.org) |
| 00:19.54 | *** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;) |
| 00:32.44 | *** join/#brlcad edpetmxmrjwmfzrj (~armin@dslb-088-067-249-032.088.067.pools.vodafone-ip.de) |
| 02:01.37 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:19.25 | DaRock | starseeker: how does it find TERMLIB_LIBRARY? What is it looking for exactly? |
| 06:54.37 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 06:55.14 | *** join/#brlcad DaRock1 (~Thunderbi@mail.unitedinsong.com.au) |
| 07:27.12 | *** join/#brlcad elpea (~chatzilla@dsl-hkibrasgw5-58c04d-211.dhcp.inet.fi) |
| 08:17.19 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 09:26.45 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) |
| 11:13.30 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) |
| 11:29.37 | DaRock | starseeker: I'm spinning here, can't quite get my head around it. FindTERMLIB has some real quirks in it - I don't get the cmake stuff enough yet, but what appears to be happening is I get successes and finally a fail on a missing LIBTERM_INCLUDE_DIR. What I don't get is where the fail is happening exactly |
| 11:33.24 | DaRock | starseeker: and here's why - firstly, the variable is set (correctly); and secondly, the logs indicate yet a different issue entirely. When it runs a test compile to see all is well, it still looks for libterm! And it succeeds as far as I can tell. I ran the compile manually myself to see - couldn't do the cmake particular stuff though so maybe thats the failure. BSD has libtermlib.so so thats probably why |
| 11:35.08 | DaRock | starseeker: so if its in the system already, there'd be no need for the builtin anyway - except it can't seem to find it. But I'll buggered if I can figure out a patch yet :) |
| 11:41.26 | DaRock | starseeker: actually one thing has struck me - I don't see anywhere that the automation can even be overridden. It looks like it ignores any input in that area and _only_ tries to determine it itself. Which might explain why it finds the system termlib and goes with it - but doesn't check the others - and then failure means it fallsback to the builtin. But why the fail when everything seems to succeed? |
| 11:42.53 | DaRock | starseeker: last piece of info, that I'm not sure about and have little to go on with, is in the logs after the last test compile it states a return value of 1, not succeed or anything |
| 11:43.25 | d_rossberg | DaRock: but does the libtermlib.so in BSD come with the development (aka header) files? |
| 11:44.08 | DaRock | any chance you could quickly tell me the header file for it? :) |
| 11:44.30 | d_rossberg | to enable the termlib which comes with brl-cad you have to set BRLCAD_TERMLIB to BOUNDLED |
| 11:44.36 | *** join/#brlcad elpea (~chatzilla@dsl-hkibrasgw5-58c04d-211.dhcp.inet.fi) |
| 11:44.57 | DaRock | not the aim atm |
| 11:44.57 | d_rossberg | sorry BUNDLED |
| 11:45.43 | d_rossberg | is the termlib in the base system or a package? |
| 11:45.56 | DaRock | I have term.h, termios.h, termcap.h, ncurses.h, curses.h, .... |
| 11:46.01 | DaRock | base |
| 11:48.01 | DaRock | but if it has the lib, it usually has the header - just not sure which that is right now |
| 11:48.26 | DaRock | and ncurses-curses are the same here |
| 11:49.58 | DaRock | d_rossberg: I'll also point out that building tests works fine for termlib according to the logs and my own compilation btw |
| 11:50.14 | DaRock | so the headers must be found |
| 11:50.47 | d_rossberg | is just looking in the BRL-CAD sources for a termlib header, couldn't fine one yet |
| 11:50.58 | DaRock | lol |
| 11:51.09 | DaRock | what do you know of cmake, then? |
| 11:55.14 | d_rossberg | it looks like you need termcap.h |
| 11:55.50 | DaRock | can you see if there's any reference to user set variables having any effect here? ie I should be able to set TERMLIB_LIBRARY or TERMLIB_INCLUDE_DIR and it should honor those |
| 11:55.59 | DaRock | sorry - file is misc/CMake/FindTERMLIB.cmake |
| 11:58.33 | DaRock | it also doesn't appear to set any variables (particularly those 2 mentioned) once found - so when it runs that final check... failure |
| 11:59.30 | DaRock | no include is set, so it may as well play pong for a bit, then continue with the builtin anyway |
| 12:00.07 | ``Erik | DaRock: a lot of cmake info is shoved to stdout and never saved anywhere, it might offer a clue if you rm -rf'd your build dir and ran cmake >> logfile |
| 12:00.43 | ``Erik | (I think termlib might only be used in a couple weird places, like nirt and burst... not sure on that, though) |
| 12:01.26 | DaRock | ``Erik: and a lot is not output, and is only found in the logs - I'm reading both. But that misc/CMake/FindTERMLIB.cmake file is _definitely_ faulty |
| 12:04.52 | DaRock | ``Erik: stdout - -- Found ZLIB: /usr/include |
| 12:04.52 | DaRock | -- Found LEMON: /usr/local/brlcad/bin/lemon |
| 12:04.52 | DaRock | -- Found RE2C: /usr/local/brlcad/bin/re2c |
| 12:04.52 | DaRock | -- Found XSLTPROC: /usr/local/bin/xsltproc |
| 12:04.52 | DaRock | -- Looking for tputs in termlib |
| 12:04.52 | DaRock | -- Looking for tputs in termlib - found |
| 12:04.52 | DaRock | -- Performing Test LIBTERM_RESULT |
| 12:04.53 | DaRock | -- Performing Test LIBTERM_RESULT - Success |
| 12:04.53 | DaRock | -- Could NOT find TERMLIB (missing: TERMLIB_INCLUDE_DIR) |
| 12:04.54 | DaRock | CMake Warning at CMakeLists.txt:480 (_message): |
| 12:04.54 | DaRock | <PROTECTED> |
| 12:04.55 | DaRock | <PROTECTED> |
| 12:04.55 | DaRock | Call Stack (most recent call first): |
| 12:04.56 | DaRock | <PROTECTED> |
| 12:05.00 | ``Erik | hm, yeah, it's using bundled on one of my bsd boxen, :/ |
| 12:05.36 | DaRock | probably all. same port after all - same here :) |
| 12:05.55 | DaRock | this all began from a png fault... |
| 12:06.16 | DaRock | then a conflict with tk/tcl |
| 12:07.19 | DaRock | the bandaid fix is to allow all bundled... but that just increases dist size, increased chance of conflicts (ie tk) |
| 12:08.11 | DaRock | apparently its simply going to fail unless you use bundled - which is ok for average user who wants it to work out the box, but if you're a porter or packager... |
| 12:09.35 | DaRock | ``Erik: btw - urt is not a dependency afaict. There is no need to deprecate the port because urt is builtin - and in fact probably been ignoring the dependent port anyway :) |
| 12:10.45 | DaRock | but that gets us back to this builtin issue - we should be able to choose system if wanted and add builtins only if needed (like urt) |
| 12:12.27 | DaRock | ``Erik: can you run a test for me? Comment out the urt under LIB_DEPENDS and see if it builds - you might be quicker on the resolve there |
| 12:12.40 | DaRock | and runs, mind |
| 12:19.39 | DaRock | so does anyone know enough about the cmake system to see what needs to change? Honoring overrides, whether the variables are properly set, etc? |
| 12:23.36 | d_rossberg | i'm using the cmake-gui, there i see all the parameters and can play with them (e.g. trying to set TERMLIB_INCLUDE_DIR to /usr/include) |
| 12:25.07 | DaRock | does that let you see them during build? Or only prior? |
| 12:26.03 | DaRock | I don't see anywhere in FindTERMLIB.cmake where that variable is set |
| 12:26.26 | d_rossberg | before and after the cmake run, the log messages of the runs are shown in the gui too |
| 12:26.30 | DaRock | I see it says it can be set, but doesn't check it or set it itself |
| 12:26.46 | DaRock | sounds useful :) |
| 12:27.03 | d_rossberg | FIND_PACKAGE_HANDLE_STANDARD_ARGS() should set TERMLIB_INCLUDE_DIR |
| 12:27.41 | DaRock | How? I thought it only checked it was valid? |
| 12:28.00 | DaRock | afaict thats the fail point |
| 12:28.15 | DaRock | it isn't set, so that macro fails |
| 12:29.24 | DaRock | or have I misread the docs on that one? |
| 12:30.09 | DaRock | that macro fails, then the build fallsback to builtin termlib |
| 12:30.26 | DaRock | I'm installing cmake-gui now :) |
| 12:32.24 | d_rossberg | is just checking the FIND_PACKAGE_HANDLE_STANDARD_ARGS() |
| 12:37.24 | DaRock | I'm a newb at cmake, so tell me if I'm wrong. I read the logic as include some macros, create a new macro that checks header files for a func and validates the include dir and sets the link opts, then runs a series of checks of different terminal/cursor libraries for tputs. (does absolutely nothing with this info) It then starts to setup a test env, and backs up the required libs variable, then sets it to the termlib_Library |
| 12:38.07 | DaRock | runs a quick compile test, and grabs the result |
| 12:38.20 | DaRock | can't figure out the mark_as_advanced yet |
| 12:39.15 | DaRock | then runs Find_Package_Handle_Standard_Args which determines if the library exists, and if the include dir exists |
| 12:42.29 | DaRock | d_rossberg: so how does cmake-gui work then? |
| 12:45.12 | d_rossberg | just call cmake-gui, set the build directory there (the souce directory should be automatically set then), and hit configure |
| 12:54.30 | d_rossberg | as far as i can see the THIRD_PARTY macro (defined in misc/CMake/ThirdParty.cmake) in src/other/CMakeLists.txt line 211 should find and set the TERMLIB_INCLUDE_DIR |
| 13:03.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:12.57 | d_rossberg | DaRock: the bug seams to be in THIRD_PARTY() it doesnt set the _INCLUDE_DIR for system libraries at all |
| 13:13.56 | DaRock | actually yeah, now that you mention it I didn't see anything either. I'm still trying to process it myself |
| 13:14.49 | DaRock | That's one bug. I'm wondering if the FORCE is making it only use termlib as well. |
| 13:15.46 | DaRock | but shouldn't that be something that can be overridden anyway? |
| 13:16.03 | DaRock | so why not honor it? |
| 13:17.17 | DaRock | or is it only ever going to do things automatically? |
| 13:23.22 | DaRock | so would I be right in saying that set(TERMLIB_INCLUDE_DIR "/usr/include") should be used after/in the if(BRLCAD_TERMLIB_BUILD) statement? |
| 13:23.36 | d_rossberg | the FORCE shouldn't be the problem |
| 13:24.03 | d_rossberg | TERMLIB_INCLUDE_DIR should be an empty string, i.e. no special directory |
| 13:24.14 | DaRock | why? |
| 13:24.17 | d_rossberg | if that's valid ... |
| 13:24.51 | d_rossberg | /usr/include will always be recognized |
| 13:24.56 | DaRock | actually, that is practically forcing the use of termcap - why bother checking ncurses then? |
| 13:25.09 | DaRock | not atm... |
| 13:25.25 | DaRock | and that's why I'm having trouble I think |
| 13:26.31 | DaRock | there is no honoring cli input or env vars - its not even checking. The it simply sets its own - /and/ fails |
| 13:27.02 | DaRock | finally falling back to the bundled for no good reason |
| 13:28.22 | DaRock | is there anyway to test the FIND_PACKAGE_HANDLE_STANDARD_ARGS separately? |
| 13:32.46 | d_rossberg | THIRD_PARTY() is the one which should be fixed, i think; just looking at it |
| 13:33.20 | DaRock | ok, just ran the build with an adjustment to FIND_PACKAGE_.... blah blah (tired of typing that out :) ) by using an empty string instead of the include dirs and it succeeded |
| 13:36.57 | DaRock | it fails on /usr/include. Weird... |
| 13:39.23 | DaRock | d_rossberg: so how do we fix it then? use a set()? Check for user set variables? |
| 13:39.31 | *** join/#brlcad yorik (~yorik@2804:431:f721:afd0:290:f5ff:fedc:3bb2) |
| 13:44.26 | d_rossberg | as i've said: i'm just looking at it ;) |
| 13:45.33 | DaRock | why all the redundant checks btw? It looks like it checks basically the same thing at least 3 ways... |
| 13:47.12 | DaRock | LOL! I just checked and unless you have an empty string as the last arg it will always fail! |
| 13:49.34 | DaRock | and again, why is that check needed anyway? It only checks if the include dir exists, and that has already been checked at least twice before! |
| 13:56.02 | DaRock | fwiw I think FORCE shouldn't be in the set() there already |
| 13:57.12 | DaRock | and if the test always fails anyway, I'm not sure TERMLIB_INCLUDE_DIR should even be set |
| 14:04.00 | d_rossberg | lol indeed, the macro in FindTERMLIB.cmake is called from THIRD_PARTY() before it's able to set TERMLIB_INCLUDE_DIR to any meaningful value |
| 14:05.17 | d_rossberg | FORCE and CACHE together in a set command are depricated, that's true, but not forbidden |
| 14:07.12 | d_rossberg | however, there are mor obvious issues here than the FORCE (which prevents you from hacking it) |
| 14:11.48 | DaRock | FORCE overrides any user set vars, right? |
| 14:12.48 | DaRock | for starters TERMLIB_INCLUDE_DIR is never set AFAICT |
| 14:13.08 | DaRock | secondly, any value in the last arg will cause a failure |
| 14:13.22 | DaRock | and why is it needed at all anyway? :) |
| 14:13.52 | DaRock | other than that, whats the more obvious issues? lol |
| 14:32.01 | d_rossberg | DaRock: include the line "find_path(TERMLIB_INCLUDE_DIR NAMES termcap.h PATH_SUFFIXES include)" somewhere in FindTERMLIB.cmake before the FIND_PACKAGE_HANDLE_STANDARD_ARGS() and test it again |
| 14:34.15 | d_rossberg | using the standard FindZLIB.cmake as reference it looks like it is in the responsibility of the find macro to set the include directory |
| 14:34.47 | DaRock | theres a find_path(TERMLIB_INCLUDE_DIR ${lname}.h) in the macro found there already. I didn't realise that set anything though |
| 14:35.34 | DaRock | but that of course doesn't include the PATH_SUFFIXES include |
| 14:37.55 | DaRock | should I simply change the current find_path line? |
| 14:38.42 | d_rossberg | ? where did you found the find_path? |
| 14:39.03 | DaRock | in FindTERMLIB.cmake |
| 14:39.15 | DaRock | around 41 |
| 14:44.35 | d_rossberg | and which revision? i can't find it here: https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/FindTERMLIB.cmake |
| 14:44.35 | gcibot_ | [ BRL-CAD / Code / [r69674] /brlcad/trunk/misc/CMake/FindTERMLIB.cmake ] |
| 14:45.55 | d_rossberg | however, find_path(TERMLIB_INCLUDE_DIR termcap.h) could be sufficient as well |
| 14:48.18 | d_rossberg | in 2013 the find_path() was removed |
| 14:48.38 | DaRock | lname should be the library name shouldn't it? and so expand? |
| 14:49.16 | DaRock | where do I find the rev? |
| 14:49.59 | d_rossberg | the point here is that the header file's name isn't termlib.h but termcap.h |
| 14:50.24 | d_rossberg | do you work with subversion? |
| 14:50.30 | DaRock | nope |
| 14:51.48 | d_rossberg | but? |
| 14:51.50 | DaRock | I'd say the point is that FindTERMLIB goes through a series of checks to find a working solution, but only uses the first one - termlib. Why the checks? Why override any user input? |
| 14:52.38 | DaRock | I'm using the ports system on FreeBSD, so I believe it grabs the releases |
| 14:52.46 | DaRock | I'll run a check though... |
| 14:53.47 | DaRock | all I have is 7.24.0 in the Makefile in the ports tree |
| 14:54.07 | d_rossberg | ncurses etc. are possible replacements for termlib? |
| 14:54.26 | DaRock | according to FindTERMLIB.cmake |
| 14:56.10 | d_rossberg | so, |
| 14:56.12 | DaRock | it runs through a series of checks - and takes the first working one afaict |
| 14:56.38 | d_rossberg | FindTERMLIB.cmake looks for possible replacements of termlib as well |
| 14:57.31 | DaRock | I'm not 100% sure of its effectiveness though |
| 14:58.10 | DaRock | but none of that fixes the final issue of the Find_Package_.... last arg failure |
| 14:59.42 | d_rossberg | some find_path() is definitely missing, it must set TERMLIB_INCLUDE_DIR too |
| 15:01.06 | DaRock | well if find_path() sets the TERMLIB_INCLUDE_DIR then its is doing that |
| 15:01.21 | d_rossberg | i.e. in the 7.24.0 sources you could try to replace find_path(TERMLIB_INCLUDE_DIR ${lname}.h) by find_path(TERMLIB_INCLUDE_DIR termcap.h) |
| 15:02.43 | DaRock | I don't believe that is the main issue though - the last line (macro) fails because any string aside from an empty one causes it to spit out missing include |
| 15:04.00 | DaRock | I thought that if TERMLIB_INCLUDE_DIR wasn't set it would cause the fail as well, but if it is actually setting it, then it will definitely go boom - tested that already |
| 15:05.05 | DaRock | I've set it to "", "/usr/include", "/usr/local/include" and it failed on the final 2 |
| 15:05.11 | DaRock | "" worked |
| 15:05.41 | DaRock | removing the last arg entirely fixes it too |
| 15:10.11 | DaRock | so FIND_PACKAGE_HANDLE_STANDARD_ARGS(TERMLIB DEFAULT_MSG TERMLIB_LIBRARY) works |
| 15:10.35 | DaRock | line 79 |
| 15:13.43 | d_rossberg | really? i tried it and the compile (make) failed |
| 15:14.01 | d_rossberg | maybe it works with the 7.24.0 |
| 15:14.38 | DaRock | not sure about the compile, but the macro doesn't come back with a failure at least. Compilation is another issue |
| 15:14.46 | d_rossberg | however, FindTERMLIB is reposible for setting TERMLIB_INCLUDE_DIR |
| 15:17.04 | DaRock | yes but that macro is in FindTERMLIB |
| 15:17.32 | DaRock | and regardless of whether that variable is set it will fail |
| 15:17.44 | DaRock | unless it is an empty string |
| 15:22.18 | DaRock | alright - this getting very confusing.... |
| 15:23.04 | DaRock | I'm going through sources of output - CMakeError.log, CMakeOutput.log, and stdout |
| 15:23.16 | DaRock | They all disagree |
| 15:24.31 | DaRock | CMakeOutput.log says STATUS: Performing Test LIBTERM_RESULT |
| 15:24.31 | DaRock | STATUS: Performing Test LIBTERM_RESULT - Success STATUS: Found TERMLIB: /usr/lib/libtermlib.so |
| 15:25.16 | DaRock | Stdout says -- Looking for tputs in termlib |
| 15:25.16 | DaRock | -- Looking for tputs in termlib - found |
| 15:25.16 | DaRock | -- Performing Test LIBTERM_RESULT |
| 15:25.16 | DaRock | -- Performing Test LIBTERM_RESULT - Success |
| 15:25.16 | DaRock | -- Found TERMLIB: /usr/lib/libtermlib.so |
| 15:25.52 | DaRock | and it finally says CMake Error: The following variables are used in this project, but they are set to NOTFOUND. |
| 15:25.52 | DaRock | Please set them or make sure they are set and tested correctly in the CMake files: |
| 15:25.52 | DaRock | TERMLIB_INCLUDE_DIR (ADVANCED) |
| 15:27.27 | DaRock | CMakeError.log says include files terminfo.h, termio.h, termlib.h, tinfo.h not found |
| 15:27.50 | DaRock | and thats with the last arg removed |
| 15:29.15 | DaRock | if the last arg is TERMLIB_INCLUDE_DIR then I don't see -- Found TERMLIB: /usr/lib/libtermlib.so or STATUS: Found TERMLIB: /usr/lib/libtermlib.so, I get NOT FOUND |
| 15:30.27 | DaRock | 3 tests for the basically the same thing, the can all succeed, it it will still fail - why? |
| 16:23.29 | Notify | 03BRL-CAD:starseeker * 69675 brlcad/trunk/src/external/CREO/CMakeLists.txt: MSVC isn't happy when linking - see if we can throw it some stubs |
| 16:58.38 | d_rossberg | DaRock: i fixed the system termlib issue in the current development branch (trunk) |
| 16:59.38 | d_rossberg | what is missing in the 7.24.0 is mainly the test if the find_path() was successful |
| 16:59.50 | DaRock | ok. I'll have a look later... brain's fried :) |
| 17:00.08 | DaRock | how does that go? |
| 17:01.14 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-eiyyrpuqhseukfjm) |
| 17:01.45 | d_rossberg | look at the current https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/FindTERMLIB.cmake |
| 17:01.46 | gcibot_ | [ BRL-CAD / Code / [r69676] /brlcad/trunk/misc/CMake/FindTERMLIB.cmake ] |
| 17:02.53 | d_rossberg | look at https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/FindTERMLIB.cmake |
| 17:02.54 | gcibot_ | [ BRL-CAD / Code / [r69676] /brlcad/trunk/misc/CMake/FindTERMLIB.cmake ] |
| 17:03.45 | d_rossberg | (sorry) after the find_path() there is an if statement which checks if it was successful |
| 17:04.37 | d_rossberg | whith a similat statement in the 7.24.0 version of the file it should work too |
| 17:06.19 | DaRock | ok, I see that. But why was the last macro failing with the TERMLIB_INCLUDE_DIR then? and why did it fail with manually setting it? |
| 17:08.31 | DaRock | and what happens with the RESOLVE_LIBRARIES() and LINKOPTS? |
| 17:09.20 | Notify | 03BRL-CAD:d_rossberg * 69676 brlcad/trunk/misc/CMake/FindTERMLIB.cmake: the macro was unable to detect a system termlib because of not setting TERMLIB_INCLUDE_DIR which causes FIND_PACKAGE_HANDLE_STANDARD_ARGS() to fail (and maybe something more)the necessary find_path() was removed in 2013 => integrated find_path() again |
| 17:09.23 | d_rossberg | manually: because of the FORCE (all variables are FORCED initialized with invalid values) |
| 17:10.12 | d_rossberg | and the macro was failing because it found the libtremlib.so but not the termlib.h header file |
| 17:10.54 | d_rossberg | but this generally ok because libtermlib.so is only a symbolic link |
| 17:11.28 | d_rossberg | the macro finds the real library later on |
| 17:11.47 | d_rossberg | which is ncurses in FreeBSD |
| 17:12.29 | d_rossberg | RESOLVE_LIBRARIES() and LINKOPTS seem to be not necessary (any more?) |
| 17:12.31 | DaRock | SOB! |
| 17:12.45 | DaRock | I should have picked that up! |
| 17:13.40 | d_rossberg | i don't think this was a trivial issue |
| 17:13.48 | DaRock | there are some links all over though - usually between .so and .a files though, so it slipped through... damn! I should have got that though - sorry about that |
| 17:14.57 | DaRock | righto... I might have a crack on those later then - try remove and see if it doesn't like it. Should work later too if it works on 7.24.0 |
| 17:15.20 | d_rossberg | libtermcap.so is a link too but there is a termcap.h header file - which has ncurses maros |
| 17:15.47 | DaRock | thanks for the help through it - I'll post back my results later once the brain's/body's had a chance to recover |
| 17:16.07 | d_rossberg | it was a bug in BRL-CAD nevertheless |
| 17:16.29 | DaRock | it does make it confusing - there probably should be a link to the header for libtermlib as well |
| 17:16.43 | DaRock | in BSD that is |
| 17:18.02 | DaRock | if there's one for termcap it makes sense |
| 17:18.14 | DaRock | probably a lack of interest... |
| 17:21.22 | DaRock | thanks for the fix btw |
| 17:48.31 | *** join/#brlcad LoH|Work (cdafe260@gateway/web/freenode/ip.205.175.226.96) |
| 17:51.01 | Notify | 03BRL-CAD:n_reed * 69677 brlcad/trunk/src/tclscripts/checker/check.tcl: Change meaning of -F option. Instead of subtracting first unioned solid from every unioned solid of the other tree, subtract from only the first unioned solid. Less likely to resolve the overlap, but more symmetrical and intuitive. |
| 17:54.59 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 18:05.20 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 18:58.07 | elpea | I recently installed BRL-CAD on a 128GB SATA3 SSD with a clean Windows 10 (64bit), and when I try to start the application I get this: he application was unable to start correctly (0xc0000142) |
| 18:58.57 | elpea | by "the application" I mean MGED. it eventually starts up but last time I counted 33 failed attempts with the aforementioned error popping up before it launched. any ideas? |
| 19:01.03 | elpea | I don't get this behavior on my other machine, a laptop with similar sized SSD running Windows 10 (64bit) |
| 19:39.24 | starseeker | DaRock: Ah, I see d_rossberg got it |
| 19:39.57 | starseeker | DaRock: sorry I didn't get to it sooner - having to juggle other stuff atm... |
| 19:40.15 | starseeker | elpea: I'm more surprised it started after failing to start, actually... |
| 19:41.13 | starseeker | elpea: if you google 0xc0000142 you might get some ideas... |
| 19:42.29 | Stragus | "The problem is that the ddl that launches the application is unsigned or digitally no longer valid." |
| 19:42.47 | Stragus | So that's Microsoft not wanting you to run non-signed software |
| 19:43.42 | starseeker | erm |
| 19:43.53 | starseeker | brlcad: anything we can do about that? |
| 19:44.23 | Stragus | I love how helpful the error message is to understand the problem, without googling it |
| 19:47.51 | elpea | Stragus: if so, I don't understand why the application starts up fine on my other machine |
| 19:48.14 | starseeker | elpea: it may be that the check to prevent running unsigned binaries is turned off there |
| 19:53.00 | starseeker | hmm... I don't see any cost-free way to sign open source code - it looks like the only previously cost-free option is no longer free |
| 19:53.43 | Stragus | Screw signing |
| 19:54.05 | Stragus | just lets the Windows and OSX users of his software fight against their OS signing policies |
| 20:00.50 | elpea | starseeker: I'll have to check... couldn't find anything in the AppLocker on the second machine (if that is even the correct place to look) |
| 20:01.34 | Stragus | Last I checked Google, you had to edit the registry to disable that |
| 20:01.52 | elpea | I'm pretty sure I haven't done that. |
| 20:11.53 | elpea | oh well. need to get my magician hat on to conjure free disk space for linux. |
| 20:18.34 | elpea | is this channel logged? I asked some questions here earlier but shut down my computer and found out my client wasn't logging... |
| 20:23.30 | Notify | 03BRL-CAD:starseeker * 69678 brlcad/trunk/src/external/CREO/CMakeLists.txt: Tweaks |
| 21:09.48 | Notify | 03BRL-CAD:starseeker * 69679 (brlcad/trunk/src/external/CREO/CMakeLists.txt brlcad/trunk/src/external/CREO/shim.cpp brlcad/trunk/src/external/CREO/shim.h): Get the "test" build working with MSVC |
| 21:58.53 | *** join/#brlcad merzo (~merzo@150-36-132-95.pool.ukrtel.net) |
| 22:11.08 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:16.53 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 23:59.57 | *** join/#brlcad Stragus (~alexis@modemcable090.29-19-135.mc.videotron.ca) |