Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 77197 - [science overlay] sci-misc/brlcad (New package)
Summary: [science overlay] sci-misc/brlcad (New package)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement with 16 votes (vote)
Assignee: Gentoo Science Related Packages
URL: http://brlcad.org/
Whiteboard:
Keywords: EBUILD, InOverlay
Depends on: 93307 93311 104738 104769
Blocks:
  Show dependency tree
 
Reported: 2005-01-08 23:09 UTC by Cliff Yapp
Modified: 2010-03-01 03:52 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild for brl-cad 7.0.2 (brlcad-7.0.2.ebuild,732 bytes, text/plain)
2005-01-08 23:12 UTC, Cliff Yapp
Details
Updated ebuild (brlcad-7.0.2.ebuild,717 bytes, application/octet-stream)
2005-01-10 20:49 UTC, Cliff Yapp
Details
Patch for Makefile.am errors (this isn't all of them, apparently) (brlcad-7.0.2-gentoo.patch,7.23 KB, patch)
2005-01-10 20:50 UTC, Cliff Yapp
Details | Diff
Ebuild for 7.0.4 revision 2. (brlcad-7.0.4-2.ebuild,635 bytes, application/octet-stream)
2005-01-26 15:35 UTC, Cliff Yapp
Details
ebuild - 7.0.4 Works with sf tarball (brlcad-7.0.4.ebuild,550 bytes, application/octet-stream)
2005-01-27 10:13 UTC, Cliff Yapp
Details
brlcad-7.2.4.ebuild written from scratch (brlcad-7.2.4.ebuild,2.16 KB, text/plain)
2005-05-19 17:16 UTC, Michal Slonina
Details
brlcad-7.2.4-gentoo.diff needed for brlcad-7.2.4.ebuild (brlcad-7.2.4-gentoo.diff,570 bytes, text/plain)
2005-05-19 17:19 UTC, Michal Slonina
Details
brlcad-7.2.4.ebuild ( updated dependences and new debug use flag ) (brlcad-7.2.4.ebuild,2.29 KB, text/plain)
2005-05-29 11:35 UTC, Michal Slonina
Details
Portage log for failed brlcad emerge (brlcad-7.2.4.log,1.25 MB, text/plain)
2005-07-11 02:22 UTC, Peter Jensen
Details
emerge info (for successful brlcad build) (info.txt,2.16 KB, text/plain)
2005-08-11 21:12 UTC, Craig Finch
Details
brlcad-7.4.2-gentoo.diff (brlcad-7.4.2-gentoo.diff,1.63 KB, patch)
2005-09-04 16:02 UTC, Michal Slonina
Details | Diff
brlcad-7.4.2.ebuild (brlcad-7.4.2.ebuild,2.19 KB, text/plain)
2005-09-04 16:09 UTC, Michal Slonina
Details
CONTESTS of brlcad image genereted by brlcad-7.4.2.ebuild (CONTENTS,120.78 KB, text/plain)
2005-09-06 06:00 UTC, Michal Slonina
Details
brlcad-7.4.2-system-tcl.diff (brlcad-7.4.2-system-tcl.diff,418 bytes, patch)
2005-09-13 03:21 UTC, MarkE
Details | Diff
brlcad 1.6.2 ebuild + diff + manifest + digest (brlcad-1.6.2.tar.gz,2.12 KB, application/octet-stream)
2005-10-17 13:33 UTC, Joe Krisch
Details
sci-misc/brlcad-7.6.6.ebuild (brlcad-7.6.6.ebuild,2.22 KB, text/plain)
2006-01-26 12:23 UTC, Lucas Chiesa
Details
brlcad-7.6.6-gentoo.diff (brlcad-7.6.6-gentoo.diff,7.16 KB, patch)
2006-01-26 12:24 UTC, Lucas Chiesa
Details | Diff
tcl.m4 (tcl.m4,120.91 KB, text/plain)
2006-01-26 12:26 UTC, Lucas Chiesa
Details
the emerge log file (3393-brlcad-7.6.6.log,1.86 KB, text/plain)
2006-02-16 15:37 UTC, GENTOO ROCKS!
Details
brlcad-7.6.6-r1.ebuild (brlcad-7.6.6-r1.ebuild,2.19 KB, text/plain)
2006-03-17 08:47 UTC, Rogier Eggers
Details
config.log for failed build (config.log,388.56 KB, text/plain)
2006-03-17 08:49 UTC, Rogier Eggers
Details
Primative ebuild for 7.8.2 (brlcad-7.8.2.ebuild,1.64 KB, application/octet-stream)
2006-06-22 20:46 UTC, Cliff Yapp
Details
revdep_rebuild report of damage (revdep_rebuild report.txt,177.82 KB, text/plain)
2007-02-03 14:41 UTC, Cliff Yapp
Details
ebuilds for 7.10.0 and cvs (brlcad-ebuilds.7z,30.27 KB, application/octet-stream)
2007-04-20 05:21 UTC, dongxu li
Details
updated 7.10.0 ebuild (brlcad-7.10.0.tbz,28.71 KB, application/octet-stream)
2007-05-07 23:52 UTC, dongxu li
Details
brlcad-0.7.10.ebuild and brlcad-9999.ebuild (brlcad.7z,29.79 KB, application/octet-stream)
2007-05-08 10:25 UTC, dongxu li
Details
brlcad-7.10.2 ebuild (brlcad-7.10.2.ebuild,2.54 KB, application/octet-stream)
2007-09-12 02:34 UTC, Cliff Yapp
Details
Updated BRL-CAD ebuild (brlcad-7.10.2.ebuild,1.72 KB, application/octet-stream)
2007-09-16 21:13 UTC, Cliff Yapp
Details
tcl patch (tcl-Makefile-gentoo.patch,1.06 KB, patch)
2007-09-16 21:14 UTC, Cliff Yapp
Details | Diff
tk patch (tk-Makefile-gentoo.patch,1.13 KB, patch)
2007-09-16 21:14 UTC, Cliff Yapp
Details | Diff
env.d file for /opt/brlcad paths (brlcad.envd,49 bytes, text/plain)
2007-09-16 21:15 UTC, Cliff Yapp
Details
BDL documentation license (BDL,1.47 KB, text/plain)
2007-09-16 21:16 UTC, Cliff Yapp
Details
Convenient bundle of brl-cad files (except BDL license) (brlcad-7.10.2-ebuild.tar.gz,3.46 KB, application/octet-stream)
2007-09-16 21:22 UTC, Cliff Yapp
Details
patch for tcl/tk makefiles (brlcad-tcltk-man_install.patch,2.50 KB, patch)
2007-09-17 23:37 UTC, Cliff Yapp
Details | Diff
brlcad-7.10.2.ebuild (patches correct files now) (brlcad-7.10.2.ebuild,1.70 KB, text/plain)
2007-09-17 23:38 UTC, Cliff Yapp
Details
Convenient bundle of brl-cad files (except BDL license) [updated] (brlcad-7.10.2-ebuild.tar.gz,3.36 KB, text/plain)
2007-09-17 23:39 UTC, Cliff Yapp
Details
Convenient bundle of brl-cad files (except BDL license) [updated] (brlcad-7.10.2-ebuild.tar.gz,3.36 KB, application/octet-stream)
2007-09-17 23:53 UTC, Cliff Yapp
Details
brlcad-7.10.2-ebuild tarball (brlcad-7.10.2-ebuild.tar.gz,3.36 KB, application/octet-stream)
2007-09-17 23:54 UTC, Cliff Yapp
Details
Version update to latest, remove unneeded line (brlcad-7.10.4.ebuild,1.68 KB, application/octet-stream)
2007-10-26 21:39 UTC, Cliff Yapp
Details
7.10.4 - Fix the info message to actually specify the mged binary (brlcad-7.10.4.ebuild,1.70 KB, application/octet-stream)
2007-10-29 01:38 UTC, Cliff Yapp
Details
configuration log for build on AMD64 (config.log,498.97 KB, text/plain)
2007-10-31 23:54 UTC, Bob Paddock
Details
emerge --info for build on AMD64 (emerge_info.txt,2.91 KB, text/plain)
2007-10-31 23:54 UTC, Bob Paddock
Details
Updated BRL-CAD ebuild (brlcad-7.10.4-r1.ebuild,1.82 KB, application/octet-stream)
2007-11-14 23:05 UTC, Cliff Yapp
Details
Updated BRL-CAD ebuild - Try a different libdir path for AMD64... (brlcad-7.10.4-r1.ebuild,1.80 KB, application/octet-stream)
2007-11-15 01:56 UTC, Cliff Yapp
Details
One other possibility - need to inherit multilib explicitly? (brlcad-7.10.4-r1.ebuild,1.82 KB, application/octet-stream)
2007-11-15 02:19 UTC, Cliff Yapp
Details
brlcad-cvs ebuild (brlcad-9999-r1.ebuild,2.26 KB, text/plain)
2007-12-25 15:28 UTC, dongxu li
Details
no need to check for /usr/local (usr-local.patch,393 bytes, patch)
2007-12-25 15:31 UTC, dongxu li
Details | Diff
brlcad-7.10.4-r2 (brlcad-7.10.4-r2.ebuild,2.61 KB, text/plain)
2007-12-25 15:35 UTC, dongxu li
Details
brlcad-9999-r1.ebuild (brlcad-9999-r1.ebuild,2.17 KB, text/plain)
2007-12-25 16:24 UTC, dongxu li
Details
brlcad-7.10.4-r2.ebuild (brlcad-7.10.4-r2.ebuild,2.59 KB, text/plain)
2007-12-25 23:40 UTC, dongxu li
Details
brlcad-7.12.0.ebuild (brlcad-7.12.0.ebuild,2.62 KB, text/plain)
2008-04-15 22:30 UTC, Richard Westwell
Details
brlcad-7.12.2.ebuild (brlcad-7.12.2.ebuild,2.62 KB, text/plain)
2008-05-07 21:06 UTC, Richard Westwell
Details
Patch to brlcad internal tk build (brlcad-7.12.2-tkBind.patch,409 bytes, patch)
2008-10-05 16:57 UTC, Facundo de Guzmán
Details | Diff
brlcad-7.12.6.ebuild (brlcad-7.12.6.ebuild,2.67 KB, text/plain)
2009-03-01 13:57 UTC, dongxu li
Details
brlcad-7.14.4.ebuild (brlcad-7.14.4.ebuild,2.44 KB, text/plain)
2009-03-27 08:35 UTC, dongxu li
Details
brlcad-7.14.8.ebuild (brlcad-7.14.8-r1.ebuild,2.52 KB, text/plain)
2009-05-25 10:04 UTC, dongxu li
Details
brlcad-7.14.8.ebuild (brlcad-7.14.8-r1.ebuild,2.53 KB, text/plain)
2009-05-25 18:07 UTC, dongxu li
Details
brlcad-7.14.8.ebuild (brlcad-7.14.8.ebuild,2.33 KB, text/plain)
2009-06-01 21:17 UTC, dongxu li
Details
brlcad-7.16.0.ebuild (brlcad-7.16.0.ebuild,2.44 KB, text/plain)
2009-11-02 18:34 UTC, dongxu li
Details
brlcad-7.16.2.ebuild (brlcad-7.16.2.ebuild,2.55 KB, text/plain)
2009-12-07 19:35 UTC, dongxu li
Details
cut-7.16.2.patch (cut-7.16.2.patch,521 bytes, patch)
2009-12-07 19:35 UTC, dongxu li
Details | Diff
cmd-7.16.2.patch (cmd-7.16.2.patch,535 bytes, patch)
2009-12-07 19:36 UTC, dongxu li
Details | Diff
xsltproc-7.16.2.patch (xsltproc-7.16.2.patch,383 bytes, patch)
2009-12-07 19:37 UTC, dongxu li
Details | Diff
config.log with empty XSLTPROC (config.log,426.16 KB, text/plain)
2009-12-08 05:03 UTC, dongxu li
Details
small logic fix that only affects x86_32 (brlcad-7.16.2-r1.ebuild,2.55 KB, text/plain)
2010-01-12 12:24 UTC, M. B.
Details
brlcad-7.16.4.ebuild (brlcad-7.16.4.ebuild,2.37 KB, text/plain)
2010-01-25 01:43 UTC, dongxu li
Details
emerge info sci_misc brlcad build failure (info_sci_misc_brlcad7164.txt,4.27 KB, text/plain)
2010-02-20 13:15 UTC, Bob Paddock
Details
emerge pqv brlcad7164 build failure (pqv_sci_misc_brlcad7164.txt,89 bytes, text/plain)
2010-02-20 13:16 UTC, Bob Paddock
Details
brlcad7164 build log (sci-misc:brlcad-7.16.4:20100220-125555.log,143.22 KB, text/plain)
2010-02-20 13:30 UTC, Bob Paddock
Details
sci-misc:brlcad-7.16.6:20100227-140150.log (brlcad-7.16.6-20100227-140150.log,1.14 MB, text/plain)
2010-02-27 18:18 UTC, Luis Ferreira
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cliff Yapp 2005-01-08 23:09:24 UTC
This is a brl-cad ebuild which is close to working, but encounters some sandbox violation during the make install portion.  Help appreciated
Comment 1 Cliff Yapp 2005-01-08 23:12:19 UTC
Created attachment 48000 [details]
Ebuild for brl-cad 7.0.2

This one has sandbox problems
Comment 2 Cliff Yapp 2005-01-09 05:18:32 UTC
Sandbox problems (apparently) stem from $(DESTDIR) variable not being used in the install-data-hook logic in the following Makefiles:

libtcl/doc/Makefile
libtk/doc/Makefile
incrTcl/itcl/doc/Makefile
incrTcl/itk/doc/Makefile
iwidgets/doc/Makefile

So fixing this should solve the sandbox issue.  If this change makes sense in the upstream I'll just bump the ebuild version, otherwise I can try and figure out the patches.
Comment 3 Ciaran McCreesh 2005-01-10 10:17:25 UTC
Things to fix:

* KEYWORDS needs to be set as per policy
* Fix IUSE
* Don't hardcode version numbers
* No econf?
Comment 4 Cliff Yapp 2005-01-10 10:45:46 UTC
> Things to fix:

> * KEYWORDS needs to be set as per policy

OK.  In theory I suppose this should build on a lot of different archs, but the only one I can test on is x86.  Any volunteers?

> * Fix IUSE

Opps, forgot to remove tcltk.

> * Don't hardcode version numbers

Did I?  You mean this? :
  S="${WORKDIR}/${PN}-7.0"

Unfortunately the build directory doesn't open up into the full 7.0.2 - the tarball just expands into 7.0.  I don't see a way around hard coding that particular part - is there one?

> * No econf?

Uh - just used what had worked for the normal build, didn't think about econf.  I suppose it should work - I'll give it a try.

I guess I can go ahead and try to generate patch files for this - hopefully it will be of enough interest to merit quick insertion into portage once the ebuild is working.
Comment 5 Ciaran McCreesh 2005-01-10 10:51:15 UTC
KEYWORDS -- policy says they should be ~arch to begin with, so you want ~x86.

Version numbers -- use either bash substitution or versionator to remove the final version component.
Comment 6 Cliff Yapp 2005-01-10 11:13:43 UTC
Ah, OK.  ~x86 it is.

Um - is there documenation somewhere for the versionator eclass?  Also, is it really worth it to make that part of the ebuild non-hard coded?  I guess if policy dictates it I can try but it seems sort of silly.  I might even see if the developers of brl-cad could switch to using the full version number - that might be the simplest thing.
Comment 7 Ciaran McCreesh 2005-01-10 11:15:57 UTC
man 5 versionator.eclass (part of portage-manpages). Worth doing, it saves all kinds of pain when doing version bumps.
Comment 8 Cliff Yapp 2005-01-10 20:49:19 UTC
Created attachment 48159 [details]
Updated ebuild
Comment 9 Cliff Yapp 2005-01-10 20:50:07 UTC
Created attachment 48160 [details, diff]
Patch for Makefile.am errors (this isn't all of them, apparently)
Comment 10 Cliff Yapp 2005-01-10 20:51:50 UTC
OK, the build gets further into the install process now, but I'm hitting a stubborn sandbox error:

Making install in pro-engineer
make[2]: Entering directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[3]: Entering directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[3]: Nothing to be done for `install-exec-am'.
/bin/sh ../../misc/mkinstalldirs /usr/lib/../pro-engineer
 /bin/install -c -m 644 install.doc /usr/lib/../pro-engineer/install.doc
ACCESS DENIED  unlink:    /usr/pro-engineer/install.doc
/bin/install: cannot remove `/usr/lib/../pro-engineer/install.doc': Permission denied
 /bin/install -c -m 644 protk.dat /usr/lib/../pro-engineer/protk.dat
ACCESS DENIED  unlink:    /usr/pro-engineer/protk.dat
/bin/install: cannot remove `/usr/lib/../pro-engineer/protk.dat': Permission denied
make[3]: *** [install-proeDATA] Error 1
make[3]: Leaving directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc'
make: *** [install-recursive] Error 1

!!! ERROR: sci-misc/brlcad-7.0.2 failed.

I can't seem to find a simple answer for this one, so I guess I'll have to keep looking unless someone smarter than me finds it first.
Comment 11 Cliff Yapp 2005-01-24 13:47:36 UTC
Uh, silly question, but I just realized this got assigned to the graphics herd.  I would have thought this would be likely to go into the sci-misc section, along with qcad.  gCAD3D was assigned to sci, as well.  Am I missing something?  brl-cad is an engineering/science program much more than it is a graphics program.

Who decides where to assign things?  Is the point up for discussion?
Comment 12 Cliff Yapp 2005-01-26 15:32:50 UTC
OK, the 7.0.4-2 release builds successfully on gentoo, thanks to the efforts of the primary developer.  Hence the new ebuild without patches should work, with the possible exception of not pointing to the correct file on sourceforge.  If I need to I'll sort that out once the update is released, but based on latest cvs test this one is ready to go.

As mentioned, I think because of the nature and intended use this should be included in qcad's category.  That said, thanks a bunch for the help I have recieved on this ebuild from the gfx herd :-).
Comment 13 Cliff Yapp 2005-01-26 15:35:19 UTC
Created attachment 49606 [details]
Ebuild for 7.0.4 revision 2. 

Probably a naming convention error.  7.0.4-2 builds successfully on gentoo. 
Not sure what the tarball will be called on sf yet - just had the successful
test of cvs.
Comment 14 Cliff Yapp 2005-01-27 10:13:47 UTC
Created attachment 49673 [details]
ebuild - 7.0.4  Works with sf tarball

OK, the sourceforge tarball has been fixed, and now builds without trouble
using this ebuild.  It should be ready to go.
Comment 15 Cliff Yapp 2005-04-07 12:03:47 UTC
Hmm - apparently this ebuild caused some subtle problems on my system due to name conflicts in library names.  Need to put this one on hold while this is figured out.  DO NOT INSTALL.  (it may not work on an uncorrupted system anyway)
Comment 16 Michal Slonina 2005-05-19 17:16:21 UTC
Created attachment 59334 [details]
brlcad-7.2.4.ebuild written from scratch

the 7.0.4 version ebuild is a crap
i written a new one, hope this will be better, although still there are some
issues:
1) the Utah Raster Toolkit should be in a seperate ebuild, but as long as it is
not used by any other package in portage, we can defer this separation, as long
as there is no volunteer to do urt ebuild.
2) i hope i cleaned all the junk that brl-cad puts in your system, but i am a
big lame, so some pro should check the CONTENTS file.
3) it needs a rather ugly hack patch to configure script, becouse the
AC_TRY_RUN  for iwidgets is broken, i will notice upstream about this problem. 


i never used bugzilla before, so if i screwed something, than sorry
the brlcad-7.2.4-gentoo.diff follows in the next post
Comment 17 Michal Slonina 2005-05-19 17:19:39 UTC
Created attachment 59335 [details]
brlcad-7.2.4-gentoo.diff needed for brlcad-7.2.4.ebuild

ugly ugly ugly
Comment 18 Michal Slonina 2005-05-20 03:19:26 UTC
hmm, shouldn't there be a seperate folder in portage for CAD/CAM/CSG
(like sci-cad) there are many packages that would fit there, qcad, brl-cad,
varicad, linuxcad, microstation. Some are just waiting to get a proper .ebuild.
Comment 19 Michal Slonina 2005-05-28 18:30:31 UTC
If the build breaks, its probably due to missing symlinks
/usr/lib/libitcl-3.x.so and /usr/lib/libitk-3.x.so. Try to use itcl-3.3 and
itk-3.3 ebuild from bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=93307
http://bugs.gentoo.org/show_bug.cgi?id=93311
Feedback is welcome and needed.
Comment 20 Michal Slonina 2005-05-29 11:17:18 UTC
If u want to try brlcad-7.2.4.ebuild, u need the itcl-3.3.ebuild ( BUG 93307 )
and itk-3.3.ebuild ( BUG 93311 ).
Comment 21 Michal Slonina 2005-05-29 11:35:17 UTC
Created attachment 60113 [details]
brlcad-7.2.4.ebuild (  updated dependences and new debug use flag )

* brlcad-7.2.4 depends now on itcl-3.3 ( BUG 93307 ) and itk-3.3 ( BUG 93311 ).

 ( becouse brlcad configure states that libtcl and libtk is in /usr/lib, 
   this is wrong so symlink is needed in itcl and itk ebuild.
   And of course the itcl and itk are now split )
* new debug use flag added

Diff:
--- brlcad-7.2.4.ebuild.old	2005-05-29 18:58:56.551739216 +0000
+++ brlcad-7.2.4.ebuild 2005-05-29 19:06:13.232353672 +0000
@@ -11,15 +11,15 @@
 LICENSE="GPL LGPL GFDL BSD"
 SLOT="0"
 KEYWORDS="~x86"
-IUSE="java jove pic"
+IUSE="java jove pic debug"

 DEPEND="virtual/x11 \
	>=dev-lang/tcl-8.4 \
	>=dev-lang/tk-8.4 \
	media-libs/libpng \
	sys-libs/zlib \
-	>=dev-tcltk/itk-3.1 \
-	>=dev-tcltk/itcl-3.1 \
+	>=dev-tcltk/itk-3.3 \
+	>=dev-tcltk/itcl-3.3 \
	>=dev-tcltk/iwidgets-4.0.0 \
	jove? ( app-editors/jove ) \
	java? ( virtual/jdk ) \
@@ -47,6 +47,10 @@
		myconf="${myconf} --enable-jove"
	use pic && einfo "Configuring for pic code." &&
		myconf="${myconf} --with-pic"
+	use debug && einfo "Debuging support enabled" &&
+		myconf="${myconf} --enable-debug" ||
+		myconf="${myconf} --disable-debug"
+
	BC_RETRY=no econf $myconf || die "econf failed"
	emake || die "emake failed"
 }
Comment 22 Yosef Meller 2005-06-24 07:53:09 UTC
It seems that at least in 7.2.6 the source file has a built-in version of tcl,
inctTcl ans iwidgets, so maybe those dependencies can be optional, freeing this
ebuild fronm dependency on other bugs?
Comment 23 Michal Slonina 2005-07-07 13:18:40 UTC
BUG 93307 and BUG 93311 now closed, using buildin tk/tcl/iwidgets IMHO is not a
good practice. However if its brl-cad.ebuild in portage or nothing we can add
special USE flag lets say 'builtin_tcl'. Any pros or cons?
Comment 24 Yosef Meller 2005-07-09 02:45:37 UTC
It would be a good idea to allow the use of the builtin version which is sure to
work, in case the external stuff is not working for some reason (e,g, upgraded
to an incompatible version). Other than that, it doesn't seem very important.
Comment 25 Peter Jensen 2005-07-11 02:22:32 UTC
Created attachment 63117 [details]
Portage log for failed brlcad emerge

I'm having some trouble emerging this package.
Attached is the portage log, followed by 'emerge info' output.
It seems to fail with some undefined references to itk and itcl functions.
Comment 26 Craig Finch 2005-08-11 21:12:30 UTC
Created attachment 65719 [details]
emerge info (for successful brlcad build)

brlcad compiles successfully for me--see attached output from "emerge info".  I
tried some simple TCL commands in brlcad and they were successful.  I am using
itcl 3.3 and itk 3.3 (despite the face that itk is masked).
Comment 27 Michal Slonina 2005-09-03 02:27:29 UTC
I am thinking about packaging whole brlcad-7.4.2 into /usr/brlcad (in contrast
to puting all files in /usr/bin /usr/share and similar directories). Its a big
package, and in binary form on sourceforge it exposes such behaviour :)
Please let me know what you think, becouse trying to contact gentoo devs on irc
is pointless :P
Comment 28 Michal Slonina 2005-09-03 02:33:51 UTC
Another question comes from the fact that brlcad or brl-cad is known by two names.
Eg:
Sourceforge project name: BRL-CAD ( but webpage brlcad.sourceforge.net )
Sourceforge tarballs: brlcad-...
Freshmeat: BRL-CAD
Webpage: brlcad.org (bu the banner says BRL-CAD)
IRC: #brlcad on freenode

Now, which one seems cooler to you? :]
Comment 29 Yosef Meller 2005-09-03 04:53:22 UTC
I think using /usr/brlcad is OK; just like qt, kde, and other big ones. 

As for package names, I'd say 'brlcad' since it's less typing :-) and also named
like the directory it will be installed under if it's going to be in
/usr/brlcad. The official names don't really matter because usually ebuilds are
named to match the package filename better (this way $P is usable immediately).
Comment 30 Michal Slonina 2005-09-04 03:07:56 UTC
According to "friendly" FHS < http://www.pathname.com/fhs/pub/fhs-2.3.html >
we can only use /opt/brlcad or /usr/{bin,lib,share,include}, however its gentoo
tradition to screw FHS :] Any cons or pros about /opt?
Comment 31 Michal Slonina 2005-09-04 03:09:37 UTC
Binary sourceforge tarball brlcad-7.4.0_linux_ia32.tar.bz2 installs to
/usr/brlcad, not only gentoo screws FHS :]
Comment 32 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-09-04 03:59:49 UTC
(In reply to comment #27)  
> I am thinking about packaging whole brlcad-7.4.2 into /usr/brlcad (in  
contrast  
> to puting all files in /usr/bin /usr/share and similar directories). Its a  
big  
> package, and in binary form on sourceforge it exposes such behaviour :)  
> Please let me know what you think, becouse trying to contact gentoo devs on  
irc  
> is pointless :P  
>   
I think that this would be a bad idea - please read Gentoo policy on this. On  
the whole we do try to stick to FHS, but there are specific cases where this  
has not been done. Take a look at the newer xorg-x11 ebuilds that have  
rectified this, and the masked qt-4 ebuilds. KDE itself does not to allow  
multiple major revisions to be installed on the same system.  
  
Contacting us on IRC is not pointless, there are some of us in #gentoo-science.  
The thing is that there aren't very many sci devs, and so we will not respond  
instantly all the time. We have real lives, jobs and stuff making us unable to  
constantly monitor IRC. Please read the FHS and the Gentoo developer docs  
- /opt is for binary packages, /usr is for stuff compiled by the distro.  
  
There is also a mailing list for discussing scientific Gentoo applications  
which can be found on the web site. I would not be inclined to add a new ebuild 
not complying to the FHS unless there is a very good reason for doing so. The 
ones not obeying it now are in general trying to correct this where possible. 
Comment 33 Michal Slonina 2005-09-04 15:57:22 UTC
(In reply to comment #32)
> Contacting us on IRC is not pointless, there are some of us in #gentoo-science.  
> The thing is that there aren't very many sci devs, and so we will not respond  
> instantly all the time. We have real lives, jobs and stuff making us unable to  
> constantly monitor IRC. Please read the FHS and the Gentoo developer docs  
> - /opt is for binary packages, /usr is for stuff compiled by the distro. 
Forgive me being not polite, but it seamed to me that science heard is not
interested in brlcad, and my work will go >/dev/null. If You say that we need to
comply to FHS than so shell it be.

>   
> There is also a mailing list for discussing scientific Gentoo applications  
> which can be found on the web site. I would not be inclined to add a new ebuild 
> not complying to the FHS unless there is a very good reason for doing so. The 
> ones not obeying it now are in general trying to correct this where possible. 

I will subscribe imidietly, thank you for your profesional assistance, and
please accept my appologies.
Comment 34 Michal Slonina 2005-09-04 16:02:04 UTC
Created attachment 67659 [details, diff]
brlcad-7.4.2-gentoo.diff

configure.ac fixes:
 * --datadir fix
 * tk detection fix
 * iwidgets detection fix
Comment 35 Michal Slonina 2005-09-04 16:09:14 UTC
Created attachment 67660 [details]
brlcad-7.4.2.ebuild

remember to:
 * use urt-3.1b.ebuild available in bugzilla ( BUG 104738 )
 * setup TCL_LIBRARY variable ( BUG 104769 )

Thx to brlcad team for their great support in fixing problems.
Rumors say of brlcad-7.6.0...
Comment 36 Michal Slonina 2005-09-04 16:50:16 UTC
(In reply to comment #24)
> It would be a good idea to allow the use of the builtin version...
(tk/tcl/itk/itcl/iwidgets)
If we want to stick to FHS there is no way to use builtin versions.
Try to imagine the hell that will happen when library names are in conflict, all
the linker confusion, etc. Of course we could try to do some heavy voodoo in the
ebuild, but i think that would do more harm than good.
Comment 37 Cliff Yapp 2005-09-05 21:10:25 UTC
Indeed, this built-in vs. installed conflict was one of the original reasons I  
wiped out my system with the first trials.  However, I gather this is not done  
idly on the brl-cad side, and they have reasons for doing this.  It is a hard  
problem, and one I do not see a clear solution for at the moment.  
  
My preferred solution was to put the built-in libs in /usr/lib/brlcad or some  
such and have the brlcad binaries (and only the brlcad binaries) 
use /usr/lib/brlcad before /usr/lib, but a) I don't know if this is workable b) 
even if it is I don't know how to do it and c) it might not get the approval of 
the powers that be. 
 
It may be that brl-cad is simply incompatible with gentoo as things currently 
stand. :-( 
Comment 38 Michal Slonina 2005-09-06 05:57:15 UTC
In reply to #37.
Wrong. Wrong. Wrong.

It is 100% compatibile now :]. Not a single builtin lib needed :] Try the 7.4.2
ebuild and you'll see, the configuration accepts econf defaults gladly. All of
the changes needed for the original source tarball are mainly typo fixes. They
are commited to CVS and will be included in the next brl release.

The separation of tcl/tk/itcl/itk/iwidgets was very hard for brl cad team mainly
becouse of changes needed in the tk library itself. However with the help of
AFAIK debian and gentoo developers, all of modifications to the tk (
tkBezierCanvas ) were split into libtclcad library ( they are going to be
integrated back to tk lib one day ). This split still requiers internal headers
of tk library to implement tkBezierCanvas as a normal tkCanvas, so there is no
way it can be seperated from the main tarball ( otherwise we could not compile
libtclcad, becouse in gentoo tkInt.h and freinds are sent to >/dev/null after tk
installation ) The brlcad build still uses build-in tk/tcl version by default,
but... rummors say that in 7.6 such behaviour will be droped, it is left that
way only for the testing period.

Request from Yosef (comment #24) was just an idea how to avoid unwanted
dependencies on itk and itcl-3.3 and urt. However itk and itcl is in portage (
just unmask, it they work great ) and i submited initial urt ebuild to bugzilla
BUG 104738 ( i hope it will find a maintainer one day :P ). There is a BUG
104769 related to TCL_LIBRARY variable, u need to set it up for the build proces
( and any other normal TCL app? ) to work corectly.
Comment 39 Michal Slonina 2005-09-06 06:00:52 UTC
Created attachment 67737 [details]
CONTESTS of brlcad image genereted by brlcad-7.4.2.ebuild

No collisions with any gentoo package on my system.
Comment 40 Michal Slonina 2005-09-06 06:09:50 UTC
Meaning of "Not a single builtin lib needed" is "library external to brlcad
project".
Please test this ebuild, as only thruout testing can reveal all of the problems
that can still emerge.
Comment 41 MarkE 2005-09-13 03:21:46 UTC
Created attachment 68339 [details, diff]
brlcad-7.4.2-system-tcl.diff

Got brlcad-7.4.2.ebuild working...eventually.

Originally failed during 'configure' while testing for libitcl. I set up the
TCL_LIBRARY env variable and did env-update and source /etc/profile, my
config.log showed that it definately had TCL_LIBRARY defined correctly (sorry,
I lost my config.log). I even tried ITCL_LIBRARY="/usr/lib/itcl3.3" but it
didn't work. Fixed it by manually symlinking libitcl
$ ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so

'configure' then failed because it was using the tcl.h header from the brlcad
package instead of the one in /usr/include. The tcl.h in brlcad has added
#include "common.h" (which is a brlcad header) at line 19 and common.h has the
following at line 50: 
----------------------------------------
#  ifdef HAVE_CONFIG_H
#    include "brlcad_config.h"
#  else
#    include <brlcad/brlcad_config.h>
#  endif
----------------------------------------
I don't know why but it was using <brlcad/brlcad_config.h>, which doesn't exist
("brlcad.h" would work). Either way, configure should be checking against the
system tcl.h in /usr/include. The order of include dirs in the conftest program
was "-I/usr/X11R6/include -I$(top_srcdir)/include -Iinclude", which should find
/usr/include/tcl.h before brlcad/include/tcl.h but it wasn't. Anyway I changed
configure.ac to leave out the -Iinclude and that fixed that problem (see
attached brlcad-7.4.2-system-tcl.diff).

'configure' then failed due to lack of libitk symlink in /usr/lib. After
symlink added, brlcad compiled and merged successfully. I know the itcl3.3
ebuild by Michal Slonina in bugzilla had some symlinking in it, but this was
removed from the ebuild committed to portage by the itcl3.3 maintainer.

In summary, to get working
$echo 'TCL_LIBRARY="/usr/lib/tcl8.4"' > /etc/env.d/50tcl
$env-update; source /etc/profile
$emerge --onlydeps brlcad
$ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so
$ln -s /usr/lib/libitcl3.3.so /usr/lib/libitcl.so
$ln -s /usr/lib/itk3.3/libitk3.3.so /usr/lib/libitcl3.3.so
$ln -s /usr/lib/libitk3.3.so /usr/lib/libitk.so
$mv ~/brlcad-7.4.2-system-tcl.diff /usr/local/portage/sci-misc/brlcad/files
Add "epatch ${FILESDIR}/${PF}-system-tcl.diff" to brlcad-7.4.2.ebuild on the
line after "epatch ${FILESDIR}/${PF}-gentoo.diff"
$ebuild /usr/local/portage/sci-misc/brlcad/brlcad-7.4.2.ebuild digest
$emerge brlcad

Sorry for all the dodgy hacks but I'm not too knowledgeable in these areas.
There's also the chance that I was doing something wrong and I don't need to
symlink and patch, but I killed my config.log so I can't post it.
Comment 42 Jesse Lavigne 2005-10-08 21:15:18 UTC
After setting my TCL_LIBRARY variable, and getting the test ebuild in overlay, I
thought I might be good. I began running into some problems while .configure was
running, unfortunately I didn't think to record the error messages as well as
the packages that they addressed. So far, I have had to install the following
packages in order to get the program to move forward with .configure: 

media-libs/urt
dev-lang/tcl
dev-lang/tk
devl-tcltk/itcl (which also brought in dev-tcltk/iwidgets). 

I of course had to setup the TCL_LIBRARY environmental setting. 

Now, I am getting stopped by incrTcl. It gives me the following info:
checking for Tk library functionality... yes
checking whether to build Tk... no
checking for incrTcl library functionality... no
configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
configure: Try adding --enable-itcl-build
configure: error: *** incrTcl was disabled, yet no usable libitcl system library
was found ***

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/brlcad-7.4.2/work/brlcad-7.4.2/config.log

I will create an attachment with that config.log. 

Any suggestions how I can get past this? Is there any other information I can
provide you with that will help? 
Comment 43 Jesse Lavigne 2005-10-08 21:19:56 UTC
Alas, I could not fine my config.log. The only one on the system seems to be for
something I built by hand that wasn't in portage, and wasn't crucial enough to
request an ebuild. 

Incidentally, I found a link to the incrtcl project on sourceforge. Is this
perhaps something that will need an ebuild for this as well? 
http://incrtcl.sourceforge.net/
Comment 44 Joe Krisch 2005-10-17 13:33:32 UTC
Created attachment 70874 [details]
brlcad 1.6.2 ebuild + diff + manifest + digest

Sorry if I am doing this wrong.  This is my first time.  I figured while I was
trying to get brl-cad working I might as well contribute to this.  

I updated the diff to include the necessary changes for 1.6.2.	I think I have
all my steps here.  I started by:

#echo 'TCL_LIBRARY="/usr/lib/tcl8.4"' > /etc/env.d/50tcl
#env-update; source /etc/profile
#emerge --onlydeps brlcad
#ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so
#ln -s /usr/lib/libitcl3.3.so /usr/lib/libitcl.so
#ln -s /usr/lib/itk3.3/libitk3.3.so /usr/lib/libitcl3.3.so
#ln -s /usr/lib/libitk3.3.so /usr/lib/libitk.so

Then I just did emerge brlcad with my ebuild and diff installed in local
overlay .  Everything seems to work and it is using the system libs.

I hope this is helpful to someone.
Comment 45 Cliff Yapp 2005-10-21 05:33:48 UTC
I take it the most recent ebuild is for 7.6.2 rather than 1.6.2?

I am still dubious about not building the support libraries as distributed 
with brlcad specifically for brlcad.  IIRC they have made changes specifically 
needed for brlcad that have not been rolled back into the support libraries - 
has this changed?  I fear we might get unpredictable failures if we go the way 
the current ebuilds are proposing.  Does anybody have an opinion from the 
brlcad developers on this issue?
Comment 46 Christopher Sean Morrison 2005-11-13 07:39:53 UTC
Thanks to all that have been helping to get the Gentoo ebuild working.  The efforts are very much 
appreciated.  While there is still more work that needs to be done both with the ebuild itself as well as 
to BRL-CAD's build system, I'm glad to see the issues getting resolved so that BRL-CAD may become a 
good citizen on the Gentoo platform.

There have been many comments to date, so I'll just point out a few noteworthies.  1) Release 7.6.4 has 
just posted today which should resolve a few issues.  For example, the incrTcl test using brl-cad's tcl.h 
instead of a system tcl.h issue should be fixed.  2) BRL-CAD's Tk extension still utilizes canvas widget 
internal headers, even though it moved from libtk to libtclcad for the very reason of linking against a 
system tcl/tk.  This particular issue is still being looked into to find a workable solution.  3) Setting 
TCL_LIBRARY "shouldn't" be required unless libtcl is relocated.  There are similar variables for Tk, Itcl, 
etc that rely on the compile-time paths unless relocated as well.  4) Installing to /usr still won't 
necessarily/always work yet due to potential core library naming conflicts that we cannot change (e.g. 
libbu, libbn, librt).  I am working on adding configuration build support to install libraries into $prefix/
lib/brlcad or $prefix/lib/brlcad/VERSION similar to the shared resources so that multiple versions may 
be installed as well as to avoid naming conflicts.  5) Anyone's thoughts on these issues are always 
appreciated.

As for the various possible names of the project (i.e. BRL-CAD versus brlcad versus BRLCAD versus brl-
cad etc) for systems that make a distinction between account names or short names and full names, 
"BRL-CAD" is the preferred long/full name and brlcad is the conventional short/file/dir name (for typing 
convenience mostly).  The "brl-cad" variant is fine for conversation and developer notes and even 
preferred over "brlcad" in discussion but it shouldn't be used on anything official; the other variants 
such as BRLCAD, BrlCAD, BrlCad, etc are discouraged.

Thanks again to everyone that has been contributing to the BRL-CAD ebuild and for helping resolve 
configuration and build issues.
Comment 47 t35t0r 2005-11-30 23:18:08 UTC
Almost got 7.6.4 to compile. I changed this in the 2005-10-17 ebuild attachment:

myconf="${myconf} --enable-regexp-build=yes --enable-png-build=yes \
	--enable-zlib-build=yes --enable-urt-build=yes --enable-termlib-build=yes \
	--enable-tcl-build=yes --enable-tk-build=yes --enable-itcl-build=yes
	--enable-iwidgets-build=yes"

I enabled all those and the errors during configure went away. But at the very
end of the long compile I got this sandbox collision:

/bin/install -c -m 644 ./describe.com.1 /usr/lib/describe.com
ACCESS DENIED  open_wr:   /usr/lib/describe.com
/bin/install: cannot create regular file `/usr/lib/describe.com': Permission denied
make[4]: *** [install-data-local] Error 1
make[4]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other/jove'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other/jove'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src'
make: *** [install-recursive] Error 1

!!! ERROR: sci-misc/brlcad-7.6.4 failed.


..not sure why I'm getting that error. That file doesn't already exist in /usr/lib .
Comment 48 Cliff Yapp 2005-12-01 06:32:41 UTC
IIRC sandbox errors tend to happen when the install process tries to stick a 
file into the "real world" instead of respecting the variables that put it 
into the work directory.  I think what happens is the program goes through a 
complete install in the working directory, and then that install is copied to 
the system directories.  If someone knows better please correct me.

I think this is actually why so much scientific software is hard to write 
ebuilds for - a lot of the authors don't create proper configure - make - make 
install routines and just go straight for the absolute paths, which is a big 
no-no in the ebuild world.  brlcad of course is much better off, so I'm 
guessing this might just be a problem with a particular variable/file.
Comment 49 Christopher Sean Morrison 2005-12-01 07:25:33 UTC
The real short answer is to add --diable-jove-build and it shouldn't have that sandbox error.  The 
configure script will enable jove's compilation by default if it doesn't find an installed jove, but having it 
enabled or disabled isn't critical.  Especially since jove is in portage separately, it should probably be 
disabled explicitly regardless or made a dependency of the package.

That said, there is a sandbox error in jove's Makefile.am where a DESTDIR is missing similar to what we 
ran into earlier with other components of the package a while back.  There are a couple files in jove that 
have custom install rules that only installed to the configure'd install path.  I'll add a fix for DESTDIR to 
keep our sand in the box, should be in the 7.6.6 that's going up probably this weekend.
Comment 50 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-12-02 09:04:36 UTC
Once the new version is out this weekend we will test it out in an overlay. I  
would like to get this added to portage and work out the rest of the kinks. I 
don't think there are any major issues standing in the way now.  
Comment 51 Lucas Chiesa 2006-01-26 12:21:49 UTC
We have been working to get brlcad in the sci overlay. However, we can not make it build. 

A new patch for configure.ac has been made because the provided one has many flaws, like, for example, the tk test fails if DISPLAY is not set, which is not acceptable.

The patch is far from perfect. It replaces the tcl/tk/itcl/iwidgets tests. The tcl and tk are mostly ok, itcl is not so good and the iwidgets test has been removed for now.

Besides, with the patch applied, it fails to compile:

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../../include   -I/usr/X11R6/include -I../../../include  -O2 -march=athlon-xp -fomit-frame-pointer -pipe -fno-strict-aliasing -fno-common -c jove_buf.c
In file included from jove_buf.c:64:
./jove.h:256: warning: built-in function 'exp' declared as non-function
./jove.h:477: error: conflicting types for 'malloc'
./jove.h:477: error: conflicting types for 'malloc'
make[4]: *** [jove_buf.o] Error 1

Please find attached the new ebuild for 7.6.6, based on the latest ebuild from this bug, the patch and tcl.m4 which should be copied to the files directory.

Lucas Chiesa
Comment 52 Lucas Chiesa 2006-01-26 12:23:10 UTC
Created attachment 78208 [details]
sci-misc/brlcad-7.6.6.ebuild
Comment 53 Lucas Chiesa 2006-01-26 12:24:01 UTC
Comment on attachment 78208 [details]
sci-misc/brlcad-7.6.6.ebuild

New ebuild for 7.6.6
Comment 54 Lucas Chiesa 2006-01-26 12:24:59 UTC
Created attachment 78209 [details, diff]
brlcad-7.6.6-gentoo.diff

New patch for configure.ac
Comment 55 Lucas Chiesa 2006-01-26 12:26:08 UTC
Created attachment 78210 [details]
tcl.m4

This m4 file is used by the patched configure.ac. It should be copied to files/
Comment 56 GENTOO ROCKS! 2006-02-16 15:37:58 UTC
Created attachment 79973 [details]
the emerge log file

Hello all!
I'm searching for a good CAD-Programm like Proe etc. i thought brlcad could be a good choice. so i decided to get the ebuild. but my gentoo wont install all aof the above versions. the emerge messege is the following when i try to emerge the 7.6.6 version

 files/brlcad-7.6.2-gentoo.diff
>>> md5 files   ;-) files/brlcad-7.6.6-gentoo.diff
>>> md5 files   ;-) files/digest-brlcad-7.6.6
>>> md5 files   ;-) files/digest-brlcad-7.6.2
>>> md5 files   ;-) files/tcl.m4
>>> md5 src_uri ;-) brlcad-7.6.6.tar.bz2
>>> Unpacking source...
>>> Unpacking brlcad-7.6.6.tar.bz2 to /var/tmp/portage/brlcad-7.6.6/work
 * Applying brlcad-7.6.6-gentoo.diff ...                                                                                     [ ok ]

!!! ERROR: app-cad/brlcad-7.6.6 failed.
!!! Function econf, Line 498, Exitcode 1
!!! no configure script found
also i tried the hint: echo >/etc/env.d/50tcl TCL_LIBRARY="/usr/lib/tcl8.4" but no luck!
i tried much but im not so famillar with gentoo yet.
my system: amd barton 2500+, asus a7n8x-deluxe (nforce2), gf4 gpu, 1gb ram.

main things what i've installed: kde3.4, xorg, kernel 2.6.12-gentoo-r6
my make.conf:
# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
CFLAGS="-O3 -march=athlon-xp -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
#CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
#CXXFLAGS="${CFLAGS}"
ACCEPT_KEYWORDS="x86"
PORTAGE_TMPDIR="/var/tmp"
PORDIR="/usr/portage"
DISTDIR="/distfiles"
PKGDIR="$/distfiles"
PORT_LOGDIR="/var/log/portage"
PORTDIR_OVERLAY="/usr/local/portage"
#GENTOO_MIRRORS="http://gentoo.osuosl.org"
GENTOO_MIRRORS="http://gentoo.eliteitminds.com http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
RSYNC_RETRIES="3"
RSYNC_TIMEOUT="30"
MAKEOPTS="-j2"
PORTAGE_NICENESS="3"
AUTOCLEAN="yes"
FEATURES="ccache distlocks sandbox userpriv usersandbox"
CCACHE_SIZE="2G"
RSYNC_EXCLUDEFROM="/etc/portage/rsync_excludes"
LINGUAS="de"
ALSA_CARDS="intel8x0"
USE="-apm nptl jack jack-tmpfs oss alsa kde qt sse mmx 3dnow opengl X -gtk -gnome artswrappersuid audiofile avi cdr cups cpdflib curl crypt directfb doc dvd dvdr encode fastcgi flac flash ftp jpeg mpeg memlimit portaudio posix sdl samba scanner shared sharedmem theora truetype tiff usb video wmf wxwindows xine xinerama xmms xv xml2"

if ive missing something im very sry!
anyway thx for time and help!
Comment 57 Rogier Eggers 2006-03-17 08:47:02 UTC
Created attachment 82390 [details]
brlcad-7.6.6-r1.ebuild
Comment 58 Rogier Eggers 2006-03-17 08:49:58 UTC
Created attachment 82391 [details]
config.log for failed build
Comment 59 Rogier Eggers 2006-03-17 08:51:58 UTC
There are two spelling errors in the current ebuild: 

"autoconf" should be replaced by "eautoconf. it's the reason why this doesn't build for you GENTOO ROCKS. 

"enable-regexp-build=no" should be replaced with "enable-regex-build=no"

And also '--enable-jove=no' could be added to the configure section afaik. Because jove is also in portage.

See the new ebuild I put up here.

But in the end, brlcad fails to build for me as well:

[snip]
/bin/sh ../../libtool --mode=link i686-pc-linux-gnu-gcc  -mtune=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops -mmmx -msse -ffast-math -frerun-cse-after-loop -pipe -fno-strict-aliasing -fno-common -O3  -L/usr/X11R6/lib -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -O3 -o comb  comb.o librt.la ../../src/libbu/libbu.la
i686-pc-linux-gnu-gcc -mtune=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops -mmmx -msse -ffast-math -frerun-cse-after-loop -pipe -fno-strict-aliasing -fno-common -O3 -pipe -fno-strict-aliasing -fno-common -O3 -o .libs/comb comb.o  -L/usr/X11R6/lib -L/usr/local/lib ./.libs/librt.so /var/tmp/portage/brlcad-7.6.6/work/brlcad-7.6.6/src/libbn/.libs/libbn.so /var/tmp/portage/brlcad-7.6.6/work/brlcad-7.6.6/src/libbu/.libs/libbu.so -lm ../../src/libbu/.libs/libbu.so -lc -lpthread
./.libs/librt.so: undefined reference to `Tcl_CreateFileHandler'
./.libs/librt.so: undefined reference to `Tcl_GetStringResult'
./.libs/librt.so: undefined reference to `Tcl_GetCharLength'
./.libs/librt.so: undefined reference to `Tcl_ListObjGetElements'
./.libs/librt.so: undefined reference to `Tcl_GetDoubleFromObj'
./.libs/librt.so: undefined reference to `Tcl_GetBooleanFromObj'
./.libs/librt.so: undefined reference to `Tcl_ListObjLength'
./.libs/librt.so: undefined reference to `Tcl_ListObjAppendList'
./.libs/librt.so: undefined reference to `Tcl_PkgProvide'
./.libs/librt.so: undefined reference to `Tcl_GetStringFromObj'
./.libs/librt.so: undefined reference to `Tcl_DeleteFileHandler'
./.libs/librt.so: undefined reference to `Tcl_DoOneEvent'
./.libs/librt.so: undefined reference to `Tcl_AppendElement'
[snip] and so on....

I have these tcl related packages:
dev-tcltk/itcl-3.3-r1
dev-tcltk/tcllib-1.7
dev-lang/tcl-8.4.12

Also, see the config.log I posted.

TCL_LIBRARY variable is set. Anybody knows what could be the problem?
Comment 60 Cliff Yapp 2006-06-22 20:46:20 UTC
Created attachment 89873 [details]
Primative ebuild for 7.8.2

This is not an ideal ebuild in that it uses all the internal brl-cad versions of libraries, but it should produce a working brl-cad at least.  jove has a makefile bug that causes a sandbox violation, which is the only reason it is disabled.  The upstream maintainer says this probably isn't worth patching for since jove is just an editor that brl-cad has provided for ~forever...

Anyway - again, not a good ebuild - it's basically a hack and slashed version of the 7.6.6 ebuild.  It's only merit is that it was able to produce a gentoo compiled and installed brl-cad on my machine.

Cheers,
CY
Comment 61 Cliff Yapp 2007-02-03 13:05:26 UTC
Crud - it looks like the above ebuild still overwrites librt and a couple other files in the lib directory that could cause trouble.  It will get you a working brlcad, but may do odd things to your system - Beware!
Comment 62 Cliff Yapp 2007-02-03 14:41:35 UTC
Created attachment 109012 [details]
revdep_rebuild report of damage

As a warning/guide, I've attached revdep-rebuild's report of the carnage that was visited on my system (if history is a guide, only a complete reinstall fill fix this :-( ).  I don't know if this is the ebuild or if I did it myself outside of the system, as I don't think I had the sandbox disabled...
Comment 63 dongxu li 2007-04-17 07:11:49 UTC
now, 7.10.0 is out

let's work out an ebuild for it, also, an ebuild for -cvs
Comment 64 Cliff Yapp 2007-04-17 12:23:50 UTC
Sounds good, but watch out - I've re-installed my system twice after brl-cad ebuild attempts nuked key libraries beyond even revdep-rebuild's ability to repair.  brlcad includes similar libraries to standard installs, but tweaked for brlcad support.  I'm not clear if we can avoid installing them (i.e. if the standard libraries can work) but if not keeping them from conflicting with the "main" system libraries is critical.

My damage report above shows what happened with a gone wrong ebuild attempt, so I'd suggest developing on a test machine if you can.
Comment 65 dongxu li 2007-04-19 16:30:40 UTC
(In reply to comment #62)
> Created an attachment (id=109012) [edit]
> revdep_rebuild report of damage

---------------------------------------------------

add --prefix=/usr/brlcad/ , instead of --prefix=/usr/

to make revdep-rebuild work, run

revdep-rebuild -p
for p0 in $(cat /root/.revdep-rebuild.5_order); do echo $p0;emerge -C =$p0;emerge -1 =$p0;done
emerge -uDN world

Comment 66 dongxu li 2007-04-20 05:21:47 UTC
Created attachment 116773 [details]
ebuilds for 7.10.0 and cvs

the 7.10.0 should build.

the cvs ebuild got problem at checkout, but rerun "emerge brlcad" should work at updating mode.

those ebuilds won't mess up your system, because everything is installed under /usr/brlcad/

finally, /usr/brlcad/bin/mged to launch

I hope some gurus would make some good ebuilds for us still
Comment 67 dongxu li 2007-05-07 23:52:35 UTC
Created attachment 118511 [details]
updated 7.10.0 ebuild

build brlcad-7.10.0 with system regexp, libz, and libpng (if available)
Comment 68 dongxu li 2007-05-08 10:25:45 UTC
Created attachment 118543 [details]
brlcad-0.7.10.ebuild and brlcad-9999.ebuild

both 7.10.0 and -cvs work for me

read postinst info for ENVs needed to launch mged
Comment 69 Cliff Yapp 2007-09-12 02:31:04 UTC
Further improvements made to the BRL-CAD system have gotten it to the point where I think we should look at finalizing an ebuild.  Here's the current situation as far as I know it:

By default, the autoconf scripts will check existing versions of system libraries for versions they need.  If a workable version is found, it will use it.  If not, it will fall back on the included version.

I think the way to handle this is for BRL-CAD to include as DEPENDS every library which MIGHT be used from the system.  This will mean that Gentoo will install the latest available version of each library, and BRL-CAD will test those versions to see if they meet requirements.  If they do, well and good.  If not, BRL-CAD itself will know to fall back onto internal libraries.  Once the libraries on the system are fully capable, a rebuild of BRL-CAD will result in the "correct" behavior for building and (re)installing.  As there are likely to be times where the required versions of libraries will run ahead of "standard" versions in Gentoo (for example, TCL 8.5 is required by 7.10.2) I think this behavior is needed and desirable.

Second, the target directory for install.  The default is /usr/brlcad. There are good reasons for keeping BRL-CAD isolated from the primary lib directories, the main one being some of its libraries will conflict with standard system libraries.  OpenDX seems to do something similar so such a configuration would not be without precedent.

Currently the TCL needed for the system does require a version of the tcl patch for documentation paths - the Makefiles that need patching aren't present before the configure step so the choices are either to track the problem all the way back to its source or apply an epatch after the configure step is run.  The latter seems to be simpler at the moment (it avoids the need to re-run autoconf, for one) although the patch for 7.10.0 doesn't seem to work by default - a new one will need to be made up.

The 7.10.2 ebuild is a test configuration, which needs the new tcl/tk makefiles patch to be generated.  The sed logic in src_install is left in for the moment, although I need to better understand why it is there.

I'm not sure if mged should be symlinked into /usr/bin or not - mged is what most new users of BRL-CAD would start up.

I'm not sure why ADRT support isn't being enabled.  Currently, this is the build config that results from BRL-CAD probing the system:

USE="ef optimize pic proengineer ug" emerge brlcad

BRL-CAD Release 7.10.2, Build 20070910

             Prefix: /usr/brlcad/
           Binaries: /usr/brlcad//bin
       Manual pages: /usr/share/man
Configuration files: /etc
Data resource files: /usr/share
Options & variables: --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/ --enable-pro-engineer-plugin --with-jdk=/opt/sun-jdk-1.5.0.12 --with-pic --disable-debug --enable-ef-build --enable-ug-build --enable-optimized --enable-runtime-debug --build=i686-pc-linux-gnu

CC       = i686-pc-linux-gnu-gcc
CXX      = i686-pc-linux-gnu-g++
CFLAGS   = -O2 -march=i686 -pipe -pipe -fno-strict-aliasing -fno-common -O3
CXXFLAGS = -O2 -march=i686 -pipe -pipe -fno-strict-aliasing -fno-common -O3
CPPFLAGS = -DBRLCADBUILD=1 -I${top_srcdir}/include
LDFLAGS  = -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -O3

Build Tcl ............................: yes
Build Tk .............................: yes
Build Itcl/Itk .......................: yes
Build IWidgets .......................: yes
Build BLT ............................: yes
Build tkImg ..........................: yes
Build libpng .........................: no (using system)
Build libregex .......................: no (using system)
Build zlib ...........................: no (using system)
Build termlib ........................: no (using system)
Build Utah Raster Toolkit.............: no (using system)
Build Template Numerical Toolkit......: yes
Build openNURBS.......................: no (doing without, BREP unsupported)
Build jove ...........................: no

ADRT support .........................: no (need python and sdl)
X11 support ..........................: yes
OpenGL support .......................: yes
Java Developer Kit support ...........: yes (/opt/sun-jdk-1.5.0.12)
Enable run-time debugging ............: yes

Build 64-bit release .................: no (32-bit)
Build optimized release ..............: yes
Build debug release ..................: no
Build profile release ................: no
Build static libraries ...............: yes
Build shared/dynamic libraries .......: yes
Print verbose compilation warnings ...: no
Print verbose compilation progress ...: no

Only build benchmark suite ...........: no
Only build librtserver ...............: no
Install example geometry models ......: yes

Elapsed configuration time ...........: 1 minute, 34 seconds
---
./configure complete, type 'make' to begin building


Comment 70 Cliff Yapp 2007-09-12 02:34:04 UTC
Created attachment 130670 [details]
brlcad-7.10.2 ebuild

Need to generate a new tcl-doc.diff patch for 7.10.2 before this ebuild will work.  It attempts to add all the USE flags that would be appropriate for this use.
Comment 71 Christopher Sean Morrison 2007-09-12 03:07:12 UTC
Thanks again to all the folks working hard on the ebuild, particularly to Cliff.  I'm pretty excited to hear about the progress being made.  We've certainly put a lot of effort into making our build more flexible to the various packaging systems (e.g., decoupling/rewriting what were custom tk mods) including working out details for portage.  We still have a few naming conflicts that prevent a /usr prefix (particularly for our libraries) but the package should integrate a lot better now with respect to the Tcl/Tk problems we had earlier on.

A few comments about Cliff's recent comments and build settings, if I may.  I would also recommend letting BRL-CAD's auto-detection do its thing and not forcibly enabling/disabling dependency options.  If the deps that are tied to the ebuild are installed, then they will be detected during configure and just get used.  If not, the build can (and would) still complete since we include a version of every required dep.

As for the build settings, there are a few components that really don't need to be enabled and probably shouldn't be enabled including the Endgame Framework, Pro/Engineer, and Unigraphics/NX modules.  Those packages all required external (proprietary) developer kits in order for them to compile, not something the vast majority on Gentoo will likely ever have installed.

The Java interface is similarly not used by any of our tools, it's an interface used by 3rd-party developers that hook to our libraries via a jnilib.  It should just be disabled (and Java should NOT be a required BRL-CAD dependency).

Also, ADRT does not need to be manually enabled or disabled, and is not a concern that it shows up disabled.  It's a module that hasn't been fully/properly integrated  yet, so the build system has it forcibly disabled in 7.10.2; and similar to Java, neither SDL or Python should be listed as required BRL-CAD dependencies.  From your list of flags, something like the following would be suggested:

--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/
--with-pic
--enable-optimized
--build=i686-pc-linux-gnu

Cheers!
Sean
Comment 72 Cliff Yapp 2007-09-12 04:27:45 UTC
> A few comments about Cliff's recent comments and build settings, if I may.
> I would also recommend letting BRL-CAD's auto-detection do its thing and
> not forcibly enabling/disabling dependency options.  If the deps that are
> tied to the ebuild are installed, then they will be detected during
> configure and just get used.  If not, the build can (and would) still
> complete since we include a version of every required dep.

Hmm.  Two concerns about such an approach.  I had originally thought to add the dependencies as a concession to the view that BRL-CAD should use system libraries in preference to its own internal copies whenever possible.  This would make sure that whatever the latest copies available on a given version of Gentoo are, they are installed for configure to try.  The second reason and possibly more important (although I admit it occurs to me after the fact) is that if BRL-CAD detects and uses a system library that is not listed in its ebuild requirements, there is a chance (a remote one, but a chance) that a library would be removed or updated without the Gentoo system being aware its removal (or update) would cripple BRL-CAD.  A re-emerge of BRL-CAD would fix the issue however (switching to the internal library version), so perhaps it is not so critical - Gentoo gurus, is there anything about the current emerge system that would be made unhappy in this situation if system libraries in use are not listed as DEPENDS in the ebuild?

> As for the build settings, there are a few components that really don't
> need to be enabled and probably shouldn't be enabled including the Endgame
> Framework, Pro/Engineer, and Unigraphics/NX modules.  Those packages all
> required external (proprietary) developer kits in order for them to compile,
> not something the vast majority on Gentoo will likely ever have installed.

OK - those flags can be removed, obviously :-).  I was just trying to cover all the likely options based on the INSTALL file.  I don't guess those proprietary kits would get used on Gentoo with ebuilds, and if the issue does come up it is simple enough to add them back in.

> The Java interface is similarly not used by any of our tools, it's an
> interface used by 3rd-party developers that hook to our libraries via a
> jnilib.  It should just be disabled (and Java should NOT be a required
> BRL-CAD dependency).

Sounds good.

> Also, ADRT does not need to be manually enabled or disabled, and is not
> a concern that it shows up disabled.  It's a module that hasn't been
> fully/properly integrated  yet, so the build system has it forcibly
> disabled in 7.10.2; and similar to Java, neither SDL or Python should be
> listed as required BRL-CAD dependencies.

OK, sounds good.  It's nice when things get simpler ;-).

> From your list of flags, something like the following would be suggested:
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/
> --with-pic --enable-optimized --build=i686-pc-linux-gnu

Looks good - thanks!  In this situation (ebuild for workstation install) would you suggest enabling optimized in all cases?  As for the --build option, I'll need to look into that - it would have to be conditionalized somehow for each arch.  I don't suppose configure can autodetect it?

Cheers, and thanks!
Cliff
Comment 73 Christopher Sean Morrison 2007-09-13 02:07:26 UTC
(In reply to comment #72)
> Hmm.  Two concerns about such an approach.  I had originally thought to add the
> dependencies as a concession to the view that BRL-CAD should use system
> libraries in preference to its own internal copies whenever possible.  This
> would make sure that whatever the latest copies available on a given version of
> Gentoo are, they are installed for configure to try.  The second reason and
> possibly more important (although I admit it occurs to me after the fact) is
> that if BRL-CAD detects and uses a system library that is not listed in its
> ebuild requirements, there is a chance (a remote one, but a chance) that a
> library would be removed or updated without the Gentoo system being aware its
> removal (or update) would cripple BRL-CAD.  A re-emerge of BRL-CAD would fix
> the issue however (switching to the internal library version), so perhaps it is
> not so critical - Gentoo gurus, is there anything about the current emerge
> system that would be made unhappy in this situation if system libraries in use
> are not listed as DEPENDS in the ebuild?

I would consider that latter case a "bug" in the ebuild.  I.e. if BRL-CAD were dependent upon some unlisted package, the problem really is just that it's not listed and needs to be.  List the proper dependencies and the problem is solved.  I agree that it should just use system libraries and specifically have each one of those listed that is used.  If someone tries to remove a required dependency, it'll show up as required by BRL-CAD.

> OK - those flags can be removed, obviously :-).  I was just trying to cover all
> the likely options based on the INSTALL file.  I don't guess those proprietary
> kits would get used on Gentoo with ebuilds, and if the issue does come up it is
> simple enough to add them back in.

At $10k-$20k USD per license, the market for those developer kits is excessively small and pretty much limited to folks that have a pretty good handle on what to do with getting those kits to work with BRL-CAD.  We're talking about a small number of folks that can probably be counted on one hand.

> Looks good - thanks!  In this situation (ebuild for workstation install) would
> you suggest enabling optimized in all cases?  As for the --build option, I'll
> need to look into that - it would have to be conditionalized somehow for each
> arch.  I don't suppose configure can autodetect it?

The --build option was probably auto-added by portage; my options list was based off of the summary that you posted earlier.  There are probably a lot of other options that are being auto-added that I listed that you do not want to manually list.

As for optimized builds, probably.  I can't think of a good reason at the moment why you wouldn't want to leave that option off other than to use cflags/cxxflags instead of enable-optimized, using optimization settings coming directly from portage that the user had set.  I'm not familiar with how that comes into play on gentoo, whether user-provided optimization settings merely are appended so they override, or if there are separate option sets.  Either way should work just fine.

Cheers!
Sean
Comment 74 Cliff Yapp 2007-09-14 00:56:59 UTC
> I would consider that latter case a "bug" in the ebuild.  I.e. if BRL-CAD
> were dependent upon some unlisted package, the problem really is just that
> it's not listed and needs to be.  List the proper dependencies and the
> problem is solved.  I agree that it should just use system libraries and
> specifically have each one of those listed that is used.  If someone tries
> to remove a required dependency, it'll show up as required by BRL-CAD.

Right.  Sorry, I think I mis-read your comment initially - it sounds like we're on the same page.

> The --build option was probably auto-added by portage; my options list was
> based off of the summary that you posted earlier.  There are probably a lot
> of other options that are being auto-added that I listed that you do not
> want to manually list.

Ah, right.  I'll review a couple other ebuilds, but I think you spotted the key flags.

> As for optimized builds, probably.  I can't think of a good reason at the
> moment why you wouldn't want to leave that option off other than to use
> cflags/cxxflags instead of enable-optimized, using optimization settings
> coming directly from portage that the user had set.  I'm not familiar with
> how that comes into play on gentoo, whether user-provided optimization
> settings merely are appended so they override, or if there are separate
> option sets.  Either way should work just fine.

Hmm.  Well, I would expect portage to use its default settings in make.conf unless specifically overridden, and my guess is that they are appended.  I can try running benchmarks on ebuild and manual builds to see if there is a difference, but I doubt it is too important.  I think you can override settings on a per-emerge command basis (I know this can be done for the USE flag) so I doubt there will be any trouble.

OK, time to get busy.  With any luck I will have some time this weekend to pull something fully functional and conforming to the ebuild guidelines together, and then we can start bugging the portage gods to include it ;-).

Cheers,
CY
Comment 75 Cliff Yapp 2007-09-16 21:11:19 UTC
OK, after some weekend hacking there is now what should be working and "proper" 7.10.2 ebuild.  The fix from dongxu li is included - there was a slight change to the tk makefile evidently between 7.10.0 and 7.10.2, but correcting for that it still seems to do what is intended.  For some reason I can't quite get a single patch file for everything to do its thing, so I've got one for tcl and one for tk.  I doubt it matters much but if someone wants to combine them it shouldn't change anything.

The install target is now /opt/brlcad, which is closer to "proper" practice than /usr/brlcad.  As reading over the bug history will show this has been hashed out before, but I think /opt is emerging as the most desirable option.  There are at least three libraries in BRL-CAD which have name conflicts with standard libraries - not included versions of system installed libraries but truly different libraries.  These can't be renamed because there are compatibilities that must be maintained, so the only viable options appear to be either /opt/brlcad/ or coming up with some sort of /usr/lib/brlcad/ arrangement.  So far /opt appears to work just fine in my testing - normally opt is reserved for binary installations but it seems like a good match for this situation as well.
The earlier observation that BRL-CAD didn't need any duplicate libraries isn't true currently unless (at a minimum) tcl/tk-8.5 is unmasked, and there is no guarantee in the future that available system libraries on a given Gentoo box can be made to work.  /opt avoids all of the potential problems.

An env.d file containing the PATH and MANDIR settings for BRL-CAD is also included in the files directory.  This file will be installed into /etc/env.d and once env-update && source /etc/profile are run will result in mged and friends being in the path by default.  There is also a license file to be added for the documentation - BLD.

I've run repoman over the ebuild and gone over all the ebuild writing policy I can find.  To the best of my knowledge, BRL-CAD is now ready for inclusion in portage.

Thanks to Sean and his team, who did all the really hard work to make this possible, and to the army of ebuild writers who have tackled this!  Now we need to find out of there is a developer who is willing to sponsor this in the main portage tree itself.

Cheers,
CY
Comment 76 Cliff Yapp 2007-09-16 21:13:09 UTC
Created attachment 131083 [details]
Updated BRL-CAD ebuild

This version installs to /opt/brlcad, including the env.d settings needed.
Comment 77 Cliff Yapp 2007-09-16 21:14:04 UTC
Created attachment 131085 [details, diff]
tcl patch

Patch for tcl makefile per earlier 7.10.0 patch
Comment 78 Cliff Yapp 2007-09-16 21:14:38 UTC
Created attachment 131087 [details, diff]
tk patch

tk Makefile patch
Comment 79 Cliff Yapp 2007-09-16 21:15:39 UTC
Created attachment 131089 [details]
env.d file for /opt/brlcad paths

Installed by ebuild in /etc/env.d
Comment 80 Cliff Yapp 2007-09-16 21:16:39 UTC
Created attachment 131091 [details]
BDL documentation license

This is the BRL-CAD documentation license, which doesn't seem to be in portage.  I currently have it in /usr/local/portage/licenses
Comment 81 Cliff Yapp 2007-09-16 21:22:42 UTC
Created attachment 131094 [details]
Convenient bundle of brl-cad files (except BDL license)

The previous files are submitted in order to comply with policy.  If anyone wants a shortcut, this tarball contains everything except the BDL license file (which needs to go elsewhere after all.)  This file also has a ChangeLog and metadata.xml included in case that's of any help to the gentoo dev(s).  I use this by making sure that:

a)  /usr/local/portage is an overlay in make.conf (there are docs on overlays)
b)  make sure /usr/local/portage exists in the filesystem
c)  mkdir /usr/local/portage/licenses
d)  place the BDL file in /usr/local/portage/licenses
e)  mkdir /usr/local/portage/sci-misc
f)  place the above tar file in /usr/local/portage/sci-misc
g)  tar -xvzf brlcad-7.10.2-ebuild.tar.gz

The last step should expand to a brlcad directory with the necessary contents.  After that, it should work as expected.

Feedback appreciated.

Cheers,
CY
Comment 82 Steve L 2007-09-16 23:57:36 UTC
It compiles and loads fine here on x86 (athlon), except if profile USE flag is set when it failed:

checking if compiler and linker recognize -pg... no
configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
configure: Profiling was enabled but -pg does not work
configure: error: *** Don't know how to profile with this compiler ***

I imagine that's an ICC option?
I haven't tried loading any files (I don't know this package at all) but mged ran without complaint, no warnings or anything to console.

Well done for getting there in the end :-)
Comment 83 Christopher Sean Morrison 2007-09-17 02:12:07 UTC
(In reply to comment #82)
> It compiles and loads fine here on x86 (athlon), except if profile USE flag is
> set when it failed:
> 
> checking if compiler and linker recognize -pg... no
> configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
> configure: Profiling was enabled but -pg does not work
> configure: error: *** Don't know how to profile with this compiler ***
> 
> I imagine that's an ICC option?
> I haven't tried loading any files (I don't know this package at all) but mged
> ran without complaint, no warnings or anything to console.
> 
> Well done for getting there in the end :-)

Steve, I've just added a check for icc's -p option (which adds gprof instrumentation) to the latest sources so it'll be in subsequent releases.

The reason it wasn't already in there, though, is because ICC's best profile instrumentation uses their multiphased build-run-rebuild passes (using -prof_gen, -prof_use, and family).  That's a bit "too much" to hook into configure given how frequently that compiler is used for that purpose, so I've just added the flags by hand as needed.  So now, though, with -p added, it'll work with gprof, but it's not going to give the nice performance tuned binaries you might be looking for.

Cheers!
Sean
Comment 84 Cliff Yapp 2007-09-17 23:34:49 UTC
OK, one more tweak - it was suggested that it would be better to patch the Makefile.in files rather than the Makefiles.  The updates to the ebuild and patch files do this, and it has built successfully on my machine - ebuild runs the autogen.sh script.
Comment 85 Cliff Yapp 2007-09-17 23:37:05 UTC
Created attachment 131177 [details, diff]
patch for tcl/tk makefiles

Used proper ebuild patch-building procedure, one file now.
Comment 86 Cliff Yapp 2007-09-17 23:38:08 UTC
Created attachment 131178 [details]
brlcad-7.10.2.ebuild (patches correct files now)

Correct patch options, cut profile flag for now.
Comment 87 Cliff Yapp 2007-09-17 23:39:44 UTC
Created attachment 131180 [details]
Convenient bundle of brl-cad files (except BDL license) [updated]

Update of earlier tarball.
Comment 88 Cliff Yapp 2007-09-17 23:53:27 UTC
Created attachment 131182 [details]
Convenient bundle of brl-cad files (except BDL license) [updated]

Oops (obsolete older tarball(s) to avoid confusion)
Comment 89 Cliff Yapp 2007-09-17 23:54:30 UTC
Created attachment 131183 [details]
brlcad-7.10.2-ebuild tarball

Sigh.  And put in correct file type (sorry for the spam)
Comment 90 Marijn Schouten (RETIRED) gentoo-dev 2007-09-20 14:32:39 UTC
(In reply to comment #89)
> Created an attachment (id=131183) [edit]
> brlcad-7.10.2-ebuild tarball

wtf is this?
Comment 91 Marijn Schouten (RETIRED) gentoo-dev 2007-09-20 14:34:46 UTC
from the ebuild:

	insinto /etc/env.d
	newenvd "${FILESDIR}"/brlcad.envd 99brlcad

that insinto doesn't do anything I think. And why not name the file 99brlcad in the first place?
Comment 92 Cliff Yapp 2007-09-20 17:05:31 UTC
The tarball is simply a convenience bundle of the files I had in /usr/local/portage/sci-misc/brlcad for anyone who wanted to try it - it's easier than grabbing everything one by one and placing them by hand.

As for the env.d - I think that command is a leftover before I used the newenvd command, so it can go.  The filename itself - does it matter?  IIRC I was using the same conventions for that as I saw in other ebuilds in portage.
Comment 93 Cliff Yapp 2007-10-26 21:39:13 UTC
Created attachment 134457 [details]
Version update to latest, remove unneeded line
Comment 94 Bob Paddock 2007-10-29 01:08:00 UTC
Shouldn't 
"	einfo "To run an example, try /opt/brlcad/bin /opt/brlcad/db/havoc.g" read

"/opt/bclad/bin/mged /opt/brlcad/db/havoc.g" ?

The 'mged' is missing after the /bin .


Anyone know how well, or if brlcad will work on a AMD64 box?

I got this when I tried:

/opt/brlcad/bin/mged /opt/brlcad/db/havoc.g
Initializing and backgrounding, please wait...Itcl_Init error Can't find a usable itcl.tcl in the following directories:
    /opt/brlcad/lib/itcl3.3 ./../lib/itcl3.3 ./../library ./../../library ./../../itcl/library ./../../../itcl/library ./../../../../itcl/library ./../../../../../itcl/library ./src/other/incrTcl/itcl/library ./../src/other/incrTcl/itcl/library ./../../src/other/incrTcl/itcl/library ./../../../src/other/incrTcl/itcl/library ./../../../../src/other/incrTcl/itcl/library ./../../../../../src/other/incrTcl/itcl/library
This probably means that Itcl/Tcl weren't installed properly.
If you know where the Itcl library directory was installed,
you can set the environment variable ITCL_LIBRARY to point
to the library directory.

Can't find a usable itk.tcl in the following directories:
    /opt/brlcad/lib/itk3.3 ./../lib/itk3.3 ./../library ./../../library ./../../itk/library ./../../../itk/library ./../../../../itk/library ./../../../../../itk/library ./src/other/incrTcl/itk/library ./../src/other/incrTcl/itk/library ./../../src/other/incrTcl/itk/library ./../../../src/other/incrTcl/itk/library ./../../../../src/other/incrTcl/itk/library ./../../../../../src/other/incrTcl/itk/library
This probably means that Itcl/Itk weren't installed properly.
If you know where the Itk library directory was installed,
you can set the environment variable ITK_LIBRARY to point
to the library directory.

MGED Aborted.
Done

brlcad does seem to work in 32bit chroot.
Comment 95 Cliff Yapp 2007-10-29 01:36:30 UTC
Good catch - it is indeed mged.

Not sure about AMD64 - that's not a platform I have available to test on :-(.
Comment 96 Cliff Yapp 2007-10-29 01:38:55 UTC
Created attachment 134602 [details]
7.10.4 - Fix the info message to actually specify the mged binary
Comment 97 Cliff Yapp 2007-10-29 01:52:18 UTC
(In reply to comment #94)

> MGED Aborted.
> Done
> 
> brlcad does seem to work in 32bit chroot.

Request from upstream - would it be possible to provide a configure and build log as well as the config.log file?  As attachments to the bug here is fine.
 

Comment 98 Bob Paddock 2007-10-31 23:44:02 UTC
(In reply to comment #95)
> Good catch - it is indeed mged.
> 
> Not sure about AMD64 - that's not a platform I have available to test on :-(.

From my testing it looks like what needs done is that /opt/brlcad/lib64
needs added to the lib path, as it is not there now.

Specifying the libraries manually brings mged up:

~ $ ITK_LIBRARY=/opt/brlcad/lib64/itk3.3 ITCL_LIBRARY=/opt/brlcad/lib64/itcl3.3 /opt/brlcad/bin/mged /opt/brlcad/db/havoc.g
Initializing and backgrounding, please wait...Opened in READ ONLY mode
Done

Comment 99 Bob Paddock 2007-10-31 23:54:23 UTC
Created attachment 134848 [details]
configuration log for build on AMD64

configuration log for build on AMD64.
Comment 100 Bob Paddock 2007-10-31 23:54:53 UTC
Created attachment 134849 [details]
emerge --info for build on AMD64

emerge --info for build on AMD64
Comment 101 M. B. 2007-11-01 01:22:36 UTC
I have been able to build and work with brlcad within amd64. Not much though. But if specific test are required I'm willing to play guinea pig - just drop me a line.

The missing itcl/itk paths did I solve by creating symbolic links in /opt/brlcad/lib/itcl3.3 to /opt/brlcad/lib64/itcl3.3 and itk3.3 respectively.
Comment 102 Cliff Yapp 2007-11-14 23:05:16 UTC
Created attachment 136002 [details]
Updated BRL-CAD ebuild

In the ongoing effort to make an inclusion-worthy ebuild, here is the latest effort.  Thanks to Sébastien Fabbro for much helpful advice.

New points:

1. Install is now done in /usr/$(get_libdir)/brlcad instead of /opt, in order to comply with the "binary only" designation for the /opt directory.

2.  Removed tcl/tk depends, which are covered by itcl/itk.  Added blt.  

3.  Switched from pre-existing 99brlcad file to one created by the ebuild process itself, in order to ensure the correct $(get_libdir) value.

4.  Further consolidated ebuild flags - I'm not sure if this is TOO far but this should be correct for "normal" operation and Sébastien's thought was that people wanting large scale customization would be likely to build their own copy outside portage.

5.  Additional use of the $(get_libdir) variable in the configure setup - this MAY fix the issues seen with the lib64 directory paths on AMD64, but I'm not completely sure - testing definitely appreciated.

Things not yet changed:

1.  Still calling BRL-CAD's own autogen.sh script - eautoreconf doesn't seem to work when I tried it.  (Noted in the comments.)  Running autoconf is motivated by patching the Makefile.in file rather than the Makefile directly (per earlier comments) - that's the "correct" way to do it.  It may be possible to patch both if running the autogen.sh script is a major problem, but considering how long the BRL-CAD build is anyway I personally think this is acceptable.

2.  BRL-CAD in this version will still build mostly internal libraries.  The cvs  tree of BRL-CAD has some logic to check for 8.4 and friends and use those if available, but the 7.10.4 tarball would need patching.  Some of these libraries (tkimg is one example) do not yet have ebuilds in the main tree, so attempting to correct this wholesale would involve the from-scratch creation of several ebuilds and approval of anywhere from two to four+ for inclusion in the main tree at the same time as BRL-CAD itself.  My take on this is to allow the process to be a gradual one - as more libraries are added to the tree and new BRL-CAD releases appear, the need for internal lib building will gradually fall away without any real fuss.  I know this is a hot button topic, but if this and the previous issue are the last two major ones standing in the way of this being adopted we must either begin the large scale ebuild process or reach a decision to go ahead and gradually wean the build off of internal libs.

There may still be a couple minor style points - I'm not sure I've gotten everything to the last detail, but I'd like the AMD64 guys (if willing) to give this a try and see if it works out of the box for them.

CY
Comment 103 Bob Paddock 2007-11-15 00:01:12 UTC
Still not working out of the box on AMD64.

There is no such thing as /usr/lib64/brlcad/lib/itcl3.3 .
Should that not be /usr/lib/brlcad/lib64 ?

/usr/lib/brlcad/bin/mged
Initializing and backgrounding, please wait...Itcl_Init error Can't find a usable itcl.tcl in the following directories:
    /usr/lib64/brlcad/lib/itcl3.3 ./../lib/itcl3.3 ./../library ./../../library ./../../itcl/library ./../../../itcl/library ./../../../../itcl/library ./../../../../../itcl/library ./src/other/incrTcl/itcl/library ./../src/other/incrTcl/itcl/library ./../../src/other/incrTcl/itcl/library ./../../../src/other/incrTcl/itcl/library ./../../../../src/other/incrTcl/itcl/library ./../../../../../src/other/incrTcl/itcl/library
This probably means that Itcl/Tcl weren't installed properly.
If you know where the Itcl library directory was installed,
you can set the environment variable ITCL_LIBRARY to point
to the library directory.

Can't find a usable itk.tcl in the following directories:
    /usr/lib64/brlcad/lib/itk3.3 ./../lib/itk3.3 ./../library ./../../library ./../../itk/library ./../../../itk/library ./../../../../itk/library ./../../../../../itk/library ./src/other/incrTcl/itk/library ./../src/other/incrTcl/itk/library ./../../src/other/incrTcl/itk/library ./../../../src/other/incrTcl/itk/library ./../../../../src/other/incrTcl/itk/library ./../../../../../src/other/incrTcl/itk/library
This probably means that Itcl/Itk weren't installed properly.
If you know where the Itk library directory was installed,
you can set the environment variable ITK_LIBRARY to point
to the library directory.

MGED Aborted.
Comment 104 Cliff Yapp 2007-11-15 01:56:25 UTC
Created attachment 136013 [details]
Updated BRL-CAD ebuild - Try a different libdir path for AMD64...

Hmm.  OK, maybe I got too clever for my own good.  It's looking in /usr/lib64/brlcad/lib, so let's see if this sets it correctly...
Comment 105 Cliff Yapp 2007-11-15 02:01:40 UTC
Wait, sorry - got ahead of myself.  Where is it actually installing on your system - is it /usr/lib64/brlcad or /usr/lib/brlcad, and inside that root is it in lib or lib64?

I was hoping the use of the $(get_libdir) variable would do the "right thing" for the platform in question, but maybe not...
Comment 106 Cliff Yapp 2007-11-15 02:19:19 UTC
Created attachment 136014 [details]
One other possibility - need to inherit multilib explicitly?

One other possibility to try - I may have forgotten to pull in a needed eclass package to make the get_libdir variable do the "right thing".

Sorry for all the guesswork :-(.  If someone can point me to some good docs on this type of issue with portage/ebuilds I'd be obliged.
Comment 107 Bob Paddock 2007-11-15 11:16:01 UTC
/usr/lib is a simlink to /usr/lib64 on *most* AMD64 systems,
but not all.  Something to do with multilib stuff.

bob@tux ~ $ ls /usr/lib -l
lrwxrwxrwx 1 root root 5 Sep  1 04:45 /usr/lib -> lib64
bob@tux ~ $

The real issue is the brlcad/lib vs brlcad/lib64:


bob@tux ~ $ ls /usr/lib64/brlcad/lib
blt2.4  tcl8  tcl8.5  tk8.5
bob@tux ~ $

That is all that is in brlcad/lib.

bob@tux ~ $ ls /usr/lib64/brlcad/lib64
itcl3.3              libitcl3.3.so               libpkg.so
itk3.3               libitcl3.3.so.0             libpkg.so.19
iwidgets4.0.1        libitcl3.3.so.0.0.0         libpkg.so.19.0.1
[and lots more]
libfft.so.19.0.1     liboptical.so.19.0.1        tclConfig.sh
libitcl.a            liborle.a                   tk8.5
libitcl.la           liborle.la                  tkConfig.sh
libitcl.so           liborle.so                  tkimg.a
bob@tux ~ $

is in lib64.

Should there be a brlcad/lib at all?
Comment 108 Cliff Yapp 2007-11-15 13:43:03 UTC
I had hoped that using $(get_libdir) where I did in the configure script with the most recent ebuild (which inherits multilib eclass) might do the "right thing" - it SEEMS like there should be a way to provide the correct options to make this work.  If there are any "hard coded" instances of lib anywhere that might be a problem, but it's rather difficult to test on my system since all I've got anywhere is lib :-/.

I think I messed up the first use of $(get_libdir) by not inheriting the eclass, so there's a chance it will behave differently now, but the only way to test it is for someone to try it unless there's a way to "fake" that part of the ebuild expansion.  (Or, alternately, someone could watch the build until they spot the configure options and then kill it...)
Comment 109 Sébastien Fabbro (RETIRED) gentoo-dev 2007-12-19 13:24:58 UTC
Hi,

I bumped brlcad-7.10.4 in the science overlay. I will probably not have time to maintain it, so feel free to submit patches here (as txt files) that I can quickly commit to the overlay. Once the ebuild stable, it may go to the main tree.

There are many changes since the last attachment, so please review them as much as you can. The main problem I encountered was the tcl-8.5 dependencies. I tried using the masked ones from the tree, but then all other tcl/tk packages required for brlcad would fail the configure tests. Building brlcad from system libs would be really nice and for sure would speed up its inclusion in main tree.


For those not yet familiar with the science overlay, see http://www.gentoo.org/proj/en/overlays/userguide.xml and use layman -a science.


Thanks all for your work!

Comment 110 Cliff Yapp 2007-12-19 16:33:16 UTC
First off - thank you!

Looking over the ebuild in the sci overlay, I have a couple of questions:

Is it OK use /usr/brlcad for this?  Most of the reason for the multilib logic was to be able to use /usr/lib/brlcad (or /usr/lib64/brlcad) automatically.  I can't remember precisely where I got it but I had found somewhere a suggestion that installing things into /usr/$APP directories was discouraged by Gentoo Policy.  Is that not actually the case?

Also, the patch changes the Makefile.in files and not the pre-existing makefiles - hence re-running the autogen routines.  Did you test the sci overlay ebuild with the file overwrite protections on?  Perhaps it's not needed but I had assumed the autogen script was needed to propagate the changes from the Makefile.in files to the actual Makefiles

Hopefully building with system libs will come in a future version of BRL-CAD, but there are at least a couple of the libs that either don't have ebuilds or have ebuilds only in the overlays.  Getting such a BRL-CAD ebuild in the main tree would require a coordinated introduction of supporting ebuilds as well. 
Comment 111 Sébastien Fabbro (RETIRED) gentoo-dev 2007-12-19 16:50:22 UTC
 > Is it OK use /usr/brlcad for this?  

It's either this simple way or a fully patched ebuild to respect FHS. Since brl-cad overwrites the name of a whole lot of libraries (such as librt from glibc), we need to put it somewhere not dangerous. And I noticed if we specify more dir options, it will start dropping files (like html, ex) all over the system. So it would need to patch a bunch of Makefiles. The solution right now is not optimum since it still pollutes the /usr/brlcad/doc with useless files.

> but I had assumed the autogen script was needed to propagate the changes from
> the Makefile.in files to the actual Makefiles

The autogen.sh script builds the configure script. The configure script takes the Makefile.ins and produces the Makefiles.
 
> Hopefully building with system libs will come in a future version of BRL-CAD,
> but there are at least a couple of the libs that either don't have ebuilds or
> have ebuilds only in the overlays.  Getting such a BRL-CAD ebuild in the main
> tree would require a coordinated introduction of supporting ebuilds as well. 

Which ones we don't have ebuilds? In the overlay we have tkimg, tnt and jama.
Comment 112 Cliff Yapp 2007-12-20 01:00:50 UTC
(In reply to comment #111)

> And I noticed if we specify more dir options, it will start dropping files
> (like html, ex) all over the system. So it would need to patch a bunch of
> Makefiles. 

Can you provide a little more detail on that behavior?  There is upstream interest in understanding and possibly correcting the behavior you're seeing.
Comment 113 Cliff Yapp 2007-12-20 01:16:25 UTC
(In reply to comment #111)

> Which ones we don't have ebuilds? In the overlay we have tkimg, tnt and jama.

Oh, good - I didn't realize you had all of those.  The remaining fly in the soup is probably opennurbs, which isn't required now but may be fairly soon.

opennurbs (http://www.opennurbs.org/) is a bit odd - it's got a download form requirement, but its license seems to be very liberal.  If Gentoo wanted to have an easy-to-install ebuild it would require re-hosting the file in question (preferably rebundled as a tar.gz with a version number...) or doing some kind of fetch restrictions ala the old sun-jdk installs.  Also it seems to have a version of zlib bundled, so that would need to be patched to use the system version...

Is anyone working on opennurbs for an ebuild?  And does Gentoo have provisions for hosting a file when there are non-license-required fetch restrictions?
Comment 114 dongxu li 2007-12-25 15:28:50 UTC
Created attachment 139280 [details]
brlcad-cvs ebuild

tcl/tk doc-Makefile patch not needed any more
Comment 115 dongxu li 2007-12-25 15:31:37 UTC
Created attachment 139282 [details, diff]
no need to check for /usr/local

a trivial patch file to be used by brlcad-cvs ebuild
Comment 116 dongxu li 2007-12-25 15:35:50 UTC
Created attachment 139283 [details]
brlcad-7.10.4-r2

it builds and runs for me now.

the tcl/tk Makefiles still need the patch for do-docs.

some broken symlink for libraries. I'm using a naive fix for librt
Comment 117 dongxu li 2007-12-25 16:24:54 UTC
Created attachment 139284 [details]
brlcad-9999-r1.ebuild

some minor changes.
the /usr/local patch still included.
http://bugs.gentoo.org/attachment.cgi?id=139282

hopefully, /etc/env.d/99brlcad is correct now
Comment 118 dongxu li 2007-12-25 23:40:01 UTC
Created attachment 139319 [details]
brlcad-7.10.4-r2.ebuild

make the 7.10.4

http://sourceforge.net/project/showfiles.php?group_id=105292 shows source files by arch. we should better to include this feature in SRC_URI
Comment 119 Richard Westwell 2008-04-15 22:30:40 UTC
Created attachment 149864 [details]
brlcad-7.12.0.ebuild

here's one for 7.12.0, only a couple of minor changes
I had to disable autogen.sh (regenerating the configure script instead of using the default seemed to stop things from working on amd64 at least)
also the data files should now be located within /usr/share/brlcad instead of /usr/share directly

remember to log out, log back in again after installing to make sure ITK_LIBRARY ITCL_LIBRARY is updated in the environment variables
Comment 120 Richard Westwell 2008-05-07 21:06:45 UTC
Created attachment 152375 [details]
brlcad-7.12.2.ebuild

version updated, no changes to the ebuild
Comment 121 Auke Booij (tulcod) 2008-05-13 19:42:32 UTC
i'm really interested in this package, can anyone maintain it anywhere? (sunrise? maybe even portage?)
Comment 122 Auke Booij (tulcod) 2008-05-13 19:47:13 UTC
argh, i'm sorry guys, i *really* read the comments, but i obviously missed "science overlay" about a million times. sry.
Comment 123 Facundo de Guzmán 2008-10-01 22:57:30 UTC
Version 7.10.4 is affected by this bug http://bugs.gentoo.org/show_bug.cgi?id=225999

Are the last versions affected also?

When I try to run mged I get this:

Can't find a usable tk.tcl in the following directories: 
    /usr/brlcad/lib/tk8.5

/usr/brlcad/lib/tk8.5/tk.tcl: no event type or button # or keysym
no event type or button # or keysym
    while executing
"bind Listbox <MouseWheel> {
        %W yview scroll [expr {- (%D / 120) * 4}] units
    }"
    invoked from within
"if {[tk windowingsystem] eq "aqua"} {
    bind Listbox <MouseWheel> {
        %W yview scroll [expr {- (%D)}] units
    }
    bind Listbox <Option-Mou..."
    (file "/usr/brlcad/lib/tk8.5/listbox.tcl" line 182)
    invoked from within
"source /usr/brlcad/lib/tk8.5/listbox.tcl"
    (in namespace eval "::" script line 1)
    invoked from within
"namespace eval :: [list source [file join $::tk_library $file.tcl]]"
    (procedure "SourceLibFile" line 2)
    invoked from within
"SourceLibFile listbox"
    (in namespace eval "::tk" script line 4)
    invoked from within
"namespace eval ::tk {
	SourceLibFile button
	SourceLibFile entry
	SourceLibFile listbox
	SourceLibFile menu
	SourceLibFile panedwindow
	SourceLibFile ..."
    invoked from within
"if {$::tk_library ne ""} {
    proc ::tk::SourceLibFile {file} {
        namespace eval :: [list source [file join $::tk_library $file.tcl]]
    }
   ..."
    (file "/usr/brlcad/lib/tk8.5/tk.tcl" line 401)
    invoked from within
"source /usr/brlcad/lib/tk8.5/tk.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source $file]"


This probably means that tk wasn't installed properly.

MGED Aborted.
Comment 124 Facundo de Guzmán 2008-10-05 16:57:24 UTC
Created attachment 167322 [details, diff]
Patch to brlcad internal tk build

This patch fixes the issue with the new Xorg-server 1.5 and Tk that I mentioned in the comment above. It patches the internal tk source of brlcad. Tested with ebuild 7.12.2
Comment 125 Steve L 2008-12-10 05:43:21 UTC
Is this ready to go to maintainer-wanted and sunrise?
Comment 126 Sébastien Fabbro (RETIRED) gentoo-dev 2008-12-10 23:08:07 UTC
(In reply to comment #125)
> Is this ready to go to maintainer-wanted and sunrise

Why? This is already in the science overlay, comment #109.
Comment 127 Luis Ferreira 2009-02-14 10:14:47 UTC
ACCEPT_KEYWORDS="~x86"  emerge -av brlcad

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] sci-libs/tnt-3.0.10  49 kB [1]
[ebuild  N    ] sci-libs/jama-1.2.5  USE="-doc" 16 kB [1]
[ebuild  N    ] sci-misc/brlcad-7.10.4  USE="-debug -examples" 22,437 kB [1]

Total: 3 packages (3 new), Size of downloads: 22,502 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/portage/local/layman/science

Would you like to merge these packages? [Yes/No] yes

>>> Verifying ebuild manifests

!!! Digest verification failed:
!!! /usr/portage/local/layman/science/sci-misc/brlcad/ChangeLog
!!! Reason: Filesize does not match recorded size
!!! Got: 917
!!! Expected: 703
Comment 128 Christopher Sean Morrison 2009-02-14 16:05:49 UTC
For anyone working this, the upcoming 7.14.4 release (by end of Feb) includes some new search logic that allows arbitrary mixtures of system and non-system installs of incrTcl and Tcl/Tk.  In the past (as mentioned by others in this thread), you could encounter an Itcl_Init failure when running mged that should now be taken care of.  Moreover, the fix also allows for a more varied matching back-support for 8.4 or 8.5 Tcl/Tk (the latter recommended) as well as Itcl 3.2 or 3.3 (latter required if 8.5).

It would be nice to have some closure on our portage integration if there is a maintainer willing to keep it up to date.  I think there have been four releases or so since the last update.
Comment 129 dongxu li 2009-03-01 13:57:59 UTC
Created attachment 183556 [details]
brlcad-7.12.6.ebuild

ebuild for 7.12.6
needs the usr-local.patch
Comment 130 dongxu li 2009-03-01 13:59:52 UTC
(In reply to comment #124)
> Created an attachment (id=167322) [edit]
> Patch to brlcad internal tk build
> 
> This patch fixes the issue with the new Xorg-server 1.5 and Tk that I mentioned
> in the comment above. It patches the internal tk source of brlcad. Tested with
> ebuild 7.12.2
> 

I couldn't user this brlcad-tk patch. mged segfaults on opening database
Comment 131 Cliff Yapp 2009-03-03 03:33:37 UTC
If you're segfaulting trying to use the graphical file open dialog, I saw similar behavior here - clicking on a file in the dialog caused a Tk level failure and segfault.  Upgrading to tcl/tk 8.5.6 has fixed it here, but that won't be in a release until 7.14.4 (coming very soon.)
Comment 132 dongxu li 2009-03-05 22:01:46 UTC
(In reply to comment #131)
> If you're segfaulting trying to use the graphical file open dialog, I saw
> similar behavior here - clicking on a file in the dialog caused a Tk level
> failure and segfault.  Upgrading to tcl/tk 8.5.6 has fixed it here, but that
> won't be in a release until 7.14.4 (coming very soon.)
> 

I have exactly tcl/tk-8.5.6

I got ekiga-3.0.2 segfaults also, not sure the gtk errors there related or not 
Comment 133 dongxu li 2009-03-27 08:35:53 UTC
Created attachment 186392 [details]
brlcad-7.14.4.ebuild

this will build 7.14.4, but many USE flags ignored here.

need more investigation here.

you would need tcl/tk-8.5
Comment 134 dongxu li 2009-05-25 10:04:42 UTC
Created attachment 192384 [details]
brlcad-7.14.8.ebuild

brlcad-7.14.8.ebuild
need some work to clean up leftovers from previous versions, but this ebuild emerges and works for me.
Comment 135 dongxu li 2009-05-25 18:07:52 UTC
Created attachment 192428 [details]
brlcad-7.14.8.ebuild

updated env.d, no need to set LDPATH etc.
Comment 136 Thomas Raschbacher gentoo-dev 2009-05-26 08:50:06 UTC
7.18.4 is out by now .. is anyone going to add it to the science overlay? - would be nice ;)
Comment 137 Thomas Raschbacher gentoo-dev 2009-05-26 08:54:35 UTC
sorry meant 7.14.8
Comment 138 Thomas Raschbacher gentoo-dev 2009-05-27 13:42:45 UTC
put 7.14.8 in my overlay for now ..
Comment 139 Thomas Raschbacher gentoo-dev 2009-05-29 11:55:03 UTC
The location of the havoc.g file seems to have changed. the correct einfo line should be as follows: (updated in my dev overlay)

einfo "${brlcadprefix}/bin/mged ${brlcadprefix}/share/brlcad/${PV}/db/havoc.g"
Comment 140 Christopher Sean Morrison 2009-05-29 14:42:37 UTC
It's not moved, the ebuild has just been wrong since after one of the 7.10 updates and nobody noticed.

A few other notes about the ebuild:

1) blt is no longer a dependency so should remove the DEPEND line and the --enable-libblt-build compile option.

2) there's no code limitation that limits compilation to just ~amd64 ~x86.  should compile on pretty much anything Gentoo supports.

3) --enable-documentation, --enable-models, --enable-iwidgets-build, --enable-libblt-build, and --enable-opennurbs-build should be removed as they do nothing or in the case of a couple are at least unnecessary.  the --enable-iwidgets-build option conflicts with setting dev-tcltk/iwidgets as a dependency.  If --enable-documentation is going to be added, there are additional dependencies that should be specified.  default behavior on most configure options is auto-detect and enabling a build without the dependency will result in a configure abort.

4) should declare a DEPEND dependency on a lexer/parser (e.g., bison/flex).  not strictly required, but will provide desirable functionality.

5) most of the commented lines should just be removed as they are out-dated (except MANPATH, should set that, but not the rest).

6) The postinst message should refer users to http://brlcad.org/wiki/Documentation in addition to the path to havoc.g being wrong.

Cheers!
Sean
Comment 141 dongxu li 2009-06-01 21:17:11 UTC
Created attachment 193188 [details]
brlcad-7.14.8.ebuild

updated configure options, I still don't know what DEPENDs for USE=doc
Comment 142 Christopher Sean Morrison 2009-08-30 22:54:35 UTC
For USE=docs, the minimal dependency is xsltproc.  That will build and install the html documentation.  To also generate that same documentation in pdf format, it will need Apache FOP.

We're about to push out a 7.16.0 release for the end of August (i.e., today).
Comment 143 dongxu li 2009-11-02 18:34:05 UTC
Created attachment 209074 [details]
brlcad-7.16.0.ebuild

only tested on x86_64.
Comment 144 Luis Ferreira 2009-11-17 23:59:22 UTC
http://bugs.sabayonlinux.org/show_bug.cgi?id=996
Comment 145 Facundo de Guzmán 2009-11-29 23:01:31 UTC
brlcad-7.16.0.ebuild works for me.

Also tested in x86_64

Good job!
Comment 146 dongxu li 2009-12-07 19:35:15 UTC
Created attachment 212388 [details]
brlcad-7.16.2.ebuild

brlcad-7.16.2.ebuild
Comment 147 dongxu li 2009-12-07 19:35:58 UTC
Created attachment 212390 [details, diff]
cut-7.16.2.patch
Comment 148 dongxu li 2009-12-07 19:36:28 UTC
Created attachment 212391 [details, diff]
cmd-7.16.2.patch
Comment 149 dongxu li 2009-12-07 19:37:22 UTC
Created attachment 212392 [details, diff]
xsltproc-7.16.2.patch
Comment 150 Christopher Sean Morrison 2009-12-07 21:22:36 UTC
Thanks for the patches, dongxu_li!  Your changes, with the exception of the xsltproc patch, have all been committed to the repository and will be part of the upcoming 7.16.4 release (due to be posted this week).

A change was made to our configure.ac template that should affect the xsltproc patch, but you shouldn't be setting the XSLTPROC variable directly in the Makefile.am as it's an AC_SUBST variable set by configure.  My suspicion is that the variable was empty, causing a build failure, which shouldn't happen after my recent change.  Why it failed to detect xsltproc for you should be described in your config.log file (and would be useful to know).

Cheers!
Sean
 
Comment 151 dongxu li 2009-12-08 05:03:49 UTC
Created attachment 212436 [details]
config.log with empty XSLTPROC

the problem seems be to from --disable-documentation.

with --disable-documentation, XSLTPROC is not set, but doc/dockbook still being built. need to check why doc/docbook is still being used with --disable-documentation
Comment 152 Christopher Sean Morrison 2009-12-08 05:30:26 UTC
Ah, yeah, that would explain things.  The configure.ac template had some lame logic that made it skip searching for xsltproc if you disabled documentation.  It shouldn't have been traversing into doc/docbook if docs are disabled regardless, but the patch I applied will take care of that issue indirectly by at least making sure XSLTPROC is ":".  Now even if documentation is disabled, it shouldn't fail even if the build (or builder) does get into the doc/docbook directory.

Chers!
Sean
Comment 153 M. B. 2010-01-12 12:24:27 UTC
Created attachment 216212 [details]
small logic fix that only affects x86_32

the ebuild from dongxu li contains a small logic error that makes the build to attempt to build as x86_64 on 32-bit systems. this ebuild fixes that and makes it build nicely on my old laptop.

regards,
m.b.

# diff -Naur brlcad-7.16.2.ebuild brlcad-7.16.2-r1.ebuild 
--- brlcad-7.16.2.ebuild	2010-01-12 12:01:56.012227809 +0100
+++ brlcad-7.16.2-r1.ebuild	2010-01-12 12:52:55.357227915 +0100
@@ -64,7 +64,7 @@
         $(use_enable debug warnings) \
         $(use_enable debug progress) \
 		"
-	use amd64 || myconf="${myconf} --enable-64bit"
+	use amd64 && myconf="${myconf} --enable-64bit"
 	use debug || myconf="${myconf} --enable-optimized"
 	./configure $myconf || die "configure failed"
 	emake || die "emake failed"
Comment 154 dongxu li 2010-01-19 04:17:59 UTC
Great work!

I noticed that the old ebuild fails on x86_32, but didn't try to troubleshoot.

(In reply to comment #153)
> Created an attachment (id=216212) [details]
> small logic fix that only affects x86_32
> 
> the ebuild from dongxu li contains a small logic error that makes the build to
> attempt to build as x86_64 on 32-bit systems. this ebuild fixes that and makes
> it build nicely on my old laptop.
> 
> regards,
> m.b.
> 
> # diff -Naur brlcad-7.16.2.ebuild brlcad-7.16.2-r1.ebuild 
> --- brlcad-7.16.2.ebuild        2010-01-12 12:01:56.012227809 +0100
> +++ brlcad-7.16.2-r1.ebuild     2010-01-12 12:52:55.357227915 +0100
> @@ -64,7 +64,7 @@
>          $(use_enable debug warnings) \
>          $(use_enable debug progress) \
>                 "
> -       use amd64 || myconf="${myconf} --enable-64bit"
> +       use amd64 && myconf="${myconf} --enable-64bit"
>         use debug || myconf="${myconf} --enable-optimized"
>         ./configure $myconf || die "configure failed"
>         emake || die "emake failed"
> 

Comment 155 dongxu li 2010-01-25 01:43:19 UTC
Created attachment 217342 [details]
brlcad-7.16.4.ebuild

version bump to 7.16.4

CFLAGS="-Werror" breaks upon src/libbu/bomb.c

Have to be filtered out currently.
Comment 156 Christopher Sean Morrison 2010-01-25 03:34:09 UTC
You don't have to filter it out.  If you add the --disable-strict configure flag, it will remove -Werror from the build.
Comment 157 dongxu li 2010-01-25 17:12:35 UTC
(In reply to comment #156)
> You don't have to filter it out.  If you add the --disable-strict configure
> flag, it will remove -Werror from the build.
> 

I think the source code should be fixed to allow -Werror.

thanks!
Comment 158 Christopher Sean Morrison 2010-01-25 19:50:38 UTC
Even better, patches welcome!

One noteworthy point, though, is that the flag being enabled is not technically just -Werror.  That is of course a good flag to enable by itself, but we go above and beyond by asking the compiler to report nearly everything it's capable of reporting.  That results in a LOT of platform variability, compiler version variability, and *many* false positives, so package distribution systems like portage *should* disable the behavior.

We've been moving towards what we call "strict" compilation of all our core libraries where nearly all warnings are enabled (not just -Wall, but even many optional ones that default off), so we can of course address them all (even the false positives).  That's not a burden intended for the general public, even if we made it default behavior.  That was done for other (selfish) reasons.
Comment 159 Sébastien Fabbro (RETIRED) gentoo-dev 2010-02-02 21:14:54 UTC
Hi folks,

I rewrote the ebuild from scratch and bumped to 7.16.4 it in the science overlay with an as-needed patch, and now almost uses exclusively system libraries.

Let me ask again: who is interested in maintaining it either in the science overlay or as a proxy maintainer? I won't.

Comment 160 M. B. 2010-02-04 18:12:59 UTC
Uhm ... 7.16.4 from the science overlay fails with extremely weird file collisions for me:

 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * sys-apps/coreutils-7.5-r1
 * 	/usr/share/man/man1/cat.1.bz2
 * 	/usr/share/man/man1/cp.1.bz2
 * 
 * sys-apps/man-1.6f-r3
 * 	/usr/share/man/man1/apropos.1.bz2
 * 
 * sys-apps/attr-2.4.43
 * 	/usr/share/man/man1/attr.1.bz2
 * 
 * Package 'sci-misc/brlcad-7.16.4' NOT merged due to file collisions. If
 * necessary, refer to your elog messages for the whole content of the
 * above message.

Why would brlcad want to replace those man-pages?
Comment 161 M. B. 2010-02-04 18:14:26 UTC
i forgot:

# emerge --info
Portage 2.2_rc62 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 i686)
=================================================================
System uname: Linux-2.6.31-gentoo-r6-i686-Genuine_Intel-R-_CPU_T2300_@_1.66GHz-with-gentoo-2.0.1
Timestamp of tree: Wed, 03 Feb 2010 22:45:01 +0000
distcc 3.1 i686-pc-linux-gnu [enabled]
ccache version 2.4 [enabled]
app-shells/bash:     4.0_p35
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.4
dev-python/pycrypto: 2.1.0_beta1
dev-util/ccache:     2.4-r7
dev-util/cmake:      2.6.4-r3
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc:       4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -m32"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -m32"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs=6 --load-average=3"
FEATURES="assume-digests ccache distcc distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch webrsync-gpg"
GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://gentoo.mneisen.org/ http://gentoo.supp.name/"
LANG="de"
LDFLAGS="-Wl,-O1"
LINGUAS="de en sv fr ru"
MAKEOPTS="-j5 --load-average=3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--delete-after"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/science /usr/portage/local/layman/java-overlay /usr/portage/local/layman/x11 /usr/portage/local/layman/sunrise /usr/portage/local/mine"
SYNC="rsync://10.2.3.4/gentoo-portage"
USE="X a52 aac aalib accessibility acl acpi alsa amr aotuv archive bash-completion berkdb blksha1 boost branding bzip2 cairo cdda cddax cdr cleartype cli cracklib crypt css cups cxx dbus device-mapper dga dia disk-partition doc dri dvd dvdr enca encode exif fam fat ffmpeg flac foomaticdb fortran frei0r ftp fuse gd gdbm geoip gif gimp git glitz gnome gphoto2 gpm gre gs gstreamer gtk hal hddtemp hpn iconv id3tag idn inkjar iostats ipv6 jabber java java6 javascript jpeg jpeg2k kpathsea ladspa laptop latex libass libcaca libnotify libv4l2 live lm_sensors lock lzma lzo mad matroska mime mjpeg mmap mmx mmxext mng modules mp2 mp3 mp4 mpeg mplayer mudflap music ncurses network nls nodrm nptl nptlonly nsplugin ntfs ntp octave offensive ogg opengl openmp pam pcre pdf perl png postscript ppds pppd python qt4 quicktime rar readline reflection reiser4 reiserfs rss rtc samba schroedinger sdl session skins smp sound speex spl sse sse2 ssl startup-notification stk subtitles subversion svg symlink sysfs tcpd templates theora threads thunar tidy tiff trayicon truetype twolame unicode upnp usb v4l2 vcd video videos vim-syntax vim-with-x vorbis vst weather-metar weather-xoap webkit wifi wma wps wxwidgets x264 x86 xanim xcb xcomposite xfce xhtml xinerama xml xorg xosd xpm xscreensaver xv xvid xvmc zip zlib" ALSA_CARDS="hdmi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en sv fr ru" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" 
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Comment 162 dongxu li 2010-02-05 13:11:44 UTC
it should not happen, because everything is installed under /usr/brlcad/, with the except of /etc/env.d/

I have no idea how your ebuild generated the collision. It's impossible to me.Try to clean up /var/tmp/portage (it's auto, anyway), and

emerge -va brlcad

(In reply to comment #160)
> Uhm ... 7.16.4 from the science overlay fails with extremely weird file
> collisions for me:
> 
>  * Searching all installed packages for file collisions...
>  * 
>  * Press Ctrl-C to Stop
>  * 
>  * sys-apps/coreutils-7.5-r1
>  *      /usr/share/man/man1/cat.1.bz2
>  *      /usr/share/man/man1/cp.1.bz2
>  * 
>  * sys-apps/man-1.6f-r3
>  *      /usr/share/man/man1/apropos.1.bz2
>  * 
>  * sys-apps/attr-2.4.43
>  *      /usr/share/man/man1/attr.1.bz2
>  * 
>  * Package 'sci-misc/brlcad-7.16.4' NOT merged due to file collisions. If
>  * necessary, refer to your elog messages for the whole content of the
>  * above message.
> 
> Why would brlcad want to replace those man-pages?
> 

Comment 163 M. B. 2010-02-08 22:04:31 UTC
Hmm.

Maybe you checked your own ebuild? The ebuild that ended up in the science overlay was rewritten. Severely.
Comment 164 Christopher Sean Morrison 2010-02-12 21:05:10 UTC
If BRL-CAD is installed isolated into /usr/brlcad, then those man page collisions should not occur.  If the install is being tested against a different prefix that includes system directories, then 7.16.4 will have a few potential collisions.

BRL-CAD includes an extensive command subsystem and geometry editing shell where there are many commands that mirror system commands but apply to geometry.  (e.g., the "cp" command makes copies of geometry objects)  We've been in the process of converting our existing documentation for them lately which has resulted in hundreds of new manual pages.  These collisions are new with 7.16.4 as the (400+) pages were put into man section 1 (as they are "user commands", just not unix shell commands).

We're going to move the manual pages to a different section, probably section n with subsection nged to mirror what the Tcl/Tk folks have done; or we'll consider starting a new section since we'll potentially have so many by the time we're done (700+).

For release 7.16.6 (just tagged a few days ago, uploading today), the conflicting pages reported here were moved into section 'n'.
Comment 165 Bob Paddock 2010-02-13 02:28:11 UTC
(In reply to comment #159)
> and now almost uses exclusively system

Anyway to find out which ones need to be installed, as they are not being pulled in by emerge?  So far I'm on my fourth emerge/missing library iteration.

urt, itcl, iwidgets, tnt...
Comment 166 Sébastien Fabbro (RETIRED) gentoo-dev 2010-02-17 04:56:25 UTC
I will put in blrcad 7.16.6 in portage in a few days based on the 7.16.4 which is now in the overlay. So if you want to report failures or submit patches, please do it now.


(In reply to comment #165)
> 
> Anyway to find out which ones need to be installed, as they are not being
> pulled in by emerge?  So far I'm on my fourth emerge/missing library iteration.
> 
> urt, itcl, iwidgets, tnt...
> 

I don't understand, emerge brlcad should pull out all the required deps.
Comment 167 dongxu li 2010-02-18 07:46:02 UTC
7.16.6 doesn't build for me,

1, still need to filter out -Werror from configure.ac
2, have to patch src/libged/edcodes.c for function,
--- a/src/libged/edcodes.c	2010-02-18 01:30:16.740024851 -0500
+++ b/src/libged/edcodes.c	2010-02-18 01:30:40.513356471 -0500
@@ -36,6 +36,8 @@
 #define EDCODES_OK GED_OK
 #define EDCODES_NOTOK GED_ERROR
 #define EDCODES_HALT -99
+HIDDEN int
+edcodes_collect_regnames(struct ged *, struct directory *, int );
 
 
 
@@ -70,7 +72,6 @@
     int *pathpos;
     struct directory *nextdp;
     struct ged *gedp;
-    HIDDEN int edcodes_collect_regnames(struct ged *, struct directory *, int);
 
     RT_CK_DBI(dbip);
     RT_CK_TREE(comb_leaf);


(In reply to comment #164)
> If BRL-CAD is installed isolated into /usr/brlcad, then those man page
> collisions should not occur.  If the install is being tested against a
> different prefix that includes system directories, then 7.16.4 will have a few
> potential collisions.
> 
> BRL-CAD includes an extensive command subsystem and geometry editing shell
> where there are many commands that mirror system commands but apply to
> geometry.  (e.g., the "cp" command makes copies of geometry objects)  We've
> been in the process of converting our existing documentation for them lately
> which has resulted in hundreds of new manual pages.  These collisions are new
> with 7.16.4 as the (400+) pages were put into man section 1 (as they are "user
> commands", just not unix shell commands).
> 
> We're going to move the manual pages to a different section, probably section n
> with subsection nged to mirror what the Tcl/Tk folks have done; or we'll
> consider starting a new section since we'll potentially have so many by the
> time we're done (700+).
> 
> For release 7.16.6 (just tagged a few days ago, uploading today), the
> conflicting pages reported here were moved into section 'n'.
> 

Comment 168 Christopher Sean Morrison 2010-02-18 08:19:31 UTC
Apparently my first response was missed.  You should NOT filter out -Werror from configure.ac.  You need to supply the --disable-strict debug option.  This is intentional behavior and should always be specified when building as part of a package management system such as portage.

The issue with edcodes.c was discovered shortly after release and will be fixed in 7.16.8 next month.  A patch is not necessary for default builds, it's only needed for builds that specify --disable-debug to configure.  While the patch is good "for now" (until .8), the default should ideally be a debuggable build.
Comment 169 Bob Paddock 2010-02-20 13:15:52 UTC
Created attachment 220455 [details]
emerge info sci_misc brlcad build failure
Comment 170 Bob Paddock 2010-02-20 13:16:48 UTC
Created attachment 220457 [details]
emerge pqv brlcad7164 build failure
Comment 171 Bob Paddock 2010-02-20 13:30:21 UTC
Created attachment 220461 [details]
brlcad7164 build log

I'm not getting 7.16.4 to build.  Suggestions?

make[5]: Entering directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step/data'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step/data'
make[4]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step/data'
make[4]: Entering directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step'
make[3]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/step'
Making all in openNURBS
make[3]: Entering directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/openNURBS'
/bin/sh ../../../libtool --silent --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../include   -DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS  -Wall  -march=athlon64 -O2 -pipe -pipe -fno-strict-aliasing -fno-common -fexceptions -c -o libopenNURBS_nil_la-opennurbs_3dm_attributes.lo `test -f 'opennurbs_3dm_attributes.cpp' || echo './'`opennurbs_3dm_attributes.cpp
/bin/sh ../../../libtool --silent --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../include   -DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS  -Wall  -march=athlon64 -O2 -pipe -pipe -fno-strict-aliasing -fno-common -fexceptions -c -o libopenNURBS_nil_la-opennurbs_3dm_properties.lo `test -f 'opennurbs_3dm_properties.cpp' || echo './'`opennurbs_3dm_properties.cpp
/bin/sh ../../../libtool --silent --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../include   -DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS  -Wall  -march=athlon64 -O2 -pipe -pipe -fno-strict-aliasing -fno-common -fexceptions -c -o libopenNURBS_nil_la-opennurbs_3dm_settings.lo `test -f 'opennurbs_3dm_settings.cpp' || echo './'`opennurbs_3dm_settings.cpp
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/new:45,
                 from opennurbs_system.h:248,
                 from opennurbs.h:29,
                 from opennurbs_3dm_attributes.cpp:17:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/cstddef:56: error: '::ptrdiff_t' has not been declared
make[3]: *** [libopenNURBS_nil_la-opennurbs_3dm_attributes.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/new:45,
                 from opennurbs_system.h:248,
                 from opennurbs.h:29,
                 from opennurbs_3dm_properties.cpp:17:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/cstddef:56: error: '::ptrdiff_t' has not been declared
make[3]: *** [libopenNURBS_nil_la-opennurbs_3dm_properties.lo] Error 1
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/new:45,
                 from opennurbs_system.h:248,
                 from opennurbs.h:29,
                 from opennurbs_3dm_settings.cpp:17:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/cstddef:56: error: '::ptrdiff_t' has not been declared
make[3]: *** [libopenNURBS_nil_la-opennurbs_3dm_settings.lo] Error 1
make[3]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other/openNURBS'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src/other'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4/src'
make: *** [all-recursive] Error 1
 * ERROR: sci-misc/brlcad-7.16.4 failed:
 *   emake failed
 * 
 * Call stack:
 *     ebuild.sh, line   48:  Called src_compile
 *   environment, line 4099:  Called _eapi2_src_compile
 *     ebuild.sh, line  640:  Called die
 * The specific snippet of code:
 *   		emake || die "emake failed"
 * 
 * If you need support, post the output of 'emerge --info =sci-misc/brlcad-7.16.4',
 * the complete build log and the output of 'emerge -pqv =sci-misc/brlcad-7.16.4'.
 * This ebuild is from an overlay named 'science': '/var/lib/layman/science/'
!!! When you file a bug report, please include the following information:
GENTOO_VM=  CLASSPATH="" JAVA_HOME="/home/bob/.gentoo/java-config-2/current-user-vm"
JAVACFLAGS="" COMPILER=""
and of course, the output of emerge --info
 * The complete build log is located at '/var/log/portage/sci-misc:brlcad-7.16.4:20100220-125555.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sci-misc/brlcad-7.16.4/temp/environment'.
 * S: '/var/tmp/portage/sci-misc/brlcad-7.16.4/work/brlcad-7.16.4'

>>> Failed to emerge sci-misc/brlcad-7.16.4, Log file:

>>>  '/var/log/portage/sci-misc:brlcad-7.16.4:20100220-125555.log'
Comment 172 Christopher Sean Morrison 2010-02-20 17:29:45 UTC
That compilation failure was investigated a couple weeks ago after reports of new compilation failures on Ubuntu.  It seems to be a bug in the STL headers from recent versions of GCC (older 4.3 versions and 4.4.* iirc).

A related issue was reported by Ubuntu folks (Ubuntu Bug #355408), and a patch was applied to GCC (see GCC Bugzilla Bug 38000), but their fix was apparently incomplete.

A workaround can be applied (and is applied to our trunk sources), but the bug needs to be reported by someone(tm) to upstream.

Manually including <stddef.h> in src/other/openNURBS/opennurbs_system.h before including <new> is the workaround fix.
Comment 173 Bob Paddock 2010-02-21 14:25:20 UTC
> Manually including <stddef.h> in src/other/openNURBS/opennurbs_system.h before
> including <new> is the workaround fix.

That worked for me.  Thank you.
Comment 174 Sébastien Fabbro (RETIRED) gentoo-dev 2010-02-25 06:19:02 UTC
Now in main tree, please file new bugs if you have issue.

Christopher, feel free to take the as-needed patch I introduced.
Thanks all for your patience and help.
Comment 175 Christopher Sean Morrison 2010-02-25 16:04:45 UTC
Sébastien,

Likewise, thank you for your efforts on the ebuild and getting BRL-CAD added to the main tree.  That thanks also extends to everyone that has helped BRL-CAD get set up on Gentoo over the past five years.  I'll be making a public announcement on our news channels crediting everyone here for their efforts.

As for the as-needed patch, that issue is already obsolete with a refactoring removal of that particular noinst library in our trunk sources.

I'll keep an eye out for and solicit an ebuild maintainer to take over maintenance and updates.  If anyone here is interested, please contact me (via IRC, brlcad on freenode).  Thanks again everyone!

Cheers!
Sean

5 years...
    
Comment 176 Luis Ferreira 2010-02-27 18:08:13 UTC
 i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -DPREFIX=\"/usr/brlcad\" -DBRLCADBUILD=1 -I../../include -I../../src/other/openNURBS -pedantic -W -Wall -Werror -Wno-long-long -march=pentium2 -O2 -pipe -fomit-frame-pointer -pipe -fno-strict-aliasing -fno-common -fexceptions -g3 -gstabs+ -O3 -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -c brlcad_path.c -o brlcad_path.o >/dev/null 2>&1
make[2]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.6/work/brlcad-7.16.6/src/libbu'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/sci-misc/brlcad-7.16.6/work/brlcad-7.16.6/src'
make: *** [all-recursive] Error 1
 * ERROR: sci-misc/brlcad-7.16.6 failed:
 *   emake failed
 *
 * Call stack:
 *     ebuild.sh, line   54:  Called src_compile
 *   environment, line 4101:  Called _eapi2_src_compile
 *     ebuild.sh, line  646:  Called die
 * The specific snippet of code:
 *              emake || die "emake failed"
 *
 * If you need support, post the output of 'emerge --info =sci-misc/brlcad-7.16.6',
 * the complete build log and the output of 'emerge -pqv =sci-misc/brlcad-7.16.6'.
!!! When you file a bug report, please include the following information:
GENTOO_VM=icedtea6-bin  CLASSPATH="" JAVA_HOME="/opt/icedtea6-bin-1.6.2"
JAVACFLAGS="-source 1.5 -target 1.5" COMPILER=""
and of course, the output of emerge --info
 * The complete build log is located at '/var/lib/entropy/logs/sci-misc:brlcad-7.16.6:20100227-140150.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sci-misc/brlcad-7.16.6/temp/environment'.
 * S: '/var/tmp/portage/sci-misc/brlcad-7.16.6/work/brlcad-7.16.6'



***************

Sly luis # emerge --info
Portage 2.1.7.16 (default/linux/x86/10.0/desktop, gcc-4.4.1, glibc-2.10.1-r1, 2.6.31-sabayon i686)
=================================================================                                 
System uname: Linux-2.6.31-sabayon-i686-Pentium_II_-Deschutes-with-gentoo-2.0.1                   
Timestamp of tree: Sat, 27 Feb 2010 14:45:03 +0000                                                
distcc 3.1 i686-pc-linux-gnu [disabled]                                                           
ccache version 2.4 [enabled]                                                                      
app-shells/bash:     4.0_p35                                                                      
dev-java/java-config: 1.3.7-r1, 2.1.10                                                            
dev-lang/python:     2.6.4-r1                                                                     
dev-util/ccache:     2.4-r7                                                                       
dev-util/cmake:      2.8.0                                                                        
sys-apps/baselayout: 2.0.1                                                                        
sys-apps/openrc:     0.4.3-r5
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11.1
sys-devel/binutils:  2.20
sys-devel/gcc:       4.4.1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /etc/entropy /usr/share/X11/xkb /usr/share/config /usr/share/config/kdm /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/skel /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=pentium2 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://cesium.di.uminho.pt/pub/gentoo  ftp://ftp.di.fc.ul.pt/pub/linux/gentoo/  http://cesium.di.uminho.pt/pub/gentoo http://ftp.dei.uc.pt/pub/linux/gentoo/ ftp://gentoo.imj.fr/pub/gentoo/ http://130.59.10.35/ftp/mirror/gentoo/"
LANG="pt_PT.UTF-8"
LC_ALL="pt_PT.UTF-8"
LDFLAGS="-Wl,-O1,--as-needed"
LINGUAS="pt en pt_PT"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/layman/science"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="7Zip X a52 aac aalib accessibility acl acpi aiglx aim alsa artswrappersuid audiofile autotrace avahi bash-completion berkdb bidi bluetooth bzip2 cairo cdda cddb cdr chm cjk cli config_wizard consolekit cpudetection cracklib crypt css cups cxx dbox2 dbus dga djvu dri dts dv dvb dvd dvdr dvdread dxr3 ebook emboss emf encode exif extramodules fam fame fat ffmpeg fftw firefox flac flash foomatic-db fortran freetype gcj gdbm geolocation gif gimpprint gmp gnutls gpg gphoto2 gpm graphviz gs gsm gstreamer gtk hal hfs iconv icq ieee1394 imagemagick imap inkjar inotify ipod ipv6 irc irda jabber jack java jbig jfs jingle joystick jpeg jpeg2k kde kdehiddenvisibility kerberos kipi lame lapack latex lcd lcms ldap lensfun libnotify live lj lm_sensors logitech-mouse lzo mad mail matroska mikmod mjpeg mmx mng modules mozdevelop mp3 mp3rtp mp4 mpeg msn mudflap musepack musicbrainz ncurses network new-login nls nntp nptl nptlonly nsplugin ntfs ogg openal openexr opengl openmp pam pcmcia pcre pda pdf perl plotutils png policykit pop postscript povray ppds pppd pulseaudio python qt3support qt4 quicktime quotas rar rdesktop readline reflection reiserfs rss scanner sdl semantic-desktop session slp smime sms smtp speex spell spl ssl startup-notification stream svg sysfs taglib tcpd theora thumbnail thunar tiff tk tracker truetype udev unicode usb v4l v4l2 visualization voice vorbis weather wifi win32codecs wmf x264 x86 xcb xfs xine xinerama xml xmp xorg xpm xprint xulrunner xv xvid xvmc yahoo yaz zeroconf zlib" ALSA_CARDS="emu10k1x darla20 darla24 emu10k1 gina20 gina24 hdsp hdspm ice1712 indigo indigoio layla20 layla24 mia mixart mona pcxhr rme32 rme96 sb16 sbawe sscape usbusx2y vx222 usb-usx2y" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" CAMERAS="agfa_cl20 casio_qv dimagev dimera3500 kodak_dc120 kodak_dc210 kodak_dc240 kodak_dc3200 kodak_ez200 konica_qm150 panasonic_coolshot panasonic_dc1000 panasonic_dc1580 panasonic_l859 polaroid_pdc320 polaroid_pdc640 polaroid_pdc700 ricoh_g3 sipix_blink sipix_blink2 sipix_web2 sony_dscf1 sony_dscf55 toshiba_pdrm11 adc65 aox barbie canon clicksmart310 digigr8 digita directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 konica largan lg_gsm mars mustek pccam300 pccam600 ptp2 ricoh samsung sierra smal sonix soundvision spca50x sq905 stv0674 stv0680 sx330z template" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse void wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pt en pt_PT" LIRC_DEVICES="audio audio_alsa serial" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev vesa radeonhd nvidia"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS



Comment 177 Luis Ferreira 2010-02-27 18:18:55 UTC
Created attachment 221455 [details]
sci-misc:brlcad-7.16.6:20100227-140150.log
Comment 178 Christopher Sean Morrison 2010-03-01 03:52:23 UTC
Looking at the ebuild, it looks like --enable-strict-build was tied to the debug use flag.  It should not be optional.  As mentioned earlier, it should always be disabled.

If there's a way to set make flags during a build, "make STRICT_FLAGS=" will turn the strict flags off in leu of the configure flags.

Unfortunately, you can't just disable debug per bug 306841 without a patch to the 7.16.6 sources.