| 01:41.57 | narnia | well comnplex entity instances are not being handled correctly. that does not surprise me. i do not have a clear idea of how to validate a complex entity instance. |
| 02:07.14 | *** join/#brlcad Pimpinella (~frank@p5481A784.dip0.t-ipconnect.de) | |
| 03:34.33 | narnia | some iso standards are about as clear as mud. |
| 05:47.42 | *** join/#brlcad brlcad (~brlcad@brlcad.bronze.supporter.pdpc) | |
| 05:47.42 | *** join/#brlcad learner (~brlcad@brlcad.bronze.supporter.pdpc) | |
| 05:47.42 | *** mode/#brlcad [+oo brlcad learner] by irc.freenode.net | |
| 10:01.11 | CIA-8 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/ (anim.tcl overlap.tcl): might as well make the other exec rm instances use file delete too for portability |
| 14:33.07 | narnia | for some reason it is not handling 'vertex_point' correctly which causes other parts not to work. |
| 14:52.31 | *** join/#brlcad starseeker (~starseeke@ip68-106-90-53.hr.hr.cox.net) | |
| 14:52.36 | starseeker | Anybody around? |
| 14:56.08 | brlcad | hello starseeker |
| 14:56.11 | brlcad | been a while :) |
| 14:57.39 | starseeker | Yep :-) |
| 14:57.42 | starseeker | been busy |
| 14:58.12 | starseeker | got to updating my system, and I'm trying to reset things so I can make a more "polite" version of the brlcad ebuild |
| 14:58.23 | starseeker | Any idea what librt corresponds to? |
| 14:58.51 | starseeker | or librt.la rather? |
| 15:01.49 | brlcad | what do you mean corresponds to? |
| 15:01.58 | brlcad | librt is one of brl-cad's core libraries |
| 15:02.02 | brlcad | it's the raytrace library |
| 15:02.28 | brlcad | 90% of the brl-cad binaries uses that library in some form .. so it corresponds to just about all of them |
| 15:05.02 | starseeker | I know |
| 15:05.07 | starseeker | I mean, outside of brlcad |
| 15:05.26 | starseeker | it overwrote something else, that most of my gnome libraries are trying to link to |
| 15:05.48 | starseeker | I can't for the life of me figure out what though |
| 15:06.21 | starseeker | I'm almost to the point of the nuclear option, a total system re-emerge (probably not a bad idea anyway, really, but a real time sink) |
| 15:07.19 | brlcad | so you have a system set up that does or does not have a librt already installed? |
| 15:07.51 | starseeker | Had. brlcad overwrote it. but I don't think it was a raytracing library, unless google knows nothing about it |
| 15:08.23 | narnia | starseeker, what distribution are you running? |
| 15:08.28 | starseeker | Gentoo |
| 15:09.02 | narnia | the old librt library should have been renamed libposix4 long ago. |
| 15:09.32 | starseeker | Hmm. Are programs even still using that library? |
| 15:09.47 | Twingy | librt? |
| 15:09.48 | narnia | i thought solaris was the only one that still had the old names. |
| 15:10.21 | starseeker | glibc has librt.so (I think) but doesn't seem to librt.la |
| 15:10.43 | narnia | http://refspecs.freestandards.org/LSB_1.1.0/gLSB/app-librt.html |
| 15:11.26 | starseeker | Yes - librt.so is a file owned by glibc |
| 15:11.42 | starseeker | so is librt.a |
| 15:11.46 | starseeker | but not librt.la |
| 15:11.49 | starseeker | apparently |
| 15:12.13 | brlcad | librt.la is a libtool library |
| 15:12.20 | brlcad | brl-cad also installs the .a and .so |
| 15:12.42 | starseeker | So libtool creates the .la file? how does that work? |
| 15:13.04 | brlcad | yes, libtool makes the .la's |
| 15:13.17 | narnia | starseeker, .la is a text file which is used by libtool to know which libraries are needed. |
| 15:13.40 | brlcad | the libtool libraries keep track of everything that comprises the library, what libraries it depends on, which ones it linked against, etc |
| 15:13.57 | brlcad | not strictly necessary to run, as the .so and .a are made from the .la's |
| 15:14.03 | brlcad | but the .la isn't the problem :) |
| 15:14.23 | starseeker | in this case it seems to be - apparently the glibc install didn't recreate the la file |
| 15:14.24 | starseeker | grr |
| 15:15.45 | brlcad | it's not likely that glibc has a .la and even if it did, overwriting it wouldn't cause run-time problems |
| 15:15.46 | brlcad | the .so would be the problem |
| 15:15.46 | narnia | brlcad, is librt a .a or .so? |
| 15:16.17 | brlcad | uhm, librt is the name of the library |
| 15:16.23 | brlcad | the .a is a static version of that library |
| 15:16.38 | brlcad | the .so is a shared object version of that library |
| 15:16.47 | narnia | nevermind |
| 15:16.49 | brlcad | the .la is a libtool version of that library ;) |
| 15:16.55 | narnia | agreed |
| 15:17.05 | brlcad | brl-cad install's both shared and static |
| 15:17.16 | narnia | looks like gentoo has a name collision. |
| 15:17.41 | starseeker | oh, lots of them, when you put things in /usr/lib - tcl/tk is one, and there are a few others |
| 15:18.01 | narnia | librt from glibc is colliding with brl-cad librt. two very different libs. |
| 15:18.14 | starseeker | brlcad warned me - I guess that's why things normally go in /usr/brlcad |
| 15:18.29 | brlcad | that is one of the reasons |
| 15:18.40 | brlcad | librt is only one of several libraries that "can" conflict |
| 15:20.09 | brlcad | libbn is another one .. openssl's "big number" library or brl-cad's "basic numerics" library |
| 15:21.01 | starseeker | Normally it wouldn't be a problem, but I was trying to create an ebuild and was a bit of a doofus in the beginning... |
| 15:21.32 | brlcad | there are about a half-dozen possible things that may conflict |
| 15:21.42 | brlcad | that I know of |
| 15:21.47 | starseeker | Heh - well, there's always the good old "touch /usr/lib/librt.la" |
| 15:21.58 | narnia | ;-) |
| 15:21.58 | brlcad | how to resolve them is still up for debate |
| 15:22.17 | starseeker | brlcad : Is there a reason not to just name them brlcad-*libraryname*? |
| 15:22.19 | brlcad | starseeker: how does that help? |
| 15:22.31 | starseeker | it solves the name conflicts |
| 15:22.50 | starseeker | oh - you mean touch? with any luck it will quit giving me file not found errors |
| 15:23.01 | starseeker | we'll see if it actually NEEDS whatever was in there ;-) |
| 15:24.07 | brlcad | starseeker: those are not libraries that can be renamed easily and I'm not inclined to rename them regardless |
| 15:24.16 | starseeker | Hmm. OK. |
| 15:24.32 | starseeker | not even just the file names? |
| 15:24.53 | starseeker | keep the current filename, and just append a brlcad- to the front? |
| 15:24.54 | brlcad | they predate the other libraries and have many applications that depend on them being named as such |
| 15:25.16 | narnia | agreed |
| 15:25.19 | starseeker | Oh, other than brlcad you mean? |
| 15:25.23 | brlcad | that's the whole point -- appending anything to the front is not "keeping the current filename" |
| 15:25.31 | starseeker | OK |
| 15:26.27 | brlcad | I mean if they were new libraries and we had named something libgnome and found it conflicted, that's one thing |
| 15:26.34 | brlcad | that's not the case here by a long shot |
| 15:27.00 | brlcad | these are core libraries that are over two decades old (libbu, libbn, librt) |
| 15:27.23 | starseeker | Hmm. wow |
| 15:27.25 | brlcad | there are lots of external applications that use brl-cad's libraries |
| 15:27.33 | starseeker | OK. Hmm. |
| 15:27.42 | starseeker | What about adding it as a configure option? |
| 15:27.43 | brlcad | so renmaing them would mean changing all of them |
| 15:28.11 | brlcad | which would piss off lots of people and dilute the established name recognition |
| 15:28.11 | starseeker | so systems where the other apps weren't an issue could change it, but the default would be the current system? |
| 15:28.28 | starseeker | cool |
| 15:28.56 | brlcad | starseeker: can you see if there are any gentoo guidelines on conflict resolution? |
| 15:29.04 | starseeker | I'll take a look |
| 15:29.05 | brlcad | this can't be the first instance |
| 15:31.07 | brlcad | as a last resort we can either do what X11 does and use a top level root like /usr/brlcad/ or do something like java with isolated subdirs for libs/includes/etc like /usr/lib/brlcad/ |
| 15:31.53 | brlcad | I'm adding a configure-time hook for the latter for the debian apt system folks |
| 15:32.08 | brlcad | so that would probably suffice for you too |
| 15:32.16 | starseeker | Yes, that sounds good |
| 15:32.29 | starseeker | simpler for you guys too - one mechanism to maintain |
| 15:32.30 | brlcad | but if there's another means to resolve the conflict, I'd like to know |
| 15:32.40 | brlcad | starseeker: it's a more complicated install, though |
| 15:32.57 | brlcad | requires scripts that will add /usr/lib/brlcad to the system search path on installation |
| 15:33.02 | starseeker | well, I haven't found anything gentoo specific yet, but what little I have seen indicates names of library filenames have to be unique |
| 15:33.22 | starseeker | brlcad - I know, but I think there are mechanisms that do that |
| 15:33.55 | brlcad | well of course they ultimately do need to be unique or exist in separate directories -- but if there are procedural means to get them resolved |
| 15:34.38 | starseeker | Oh. I can't find anything about that yet - my guess is it just shows up in a bug report and people figure out what to do then |
| 15:35.10 | starseeker | I think /usr/lib/brlcad should be fine - on checking I see the mozilla ebuild(s) have added a /usr/lib/mozilla entry |
| 15:35.27 | starseeker | so has fltk |
| 15:35.58 | starseeker | If a lousy web browser can add a line, I should think brlcad is entitled ;-) |
| 15:36.16 | brlcad | still, if it can be resolved without that -- that would definitely be preferred |
| 15:36.51 | brlcad | as developers end up needing to add multiple search paths to their build systems |
| 15:37.44 | starseeker | Well, the only other option I can see is renaming the glibc library :-/ |
| 15:37.53 | starseeker | or those files rather |
| 15:43.21 | brlcad | do you know if the portage maintainers are apposed to a /usr/brlcad ? |
| 15:43.31 | brlcad | s/app/opp/ |
| 15:44.30 | starseeker | Dunno. Only real way is to submit an ebuild and find out |
| 15:44.31 | brlcad | an installation similar to X11 |
| 15:45.28 | starseeker | Once I get my system back in order I'll see what I can put together |
| 15:45.31 | brlcad | nobody authoritative on #gentoo? |
| 15:45.35 | starseeker | Nah |
| 15:46.02 | starseeker | I'll give it a shot, but it's more of a help channel - I'll probably get lost in the noise |
| 15:46.26 | brlcad | ack, they're growing too |
| 15:49.52 | starseeker | Well, the fltk ebuild looks fairly straightforward |
| 15:51.10 | starseeker | Hmm - maybe ranlib is what I need for librt.a -> librt.la |
| 15:51.25 | brlcad | ranlib gives the .a |
| 15:51.31 | starseeker | crud |
| 15:51.41 | brlcad | libtool makes the .la |
| 15:52.03 | brlcad | libtool runs ranlib (or whatever your system needs) and makes the .so and .a at compile time |
| 15:52.04 | starseeker | any way to run libtool on a individual file? |
| 15:52.13 | brlcad | it doesn't work that way |
| 15:52.21 | brlcad | I'm not following what the problem is, though |
| 15:52.31 | starseeker | I'll show you the build output in a sec... |
| 15:52.36 | brlcad | if you're missing librt.la, there's a bigger problem |
| 15:53.01 | starseeker | uh oh |
| 15:59.13 | starseeker | Crud. |
| 15:59.16 | starseeker | libtool: link: cannot find the library `/usr/lib/librt.la' |
| 16:01.00 | starseeker | Well, gotta run for now - I'll let y'all know once I come up with a more friendly ebuild for gentoo |
| 16:01.16 | starseeker | thanks for the help! |
| 16:04.52 | narnia | something tells me he is going to have to at least re-install glibc. |
| 16:25.09 | brlcad | why libtool is wanting /usr/lib/librt.la seems wrong |
| 16:25.12 | brlcad | maybe a stale build |
| 17:30.48 | narnia | no idea i have never tried gentoo. |
| 17:43.42 | narnia | argh i think the ap203.exp i am using is incorrect. |
| 20:26.29 | *** join/#brlcad CIA-10 (~CIA@flapjack.navi.cx) | |