[Slackbuilds-users] brlcad: update status

Robby Workman rworkman at slackbuilds.org
Thu Nov 28 00:24:38 UTC 2013


On Wed, 27 Nov 2013 18:55:15 -0500
John Vogel <jvogel4 at stny.rr.com> wrote:

> On Wed, 27 Nov 2013 17:25:07 -0600
> Robby Workman <rworkman at slackbuilds.org> wrote:
> 
> > On Wed, 27 Nov 2013 17:12:42 -0500
> > John Vogel <jvogel4 at stny.rr.com> wrote:
> > 
> > > On Sun, 24 Nov 2013 14:41:47 -0500
> > > John Vogel <jvogel4 at stny.rr.com> wrote:
> > > 
> > > > I was too hasty with my statement that build of brlcad was
> > > > successful. Yes it builds and mged seems to work fine. But
> > > > archer, which I mistakenly didn't test, segfaults before even
> > > > opening a window.
> > > > 
> > > > I have been scrambling to find a fix, to no avail so far. The
> > > > issue seems to be compatibility problems with the versions of
> > > > tcl/tk and itcl/itk/iwidgets. One thing that I can't seem to
> > > > work around is that the Tcl8.6.1 package installs itcl4.0.0,
> > > > and that is in the main slackware repository; brlcad bundles
> > > > Tcl/Tk8.5.9 and itcl/itk3.4 (this version number for itk seems
> > > > to be unique to brlcad).
> > > > 
> > > > I am coming to the conclusion that using the system installed
> > > > tcl/tk to build brlcad is not going to work and my changes to
> > > > the brlcad.SlackBuild are unusable at this time. If slackers
> > > > really want brlcad and are willing to accept the increased size
> > > > of the fully bundled build, that SlackBuild is easily prepared.
> > > > A patch for bundled build, which applies against my previous
> > > > summission, is attached.
> > > > 
> > > > If anyone has any suggestions as possible workarounds that I may
> > > > have missed, I welcome the input.
> > > > 
> > > > j_v
> > > 
> > > So now I know that itcl/itk 3.x (versions 3.4/3.3 used by brlcad)
> > > are incompatible (1) with tcl/tk8. I have build versions of
> > > brlcad using several methods:
> > > 
> > > 1. tcl/tk8.6.1 built without the included itcl package:
> > >   a. bundled itcl3.4/itk3.3
> > >   b. system built itcl/itk4.0.0
> > > 2. tcl/tk8.6.1 with included itcl package left in:
> > >   a. bundled itk3.3 (this wouldn't build)
> > >   b. system itk4.0.0
> > > 3. downgraded system to tcl/tk8.5.15 then built itcl/itk bundled
> > > 
> > > All except 2a builds. The only one that builds working binaries
> > > is 3. In effect, 3 is equal to bundling, since I can't imagine
> > > asking the BDFL to downgrade tcl/tk. Please consider my patch
> > > that fixes the build script to create fully working binaries.
> > 
> > 
> > Okay, so which approach did you take in the patch?  1a ?
> > 
> > -RW
> 
> Sorry, I should have specified. 1a was the original approach that
> built and didn't actually built a fully functional package. For
> missing that, I apologize. I actually left out the approach that I
> took in this patch.
> 
> That approach is to build a mostly bundled build:
> 
> 4. used from system:
>    TERMLIB (ncurses)
>    XMLLINT
>    XSLTPROC
>    ZLIB
>    REGEX
>    the remaining dependencies bundled with brlcad:
>    TCL/TK ITCL/ITK IWIDGETS TKHTML TKPNG ... etc
> 
> The only one I'm not satisfied with at this point is libpng. If I try
> to configure the build to use the system's libpng, several of the
> other bundled packages get listed by cmake as being broken depends.
> So, at some point when I'm not so frustrated with tcl/tk itcl/itk and
> brlcad forward/backward compatiblities, I can return to this and try
> to flesh out the reason the build system rejects our libpng. I smell
> another version compatibility issue.


I'd not bother with trying to use the system png.  The upstream
libpng people have a rather different version of sanity than most
other projects, and they seem to think it perfectly rational to 
change the library *name* with each major version release.
This is why you see libpng12.so and libpng14.so both on the system;
it's not enough to link libpng.so (and require/allow/prevent 
specific versions of the library) - software has to link a specific
majorversion.  


> I have tested both archer and mged. They run well, it seems to me,
> though I am just learning to use them.


Okay, I'll merge this into my branch then; thanks!

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20131127/c3ae3719/attachment.asc>


More information about the SlackBuilds-users mailing list