From tone.kokalj at ijs.si Tue Sep 2 17:07:36 2014 From: tone.kokalj at ijs.si (Tone Kokalj) Date: Tue, 02 Sep 2014 17:07:36 +0200 Subject: [xcrysden] Xcrysden / Macosx 10.9 In-Reply-To: <2EDBE5E743C8C1489A8F7B58124127105F276CDF@ee-mbx2.ee.emp-eaw.ch> References: <2EDBE5E743C8C1489A8F7B58124127105F276CDF@ee-mbx2.ee.emp-eaw.ch> Message-ID: <1409670456.6716.37.camel@catalyst.ijs.si> On Tue, 2014-08-26 at 21:20 +0000, Passerone, Daniele wrote: > > Dear developers, > As far as I know, the problem by executing a successfully compiled > xcrysden on Mavericks is still not solved. > The solution of installing mesa 7.0.3 is not so easy, and the port > proposed here: > > https://trac.macports.org/ticket/41320 > > > has not been approved by macports, being 7.0 of mesa too obsolete. Note that the old 7.x version of Mesa is not mandatory and xcrysden can be also compiled/linked against newer versions of Mesa! However, for macosx there have been reports that xcrysden does not work with some 8.x versions of Mesa; I do not know whether it works or not with the newer 9.x and 10.x versions of Mesa. The reason that xcrysden tries automatically to download and compile Mesa-7.0.3 (if instructed to do so) is that according to my experience the older 7.x version compiles much easier than the newer versions and it has less dependencies (e.g, on dri, drm, x11proto, llvm, etc...). I've just tried to compile xcrysden on x86_64-linux with the new Mesa-10.2.6 and it works (note that starting from Mesa-9.x the GLU library is separated from Mesa and should be installed and compiled separately). Regards, -- Anton Kokalj J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia (tel: +386-1-477-3523 // fax:+386-1-477-3822) Please, if possible, avoid sending me Word or PowerPoint attachments. See: http://www.gnu.org/philosophy/no-word-attachments.html From Daniele.Passerone at empa.ch Tue Sep 2 22:10:48 2014 From: Daniele.Passerone at empa.ch (Passerone, Daniele) Date: Tue, 2 Sep 2014 20:10:48 +0000 Subject: [xcrysden] Xcrysden / Macosx 10.9 In-Reply-To: <1409670456.6716.37.camel@catalyst.ijs.si> References: <2EDBE5E743C8C1489A8F7B58124127105F276CDF@ee-mbx2.ee.emp-eaw.ch> <1409670456.6716.37.camel@catalyst.ijs.si> Message-ID: Dear Tone, Thank you very much! However, I am very old ;-) and I left linux for mac exactly because my main activity and passion is not anymore digging libraries and dependencies? so I am more or less dependent on ?macports" So I was really sad when I discovered that macports stops at Mesa 8, and? *configured Mesa 10, and got "Direct rendering requires libdrm >= 2.4.38? *configured libdrm, and got ?no clock_gettime available? *then configured Mesa 9, and got "failed to find required module libxml2? *installed py27-libxml2 , no effect. As I said, I am old, and just want to check whether my beloved Diselenide model makes sense for my next DFT+U calculation? Best, Daniele On 02/09/14 17:07, "Tone Kokalj" wrote: >On Tue, 2014-08-26 at 21:20 +0000, Passerone, Daniele wrote: >> >> Dear developers, >> As far as I know, the problem by executing a successfully compiled >> xcrysden on Mavericks is still not solved. >> The solution of installing mesa 7.0.3 is not so easy, and the port >> proposed here: >> >> https://trac.macports.org/ticket/41320 >> >> >> has not been approved by macports, being 7.0 of mesa too obsolete. > >Note that the old 7.x version of Mesa is not mandatory and xcrysden can >be also compiled/linked against newer versions of Mesa! However, for >macosx there have been reports that xcrysden does not work with some 8.x >versions of Mesa; I do not know whether it works or not with the newer >9.x and 10.x versions of Mesa. > >The reason that xcrysden tries automatically to download and compile >Mesa-7.0.3 (if instructed to do so) is that according to my experience >the older 7.x version compiles much easier than the newer versions and >it has less dependencies (e.g, on dri, drm, x11proto, llvm, etc...). > >I've just tried to compile xcrysden on x86_64-linux with the new >Mesa-10.2.6 and it works (note that starting from Mesa-9.x the GLU >library is separated from Mesa and should be installed and compiled >separately). > >Regards, > >-- >Anton Kokalj >J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia >(tel: +386-1-477-3523 // fax:+386-1-477-3822) > >Please, if possible, avoid sending me Word or PowerPoint attachments. >See: http://www.gnu.org/philosophy/no-word-attachments.html > >_______________________________________________ >XCrySDen mailing list >XCrySDen at democritos.it >http://www.democritos.it/mailman/listinfo/xcrysden From ora at georgetown.edu Wed Sep 3 17:41:23 2014 From: ora at georgetown.edu (Oliver Albertini) Date: Wed, 03 Sep 2014 11:41:23 -0400 Subject: [xcrysden] Xcrysden on Maverics Message-ID: <1409758558-sup-9860@archie-pepper> Dear Daniele, If you don't mind using fink, I have a working version of xcrysden from fink. I had a working version of xcrysden on 10.9 sans-fink (thanks to David Strubbe), but it stopped working after an xquartz update. Since then I reinstalled the OS and haven't tried for it again. -- Sincerely, ORA From Daniele.Passerone at empa.ch Thu Sep 4 09:19:13 2014 From: Daniele.Passerone at empa.ch (Passerone, Daniele) Date: Thu, 4 Sep 2014 07:19:13 +0000 Subject: [xcrysden] Xcrysden on Maverics In-Reply-To: <1409758558-sup-9860@archie-pepper> References: <1409758558-sup-9860@archie-pepper> Message-ID: I would prefer not to mix fink and macports? Thank you, however. On 03/09/14 17:41, "Oliver Albertini" wrote: >Dear Daniele, > >If you don't mind using fink, I have a working version of xcrysden from >fink. >I had a working version of xcrysden on 10.9 sans-fink (thanks to David >Strubbe), but it stopped working after an xquartz update. Since then I >reinstalled the OS and haven't tried for it again. > >-- >Sincerely, > >ORA >_______________________________________________ >XCrySDen mailing list >XCrySDen at democritos.it >http://www.democritos.it/mailman/listinfo/xcrysden From mike.d.ft402 at gmail.com Thu Sep 18 09:18:13 2014 From: mike.d.ft402 at gmail.com (Michael) Date: Thu, 18 Sep 2014 13:18:13 +0600 Subject: [xcrysden] Segmentation fault on FreeBSD/amd64 Message-ID: <20140918071813.GA17054@strutter> Afternoon, I'm trying to compile and run XCrysDen on FreeBSD/amd64, with NVIDIA driver. It dies with SIGSEGV. GDB output: Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 100125] 0x000000080162cebc in glXCreateNewContext () from /usr/local/lib/libGL.so.1 (gdb) bt #0 0x000000080162cebc in glXCreateNewContext () from /usr/local/lib/libGL.so.1 #1 0x00000008006d1691 in r_debug_state () from /libexec/ld-elf.so.1 #2 0x00000008006d0d27 in __tls_get_addr () from /libexec/ld-elf.so.1 #3 0x00000008006cf089 in .text () from /libexec/ld-elf.so.1 #4 0x0000000000000000 in ?? () Make.sys: CC = gcc47 FC = gfortran47 CFLAGS= -g -ffast-math -funroll-loops -fPIC -DUSE_FONTS -pedantic -Wall CFLAGS+= -DUSE_INTERP_RESULT FFLAGS= -fdefault-double-8 -fdefault-real-8 -O2 MATH = -lm -lc X_LIB = -lXmu -lX11 TCL_LIB = -ltcl86 TK_LIB = -ltk86 GLU_LIB = -lGLU GL_LIB = -lGL FFTW3_LIB = -lfftw3 TCL_INCDIR = -I/usr/local/include/tcl8.6 TK_INCDIR = -I/usr/local/include/tk8.6 During compilation I notice abundance of those (may that be relevant?): xcBz.c: In function 'BzRenderBZ': xcBz.c:871:4: warning: passing argument 4 of 'info.proc' from incompatible pointer type [enabled by default] What could be wrong? From tone.kokalj at ijs.si Mon Sep 29 11:52:47 2014 From: tone.kokalj at ijs.si (Tone Kokalj) Date: Mon, 29 Sep 2014 11:52:47 +0200 Subject: [xcrysden] Segmentation fault on FreeBSD/amd64 In-Reply-To: <20140918071813.GA17054@strutter> References: <20140918071813.GA17054@strutter> Message-ID: <1411984367.14325.30.camel@catalyst.ijs.si> On Thu, 2014-09-18 at 13:18 +0600, Michael wrote: > Afternoon, > > I'm trying to compile and run XCrysDen on FreeBSD/amd64, with NVIDIA driver. > It dies with SIGSEGV. GDB output: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to LWP 100125] > 0x000000080162cebc in glXCreateNewContext () from /usr/local/lib/libGL.so.1 > (gdb) bt Apparently, the segfault comes from libGL library. Consider linking against some other libGL library (if you have others on you system) or else let the xcrysden to download and compile the Mesa that provides libGL/GLU; perhaps the so produced libGL will be OK. Regards, -- Anton Kokalj J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia (tel: +386-1-477-3523 // fax:+386-1-477-3822) Please, if possible, avoid sending me Word or PowerPoint attachments. See: http://www.gnu.org/philosophy/no-word-attachments.html