Enemy Territory
I am tring to run Enemy Territory using linux emulation, and the program fails telling my it can't find libGL.so.1. I believe I need the linux version of this library, but I don't know where to get it. Any help would be great. --James ET 2.56 linux-i386 Sep 10 2003 - FS_Startup - Current search path: /home/will/.etwolf/etmain /usr/home/et/enemy-territory/etmain/pak1.pk3 (10 files) /usr/home/et/enemy-territory/etmain/pak0.pk3 (3725 files) /usr/home/et/enemy-territory/etmain/mp_bin.pk3 (4 files) /usr/home/et/enemy-territory/etmain -- 3739 files in pk3 files execing default.cfg couldn't exec language.cfg couldn't exec autoexec.cfg Hunk_Clear: reset the hunk ok --- Input Initialization --- Joystick is not active. Bypassing CD checks - Client Initialization - - Initializing Renderer --- - Client Initialization Complete - - R_Init - ...loading libGL.so.1: QGL_Init: dlopen libGL.so.1 failed: libGL.so.1: cannot open shared object file: No such file or directory failed - CL_Shutdown - RE_Shutdown( 1 ) --- - CL_Shutdown - --- Sys_Error: GLimp_Init() - could not load OpenGL subsystem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enemy Territory
I installed linux_dri and that did the trick. The game runs badly, I get horrible lag, but I think it my be the network. My X server also has problems at resolution at 1024x768, it tends to freze up the whole system, well at least the terminals. And when using dri, the X server can only be started once, if I close it and restart it agian it doesn't work correctly. Rebooting it fixes it. I will try a local game with a friend later. Thanks for the help. --James On 11/09/03 05:28:15, Lee Harr wrote: I am tring to run Enemy Territory using linux emulation, and the program fails telling my it can't find libGL.so.1. I believe I need the linux version of this library, but I don't know where to get it. Any help would be great. # cat /usr/ports/graphics/linux_mesa3/pkg-plist usr/X11R6/lib/libGL.so.%%GL_MAJOR_VER%%.%%GL_MINOR_VER%%.0 usr/X11R6/lib/libGL.so.%%GL_MAJOR_VER%% usr/X11R6/lib/libGL.so [...] # cat /usr/ports/graphics/linux_glx/pkg-plist lib/libGL.so lib/libGL.so.1 [...] # cat /usr/ports/graphics/linux_dri/pkg-plist usr/X11R6/bin/gears usr/X11R6/bin/glxinfo usr/X11R6/lib/libGL.so.1 [...] I am not sure which one is the one you want Maybe the pkg-descr files will help you to decide. _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] org -- God made the integers; all else is the work of Man. -- Kronecker ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help programming printer
You may need to convert the output before printing it, also you may make the program able to use lpr. Just a thought. --James On 11/09/03 12:53:01, [EMAIL PROTECTED] wrote: I am trying to port an old MS-DOS program and I have run into a stumbling block. The Mess Dos program wrote directly to the printer. I can't seem to find much information on how to print from a program. Can anyone recommend information on a web page or a book that I can learn more? Or am I just making this too hard? Thanks -Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] org -- God made the integers; all else is the work of Man. -- Kronecker ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Having trouble with buildworld
The file is missing. Now the question is why was it? I used cvsup to reteive the source. It is was missing from a clean arcive. I am including the supfile and the reject file. Any ideas - src-supfile - # $FreeBSD: src/share/examples/cvsup/stable-supfile,v 1.26 2002/07/30 14:08:16 blackend Exp $ # # This file contains all of the CVSup collections that make up the # FreeBSD-stable source tree. # # CVSup (CVS Update Protocol) allows you to download the latest CVS # tree (or any branch of development therefrom) to your system easily # and efficiently (far more so than with sup, which CVSup is aimed # at replacing). If you're running CVSup interactively, and are # currently using an X display server, you should run CVSup as follows # to keep your CVS tree up-to-date: # # cvsup stable-supfile # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 stable-supfile # # You may wish to change some of the settings in this file to better # suit your system: # # host=CHANGE_THIS.FreeBSD.org # This specifies the server host which will supply the # file updates. You must change it to one of the CVSup # mirror sites listed in the FreeBSD Handbook at # http://www.freebsd.org/doc/handbook/mirrors.html. # You can override this setting on the command line # with cvsup's -h host option. # # base=/usr # This specifies the root where CVSup will store information # about the collections you have transferred to your system. # A setting of /usr will generate this information in # /usr/sup. Even if you are CVSupping a large number of # collections, you will be hard pressed to generate more than # ~1MB of data in this directory. You can override the # base setting on the command line with cvsup's -b base # option. This directory must exist in order to run CVSup. # # prefix=/usr # This specifies where to place the requested files. A # setting of /usr will place all of the files requested # in /usr/src (e.g., /usr/src/bin, /usr/src/lib). # The prefix directory must exist in order to run CVSup. # ### # # DANGER! WARNING! LOOK OUT! VORSICHT! # # If you add any of the ports or doc collections to this file, be sure to # specify them with a tag value set to ., like this: # # ports-all tag=. # doc-all tag=. # # If you leave out the tag=. portion, CVSup will delete all of # the files in your ports or doc tree. That is because the ports and doc # collections do not use the same tags as the main part of the FreeBSD # source tree. # ### # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=cvsup4.FreeBSD.org *default base=/usr/local/etc/cvsup *default prefix=/usr # The following line is for 4-stable. If you want 3-stable or 2.2- stable, # change RELENG_4 to RELENG_3 or RELENG_2_2 respectively. *default release=cvs tag=RELENG_5_1 *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress ## Main Source Tree. # # The easiest way to get the main source tree is to use the src-all # mega-collection. It includes all of the individual src-* collections. # Please note: If you want to track -STABLE, leave this uncommented. src-all # These are the individual collections that make up src-all. If you # use these, be sure to comment out src-all above. #src-base #src-bin #src-contrib #src-etc #src-games #src-gnu #src-include #src-kerberos5 #src-kerberosIV #src-lib #src-libexec #src-release #src-sbin #src-share #src-sys #src-tools #src-usrbin #src-usrsbin # These are the individual collections that make up FreeBSD's crypto # collection. They are no longer export-restricted and are a part of # src-all #src-crypto #src-eBones #src-secure #src-sys-crypto --- refuse --- src/etc/sendmail/freebsd.mc* doc/da_* doc/de_* doc/es_* doc/el_* doc/fr_* doc/it_* doc/ja_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/zh_* ports/chinese ports/french ports/german ports/hebrew ports/hungarian ports/japanese ports/korean ports/portuguese ports/russian ports/ukrainian ports/vietnamese - On 10/06/03 02:50:38, Matthew Seaman wrote: On Sun, Oct 05, 2003 at 03:51:12PM -0700, James Jacobsen wrote: Here is the /etc/make.conf. # -- use.perl generated deltas -- # # Created: Tue Aug 26 09:51:56 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo XFREE86_VERSION=4 # -- use.perl generated
Having trouble with buildworld
make buildworld fails with make claiming that it doesn't know how to make freebsd.mc. I am not sure what is wrong. I have tried building on a clean source tree, and I have deleted /usr/obj. I have read the relivent sections of the handbook. I am running version 5.1 on a p3, and I got the source use cvsup. The source is from the releng_5_1. I think freebsd.mc is a sendmail config file, but I don't know. Any ideas would be appreciated. Thanks --Will SIZE does matter - The UK's biggest *Free* Web based mail - 10 MB Free mail.lycos.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Having trouble with buildworld
Here is the /etc/make.conf. # -- use.perl generated deltas -- # # Created: Tue Aug 26 09:51:56 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo XFREE86_VERSION=4 # -- use.perl generated deltas -- # # Created: Sun Oct 5 15:25:52 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo Also the file /etc/defaults/make.conf does not exist, never did. It is how ever mentioned in handbook. --James On 10/05/03 18:33:25, jason wrote: James Jacobsen wrote: make buildworld fails with make claiming that it doesn't know how to make freebsd.mc. I am not sure what is wrong. I have tried building on a clean source tree, and I have deleted / usr/obj. I have read the relivent sections of the handbook. I am running version 5.1 on a p3, and I got the source use cvsup. The source is from the releng_5_1. I think freebsd.mc is a sendmail config file, but I don't know. Any ideas would be appreciated. Thanks --Will SIZE does matter - The UK's biggest *Free* Web based mail - 10 MB Free mail.lycos.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] post your /etc/make.conf file. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() behavior (was: Pointer please)
It does not matter what freebsd does, C does not require that malloc initialize space according to Kernighan and Ritchie. Its a good book, I would say its worth the forty dollars. --Will On 10/05/03 20:32:00, Dan Nelson wrote: In the last episode (Oct 05), Robert Huff said: Dan Nelson writes: Could be one of two problems. The program either malloced memory and tried to use it without zeroing it, or it freed some memory and tried to keep using it. In -current, the malloc has the J debugging flag set, which fills malloced and freed memory with 0xd0 (see the malloc manpage). On that page (on my 5.1 system), it says malloc() does not zero allocated pages. Is this a change (possibly just for CURRENT), and if so since when? Bexause unless I'm delusional (possible) I thought pages /were/ supposed to be zeroed, and doing so was one of the system's as time permits chores. Pages handed to processes by the kernel are always zeroed, but pages free()d then malloc()ed again are not zeroed by default on -RELEASEs, because they usually aren't returned back to the kernel inbetween (unless H is set, and even then it's not guaranteed). -CURRENT always has the J flag set, which means that any memory returned by malloc or passed to free will get overwritten with 0xD0, to aid debugging. That's not mentioned in the manpage, although I think it is mentioned someplace else (either FAQ or handbook). -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() behavior (was: Pointer please)
What's really bad, is that freebsd could potentally change there behavor down the line. Its probably dictated by the way kernel dezined, meaning they may do whats the cheapist. I would. If they do its go to lead to some weird behavior. :-) --James On 10/05/03 21:42:23, Robert Huff wrote: James Jacobsen writes: It does not matter what freebsd does, C does not require that malloc initialize space according to Kernighan and Ritchie. I knew that, and agree depending on a particular behavior is bad programming practice. That said, there's a lot of bad programmers out there Robert Huff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() behavior (was: Pointer please)
Man, I need to learn to spell. :) --James On 10/05/03 22:20:42, James Jacobsen wrote: What's really bad, is that freebsd could potentally change there behavor down the line. Its probably dictated by the way kernel dezined, meaning they may do whats the cheapist. I would. If they do its go to lead to some weird behavior. :-) --James On 10/05/03 21:42:23, Robert Huff wrote: James Jacobsen writes: It does not matter what freebsd does, C does not require that malloc initialize space according to Kernighan and Ritchie. I knew that, and agree depending on a particular behavior is bad programming practice. That said, there's a lot of bad programmers out there Robert Huff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc() behavior (was: Pointer please)
You learn something new every day(probably not how to spell). I'm not a very experienced programmer. I actual did not know about those debugging tools. Thanks. :) --James On 10/05/03 22:31:09, Dan Nelson wrote: In the last episode (Oct 05), James Jacobsen said: On 10/05/03 21:42:23, Robert Huff wrote: James Jacobsen writes: It does not matter what freebsd does, C does not require that malloc initialize space according to Kernighan and Ritchie. I knew that, and agree depending on a particular behavior is bad programming practice. That said, there's a lot of bad programmers out there What's really bad, is that freebsd could potentally change there behavor down the line. Its probably dictated by the way kernel dezined, meaning they may do whats the cheapist. I would. If they do its go to lead to some weird behavior. :-) There's nothing bad about it. FreeBSD follows the standards. The debugging flags simply change what the undefined behaviour is. If you malloc a block of memory, you cannot rely on what data it currently contains. FreeBSD lets you zero it, fill it with a set value, or leave it. Programs exhibiting weird behaviour under any of those three cases are broken. Most debugging mallocs will trigger it, purify will probably catch it (never used it), and valgrind under Linux will definitely catch it. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
