Re: Help building/running SDL/OpenGL code
On Wednesday 23 December 2009 22:54:07 Pieter de Goeje wrote:
On Wednesday 23 December 2009 04:42:28 Richard Mace wrote:
Incidentally, if there is anyone out there with newer hardware who is
interested in building the code I am talking about you can find it at:
http://physics.ukzn.ac.za/~richm/courses/phys110/lennard-jones-3d.html
You'll need to change the following lines in the Makefile to get it to
successfully build under FreeBSD:
==
CFLAGS = -Wall -Wextra -pthread -I/usr/local/include
-I/usr/local/include/SDL -O3 -march=native
LFLAGS = -Wall -L/usr/local/lib
lennardjones : $(OBJS)
$(CC) $(LFLAGS) -o lennardjones $(OBJS) -lSDL -lSDL_gfx -lGLU
==
It would be interesting to hear feedback. (Basic controls are: up-arrow
add heat to crystal; down-arrow cool down gas/crystal. There are a bunch
of others -- look in main.c). You are welcome to do whatever you wish
with my code.
Arrr. Same problem here at startup: segfault in glXGetFBConfigAttribSGIX. A
simple test case is the following:
py...@nox:~% cat test.c
int main() {}
py...@nox:~% cc -o test test.c -L/usr/local/lib -lSDL -lGL
py...@nox:~% ./test
zsh: segmentation fault (core dumped) ./test
Then I attempted to switch the arguments around...
py...@nox:~% cc -o test test.c -L/usr/local/lib -lGL -lSDL
py...@nox:~% ./test
py...@nox:~%
Voila! (Admittedly much to my surprise ;))
So then I changed the Makefile to use these libraries: -lGLU -lSDL
-lSDL_gfx. Result: a perfectly working ./lennardjones. The only minor
issue is that it presented me with exactly one option:
py...@nox:~/temp/lennard-jones-gas-3d% ./lennardjones
Current pixel depth: 32
Available Modes
0 = 3840 x 1200
Select your preferred video mode:
So apparently I prefer mode 0 :D. It run fine (and smooth) though.
It is clear something goes wrong during the runtime linking process, which
this library order works around. The actual problem is still a mystery to
me. It might be worthwhile to post a bugreport on the nvnews.net FreeBSD
forum.
Best regards,
Pieter de Goeje
Pieter, many, many thanks for taking the time to test and diagnose this. Your
solution works perfectly: ensure that libGLU PRECEDES all the SDL libraries in
the link line of the Makefile. Wow! I never would have thought
About your allowable modes being only 3840 x 1200: I had the same issue at
work (Linux) where I run dual monitors (2 x 1680 x 1050). Just create an
NVIDIA metamode in your xorg.conf that blanks one monitor (I do not recall the
exact syntax here, but I think you need to use NULL for the one monitor). It
is also useful for some games ;-) Then you can use one screen and avoid
staring at the crack between your monitors during simulations.
Again, many thanks. This for me is proof that I can continue to do some
scientific programming (with rendering in 3D) under FreeBSD .
-Richard
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Help building/running SDL/OpenGL code
I developed a small molecular dynamics simulation under Linux some time ago. Since recently moving to FreeBSD I thought that I'd try to get it running here, too. However, although I am able to get the code to build, it dumps core -- apparently before getting to any user code! During the build (linking phase) I get one error which seems to be a pointer to the source of the problem: = gcc -Wall -L/usr/local/lib -o lennardjones main.o anim-thread.o ode.o gasdynamics.o eyedynamics.o -lSDL -lSDL_gfx -lm -lGLU /usr/bin/ld: warning: libm.so.3, needed by /usr/local/lib/libGL.so.1, may conflict with libm.so.5 = Note the last two lines. (I have included the two previous lines to show the dependent libraries, if that helps.) Important information: 1) I am running the code on an i386 machine with the NVIDIA driver (nvidia- driver-173 for an old FX 5200). 2) I installed the Mesa Libs after installing the NVIDIA driver. I then thought this might produce a conflict with the Nvidia-supplied GL libs, so un- installed the NVIDIA driver. Then re-installed after installing mesa-demos. 3) glxinfo | grep -i render reports: direct rendering: Yes OpenGL renderer string: GeForce FX 5200/PCI/SSE2 4) glxgears runs without problems When I uninstall the NVIDIA driver and build the code, the linker error above disappears and the code runs to the point where I can select the graphics mode, i.e., it executes user code without dumping core. However, selecting any mode now gives (somewhat expectedly): === selected video mode is: 1280 x 1024 (32 bpp) Could not set video mode: Couldn't find matching GLX visual === So, it appears that there is some conflict between the mesa libraries (which I need to #include to build the code) and the NVIDIA-supplied libraries, or am I on the wrong track? Can anyone shed some light on this? I've spent quite some time on what first appeared to be a fairly trivial task and I am eager to see how this runs under FreeBSD. Thanks in advance... -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Help building/running SDL/OpenGL code
On Tuesday 22 December 2009 18:28:07 you wrote: On Tue, Dec 22, 2009 at 05:36:19PM +0200, Richard Mace wrote: I developed a small molecular dynamics simulation under Linux some time ago. Since recently moving to FreeBSD I thought that I'd try to get it running here, too. However, although I am able to get the code to build, it dumps core -- apparently before getting to any user code! During the build (linking phase) I get one error which seems to be a pointer to the source of the problem: = gcc -Wall -L/usr/local/lib -o lennardjones main.o anim-thread.o ode.o gasdynamics.o eyedynamics.o -lSDL -lSDL_gfx -lm -lGLU /usr/bin/ld: warning: libm.so.3, needed by /usr/local/lib/libGL.so.1, may conflict with libm.so.5 = Note the last two lines. (I have included the two previous lines to show the dependent libraries, if that helps.) Looks like the libGL supplied by nvidia was built for FreeBSD 5. Try installing the /usr/ports/misc/compat5x port. That includes libm.so.3, and might help. If you are not running the GENERIC kernel, make sure your kernel contains the right COMPAT_FREEBSD5, COMPAT_FREEBSD6 and COMPAT_FREEBSD7 options. Roland Thanks, Roland. Apparently /usr/ports/misc/compat5x is installed: toutatis# make install clean === Installing for compat5x-i386-5.4.0.8_11 === compat5x-i386-5.4.0.8_11 depends on file: /usr/local/share/compat/locale/UTF-8/LC_CTYPE - found === Generating temporary packing list === Checking if misc/compat5x already installed === compat5x-i386-5.4.0.8_11 is already installed = And... ls -al /usr/local/lib/compat/libm.* -r--r--r-- 1 root wheel 120004 Dec 13 06:18 /usr/local/lib/compat/libm.so. I am using the stock 8.0-RELEASE kernel on a 3-week old install. Any other ideas on where the conflict/problem may lie? -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Help building/running SDL/OpenGL code
On Tuesday 22 December 2009 19:31:31 you wrote: What version of the nvidia driver are you using? The one in /usr/ports/x11/nvidia-driver-173. I have to use this for the aging FX 5200. Have a look at the x11-drivers/xf86-video-nouveau port. Maybe that works for you? (BTW, problems like these are why I avoid proprietary drivers like the plague) I'm rendering a whole bunch of molecules (spheres), moving a camera and at the same time doing quite a bit of CPU intensive numerical integration of a whole slew of coupled ordinary differential equations -- I need the speed of the GPU (read proprietary driver) to relieve the CPU and avoid a slide show. (This works very nicely with dual core CPUs: I use one thread for the rendering and another for the numerics.) I'll keep digging (and getting educated, I guess). Incidentally, in Debian GNU/Linux they have a system of clever diverts which avoid these kinds of library clashes. Thanks -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Help building/running SDL/OpenGL code
On Tuesday 22 December 2009 20:35:19 you wrote: On Tue, Dec 22, 2009 at 07:50:19PM +0200, Richard Mace wrote: On Tuesday 22 December 2009 19:31:31 you wrote: What version of the nvidia driver are you using? The one in /usr/ports/x11/nvidia-driver-173. I have to use this for the aging FX 5200. Have a look at the x11-drivers/xf86-video-nouveau port. Maybe that works for you? (BTW, problems like these are why I avoid proprietary drivers like the plague) I'm rendering a whole bunch of molecules (spheres), moving a camera and at the same time doing quite a bit of CPU intensive numerical integration of a whole slew of coupled ordinary differential equations -- I need the speed of the GPU (read proprietary driver) to relieve the CPU and avoid a slide show. (This works very nicely with dual core CPUs: I use one thread for the rendering and another for the numerics.) In this case it might be better to invest in a more recent graphics card. Currently Radeons (up to and including R6xx/R7xx) are better supported by open source drivers than nvidia. I'll keep digging (and getting educated, I guess). Incidentally, in Debian GNU/Linux they have a system of clever diverts which avoid these kinds of library clashes. As far as I know, the compat libraries are meant to be able to keep using old binaries on newer systems. I do not think they were ever meant to be used in a mixed (as in linking with both libm.so.3 and libm.so.5) environment. From experience (botched ports upgrade going from 6.x to 7) I know that having a program linked to different versions of the same library can result in interesting experiences (i.e. crashes). There are several things you could try, from building your app and the libraries it needs on a 5.x machine to trying to get the libGL to link with the current libm. Whatever you do, it will probably end up being a kludge. Roland Thanks again for the suggestions, Roland. In the end, as a last resort, I de-installed the nvidia driver and started X with an empty /etc/X11/xorg.conf (which presumably loads the nv driver). I re-built my code and it runs, albeit without the smoothest of graphics. I guess that that proves that the problem lies with the NVIDIA driver and its inter-relationship with the Mesa libraries, which one has to use if one builds one's own OpenGL programs. It is a pity that FreeBSD has not sorted that out, but I hasten to add that I'm new to FBSD and it could be my error. It does beg the question, though, how one would develop OpenGL apps on FBSD? I'll revisit this soon, after some careful googling. Thanks again for the help. -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Help building/running SDL/OpenGL code
On Wednesday 23 December 2009 04:20:28 Pieter de Goeje wrote: On Tuesday 22 December 2009 22:00:51 Roland Smith wrote: On Tue, Dec 22, 2009 at 09:57:57PM +0200, Richard Mace wrote: In the end, as a last resort, I de-installed the nvidia driver and started X with an empty /etc/X11/xorg.conf (which presumably loads the nv driver). I re-built my code and it runs, albeit without the smoothest of graphics. On a recent core2 duo or quad, even software rendering isn't that bad. True, until you press the full screen(s) button of your program running on your dual 1920x1200 monitor setup like I do ;-) Suddenly you're watching a slideshow... I guess that that proves that the problem lies with the NVIDIA driver and its inter-relationship with the Mesa libraries, which one has to use if one builds one's own OpenGL programs. Yes. Agreed. It's quite annoying that the nvidia drivers replace the existing mesa GL libs, which breaks OpenGL when you switch back to mesa rendering. However, because the library is implemented by nvidia for their hardware, it is also blazingly fast. It is a pity that FreeBSD has not sorted that out, but I hasten to add that I'm new to FBSD and it could be my error. What I meant here by sort out was that FreeBSD provide some way for Mesa libs and NVIDIA drivers to co-exist. It seems that you (as new user) have to learn, through error, that you need to install Mesa first, then NVIDIA (and whenever Mesa-related apps get an upgrade you need to re-install NVIDIA). Would be nice if these two ports could check for each other's existence before install and do the necessary to the libGL* symbolic links. It was nvidia's decision to drop support for older cards from their recent drivers. Nothing that the FreeBSD project can do about that. The oldest cards that the new drivers support are the GeForce 6xxx series, which are over 5 years old. I'm not saying that I approve dropping support but frankly I don't really care for 3D acceleration on graphics cards that old. The latest nvidia drivers are actually built using a more recent version of FreeBSD so you won't have that linking problem. Which is indeed the most likely cause of the problem. I don't understand why glxgears does run and your simulation does not though... I would've expected both too fail or work. This is confusing to me, too, which led to the question immediately below. It does beg the question, though, how one would develop OpenGL apps on FBSD? I'll revisit this soon, after some careful googling. Personally I use a recent nvidia card with the latest nvidia drivers. This has worked well for me, but I don't use SDL. My programs tend to use the simple GLUT/GLU/GL combo or wxGTK/GLU/GL if I need more controls. Loading textures is done using DevIL. Unfortunately my old GeForce 4 is broken so I can't test the legacy drivers any more. Get a card that is well-supported by the drivers in the FreeBSD kernel and Xorg/Mesa. Currently that means Intel's on-board graphics or boards with Well, right now I am evaluating FreeBSD on an old machine (Pentium IV, NVIDIA FX5200) to see whether I would make the switch from Debian GNU/Linux. I don't really want to purchase a new card for this purpose. Perhaps I will try to install FBSD on my laptop, which is dual-core and has an NVIDIA Quadro FX 570M on board. If you're going with intel you might as well use software rendering :-) I'd agree there ;-). ATI/AMD radeon chips, except for the latest chips. AMD released docs for those chips some months ago, and the drivers for accellerated 3D are still evolving. Yes, AMD's efforts are very commendable. Accellerated 3D works fine on my Radeon X1650 equipped card with the xf86-video-ati driver and the drm.ko and radeon.ko kernel modules. Roland Thanks to all for your help and suggestions. Incidentally, if there is anyone out there with newer hardware who is interested in building the code I am talking about you can find it at: http://physics.ukzn.ac.za/~richm/courses/phys110/lennard-jones-3d.html You'll need to change the following lines in the Makefile to get it to successfully build under FreeBSD: == CFLAGS = -Wall -Wextra -pthread -I/usr/local/include -I/usr/local/include/SDL -O3 -march=native LFLAGS = -Wall -L/usr/local/lib lennardjones : $(OBJS) $(CC) $(LFLAGS) -o lennardjones $(OBJS) -lSDL -lSDL_gfx -lGLU == It would be interesting to hear feedback. (Basic controls are: up-arrow add heat to crystal; down-arrow cool down gas/crystal. There are a bunch of others -- look in main.c). You are welcome to do whatever you wish with my code. -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send
How to build VLC port
Sorry if this is well-known. I have googled but came up with nothing. (I am relatively new to FreeBSD.) I am running 8.0-RELEASE. I am trying to build VLC with # cd /usr/ports # make install clean But I get the message: === vlc-1.0.3_4,3 is marked as broken: doesn't build with dirac. *** Error code 1 I tried a # make config but cannot find out how to turn off the dirac depends (is it possible?). Thanks for any pointers. -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to build VLC port
Sorry if this is well-known. I have googled but came up with nothing. (I am relatively new to FreeBSD.) I am running 8.0-RELEASE. I am trying to build VLC with # cd /usr/ports You mean ../multimedia/vlc ? Yes, indeed. Sorry. # make install clean I'm building it now. But I get the message: === vlc-1.0.3_4,3 is marked as broken: doesn't build with dirac. *** Error code 1 I tried a # make config Try make rmconfig Thanks. I tried this (make rmconfig) and still got the same error: == toutatis# make install clean === vlc-1.0.3_4,3 is marked as broken: doesn't build with dirac. *** Error code 1 Stop in /usr/ports/multimedia/vlc. == Any other ideas? -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to build VLC port
On Sat, 12 Dec 2009 15:49:06 +0100
Bernt Hansson be...@bah.homeip.net wrote:
Richard Mace:
=== vlc-1.0.3_4,3 is marked as broken: doesn't build with dirac.
*** Error code 1
I tried a
# make config
Try make rmconfig
You also need to remove the dirac package if it's already installed.
Thanks for the hint. Actually, you don't need such a drastic measure, it
seems.
I looked into the Makefile and found:
.if (defined(WITH_DIRAC) || exists(${LOCALBASE}/lib/libdirac_decoder.a))
!defined(WITHOUT_DIRAC)
BROKEN= doesn't build with dirac
I did a
# make -DWITHOUT_DIRAC
and it seems to be building.
As I type this I see confirmation of the solution above from Warren Block
(Thanks!)
-Richard
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Cannot write to nfsv4 share
I am running 8.0-RELEASE. I am able to mount an nfsv4 share on a Debian GNU/Linux server, but I cannot write to it. I realise that nfsv4 is experimental on FreeBSD, but I am tantalisingly close to getting it working and thought that someone here could advise, or point me to some (web) reference. I have googled but have not found anything relevant to this problem. I have enabled the following in /etc/rc.conf: nfs_client_enable=YES nfsuserd_enable=YES nfsuserd_flags=-domain localdomain nfscbd_enable=YES I have passed the domain localdomain to nfsuserd via nfsuserd_flags because that is what it is set to (by default) via /etc/idmapd.conf on the Linux server. I mount the remote location using: # mount -t nfs -o nfsv4,rw 192.168.x.x:/freeagent /mnt which succeeds (either with or without the rw option) # mount /dev/ad2s1a on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/ad2s1e on /tmp (ufs, local, soft-updates) /dev/ad2s1f on /usr (ufs, local, soft-updates) /dev/ad2s1d on /var (ufs, local, soft-updates) 192.168.x.x:/freeagent on /mnt (newnfs) When I execute an ls -al on /mnt all the directories have the correct permissions, except for one (NOTE THE GROUP -- 32767) drwx--2 root 32767 16384 Jul 5 12:28 lost+found If I try, either as root, or as my regular user account, to write to the drive I get $ cd /mnt $ touch junk touch: junk: Permission denied I have checked the directory permissions for my user and they are correct. I use the same username (and group) on both the FreeBSD desktop and the Linux (NFS4) server and, according to the permissions, I own and should be able to write to the share: $ cd /mnt $ ls -ald . drwxr-xr-x 7 username username 4096 Dec 11 13:37 . I can successfully read from the nfs4 mounted drive, but I cannot write to it. Has anyone got any idea where I have gone wrong. (If I boot to Linux on the same client I can successfully mount and read/write, so I'm reasonably certain the server side is set up correctly.) -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie questions (updating, ports, etc.)
Thanks to all for your detailed and informative replies to my questions. I have many new things to try out. I can't speak for anyone else, but long posts don't bother me. I hope we've clarified things for you. Welcome to FreeBSD! Thanks. Its good to be here! -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Newbie questions (updating, ports, etc.)
I recently installed FreeBSD 8.0-RELEASE on my home desktop and am considering making the switch from Debian GNU/Linux. I have a few questions which I am hoping the list can clarify for me. 1.) Keeping installed ports/packages up to date. As far as I can tell from the docs, perhaps the most convenient method is to use something like: # portsnap fetch update # pkgdb -F # portupgrade --batch -aP (do I need an R here?) which should first try to find a package from the repositories and failing that will fall back to a port. What is the current wisdom here? Is it safe to use the --batch switch? As far as I understand, this will use the configuration defaults and not prompt the user whenever a port requires some user (options) configuration. Is this interpretation correct? Otherwise, is there a way to get portupgrade to use the defaults non-interactively, to automate the process. Related to the above, are the default options that appear in the ncurses dialogues the same as those used in the building of packages? 2.) Evolution of ports (and packages) versus evolution of the base system. Reading the docs makes it clear that FreeBSD maintains is a rigorous distinction between the base system and add-on packages (ports). This is very appealing. However, as far as I can tell so far, even though my base system is 8.0 -RELEASE (and remains fixed between releases?), the ports continuously evolve (are updated). Is my understanding correct that by tracking a RELEASE system I can have bleeding edge (or close) versions of ports? Or, do I need to track STABLE of CURRENT for that? 3.) Upgrading ports seems to take considerable time (at least with my experiments on a 5 year old Pentium IV). I am keen to adopt FreeBSD as my desktop for work (Physics Professor, Research and teaching). Is it feasible in a work environment to upgrade ports without getting bogged down in a compile-a-thon, leaving one with a useless workstation. (My target machine will be an 8-core HP z600 (Xeon) which leads me to believe that I could do the upgrading in the background while I continue to work uninterrupted. I'd like to hear others experiences here.) Sorry for the long post, but I could not find clarification on the above in the Handbook and other sources I've read. -Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
