This is a brl-cad ebuild which is close to working, but encounters some sandbox violation during the make install portion. Help appreciated
Created attachment 48000 [details] Ebuild for brl-cad 7.0.2 This one has sandbox problems
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.
Things to fix: * KEYWORDS needs to be set as per policy * Fix IUSE * Don't hardcode version numbers * No econf?
> 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.
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.
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.
man 5 versionator.eclass (part of portage-manpages). Worth doing, it saves all kinds of pain when doing version bumps.
Created attachment 48159 [details] Updated ebuild
Created attachment 48160 [details, diff] Patch for Makefile.am errors (this isn't all of them, apparently)
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.
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?
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 :-).
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.
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.
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)
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
Created attachment 59335 [details] brlcad-7.2.4-gentoo.diff needed for brlcad-7.2.4.ebuild ugly ugly ugly
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.
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.
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 ).
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" }
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?
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?
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.
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.
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).
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
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? :]
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).
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?
Binary sourceforge tarball brlcad-7.4.0_linux_ia32.tar.bz2 installs to /usr/brlcad, not only gentoo screws FHS :]
(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.
(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.
Created attachment 67659 [details, diff] brlcad-7.4.2-gentoo.diff configure.ac fixes: * --datadir fix * tk detection fix * iwidgets detection fix
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...
(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.
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. :-(
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.
Created attachment 67737 [details] CONTESTS of brlcad image genereted by brlcad-7.4.2.ebuild No collisions with any gentoo package on my system.
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.
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.
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?
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/
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.
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?
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.
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 .
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.
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.
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.
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
Created attachment 78208 [details] sci-misc/brlcad-7.6.6.ebuild
Comment on attachment 78208 [details] sci-misc/brlcad-7.6.6.ebuild New ebuild for 7.6.6
Created attachment 78209 [details, diff] brlcad-7.6.6-gentoo.diff New patch for configure.ac
Created attachment 78210 [details] tcl.m4 This m4 file is used by the patched configure.ac. It should be copied to files/
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!
Created attachment 82390 [details] brlcad-7.6.6-r1.ebuild
Created attachment 82391 [details] config.log for failed build
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?
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
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!
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...
now, 7.10.0 is out let's work out an ebuild for it, also, an ebuild for -cvs
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.
(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
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
Created attachment 118511 [details] updated 7.10.0 ebuild build brlcad-7.10.0 with system regexp, libz, and libpng (if available)
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
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
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.
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
> 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
(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
> 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
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
Created attachment 131083 [details] Updated BRL-CAD ebuild This version installs to /opt/brlcad, including the env.d settings needed.
Created attachment 131085 [details, diff] tcl patch Patch for tcl makefile per earlier 7.10.0 patch
Created attachment 131087 [details, diff] tk patch tk Makefile patch
Created attachment 131089 [details] env.d file for /opt/brlcad paths Installed by ebuild in /etc/env.d
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
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
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 :-)
(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
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.
Created attachment 131177 [details, diff] patch for tcl/tk makefiles Used proper ebuild patch-building procedure, one file now.
Created attachment 131178 [details] brlcad-7.10.2.ebuild (patches correct files now) Correct patch options, cut profile flag for now.
Created attachment 131180 [details] Convenient bundle of brl-cad files (except BDL license) [updated] Update of earlier tarball.
Created attachment 131182 [details] Convenient bundle of brl-cad files (except BDL license) [updated] Oops (obsolete older tarball(s) to avoid confusion)
Created attachment 131183 [details] brlcad-7.10.2-ebuild tarball Sigh. And put in correct file type (sorry for the spam)
(In reply to comment #89) > Created an attachment (id=131183) [edit] > brlcad-7.10.2-ebuild tarball wtf is this?
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?
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.
Created attachment 134457 [details] Version update to latest, remove unneeded line
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.
Good catch - it is indeed mged. Not sure about AMD64 - that's not a platform I have available to test on :-(.
Created attachment 134602 [details] 7.10.4 - Fix the info message to actually specify the mged binary
(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.
(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
Created attachment 134848 [details] configuration log for build on AMD64 configuration log for build on AMD64.
Created attachment 134849 [details] emerge --info for build on AMD64 emerge --info for build on AMD64
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.
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
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.
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...
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...
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.
/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?
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...)
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!
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.
> 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.
(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.
(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?
Created attachment 139280 [details] brlcad-cvs ebuild tcl/tk doc-Makefile patch not needed any more
Created attachment 139282 [details, diff] no need to check for /usr/local a trivial patch file to be used by brlcad-cvs ebuild
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
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
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
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
Created attachment 152375 [details] brlcad-7.12.2.ebuild version updated, no changes to the ebuild
i'm really interested in this package, can anyone maintain it anywhere? (sunrise? maybe even portage?)
argh, i'm sorry guys, i *really* read the comments, but i obviously missed "science overlay" about a million times. sry.
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.
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
Is this ready to go to maintainer-wanted and sunrise?
(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.
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
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.
Created attachment 183556 [details] brlcad-7.12.6.ebuild ebuild for 7.12.6 needs the usr-local.patch
(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
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.)
(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
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
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.
Created attachment 192428 [details] brlcad-7.14.8.ebuild updated env.d, no need to set LDPATH etc.
7.18.4 is out by now .. is anyone going to add it to the science overlay? - would be nice ;)
sorry meant 7.14.8
put 7.14.8 in my overlay for now ..
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"
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
Created attachment 193188 [details] brlcad-7.14.8.ebuild updated configure options, I still don't know what DEPENDs for USE=doc
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).
Created attachment 209074 [details] brlcad-7.16.0.ebuild only tested on x86_64.
http://bugs.sabayonlinux.org/show_bug.cgi?id=996
brlcad-7.16.0.ebuild works for me. Also tested in x86_64 Good job!
Created attachment 212388 [details] brlcad-7.16.2.ebuild brlcad-7.16.2.ebuild
Created attachment 212390 [details, diff] cut-7.16.2.patch
Created attachment 212391 [details, diff] cmd-7.16.2.patch
Created attachment 212392 [details, diff] xsltproc-7.16.2.patch
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
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
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
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"
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" >
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.
You don't have to filter it out. If you add the --disable-strict configure flag, it will remove -Werror from the build.
(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!
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.
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.
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?
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
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? >
Hmm. Maybe you checked your own ebuild? The ebuild that ended up in the science overlay was rewritten. Severely.
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'.
(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...
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.
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'. >
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.
Created attachment 220455 [details] emerge info sci_misc brlcad build failure
Created attachment 220457 [details] emerge pqv brlcad7164 build failure
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'
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.
> Manually including <stddef.h> in src/other/openNURBS/opennurbs_system.h before > including <new> is the workaround fix. That worked for me. Thank you.
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.
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...
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
Created attachment 221455 [details] sci-misc:brlcad-7.16.6:20100227-140150.log
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.