A while ago I submitted a patch to fix ports/76293 ; this patch did not fully work (problem with 4.x) and was reassigned to ports-bugs with: Back to the pool: to be handled by a committer running a standard OpenGL, without nvidia driver. No one has since picked this up. The port is scheduled for removal in 1 month because it is still marked deprecated. Fix: Running same thing with: LD_PRELOAD=/usr/lib/libpthread.so tclsh8.4 ./gears.tcl works fine. Adding explicit -lpthread flag to the makefile also fixes the problem. How-To-Repeat: Build port. Run "gears.tcl", see garbage.
Not a solution - libpthread.so is not existant on FreeBSD 4.X and early 5.X releases. -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> No one expects the spanish inquisition.
> Not a solution - libpthread.so is not existant on FreeBSD 4.X and early > 5.X releases. I'm sorry, I do not understand this response. Please clarify: 1) "You wasted your time creating the patch, the port will be removed at the end of the month." 2) "You need to file a bug on threads maintainer." 3) Something else? I submitted all the information I had to a) get this port back into working shape b) explain the problem to anyone who understand gl/threads and the linker and is willing to spend the 5 minutes to fix it What am I missing to save this port? Since I am the reason it was marked deprecated in the first place, I feel responsible for a useful piece of software getting deleted from the tree; granted it took a lot of beating-head-against-wall to figure out what is wrong and get it to work, but certainly less than writing the thing from scratch. Mike
Mike pí¹e v st 01. 06. 2005 v 15:36 -0500: > > Not a solution - libpthread.so is not existant on FreeBSD 4.X and early > > 5.X releases. > > I'm sorry, I do not understand this response. > Please clarify: > > 1) "You wasted your time creating the patch, the port will be removed at the > end of the month." > 2) "You need to file a bug on threads maintainer." > 3) Something else? 3) Your proposed fix is incorrect. Threading library "libpthread" is something which was introduced to FreeBSD between releases 5.2 and 5.3. But we want to ports to work on 4.11 too, which don't have "libpthread". So, your fix will not work there. Now, I'd love to help, but I can't reproduce the problem, it works just fine here compiled from existing port. For record, it's amd64 box running 5.4-STABLE with radeon driver. I don't have FreeBSD 4.X installation with working GL, so can't test. If it's not broken, it can't be fixed. I read your older mails in ports/76293 and I can't see how linking against threading library could fix misbehaving 3D rendering. That's something what just don't happen often. To me it seems that best solution would be to remove DEPRECATED from port's Makefile. Port works as now, at least here. -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> Somebody ought to cross ball point pens with coat hangers so that the pens will multiply instead of disappear.
> 3) Your proposed fix is incorrect. Threading library "libpthread" is > something which was introduced to FreeBSD between releases 5.2 and 5.3. > But we want to ports to work on 4.11 too, which don't have "libpthread". > So, your fix will not work there. > > Now, I'd love to help, but I can't reproduce the problem, it works just > fine here compiled from existing port. For record, it's amd64 box > running 5.4-STABLE with radeon driver. > > I don't have FreeBSD 4.X installation with working GL, so can't test. > > If it's not broken, it can't be fixed. > > I read your older mails in ports/76293 and I can't see how linking > against threading library could fix misbehaving 3D rendering. That's > something what just don't happen often. > > To me it seems that best solution would be to remove DEPRECATED from > port's Makefile. Port works as now, at least here. Pav, I now understand what you mean. The "fix" I proposed was not something that should be comitted - the fix was a workaround for the problem. As I explaine in earlier messages, when linking the .so , if linking with -pthread the .so file contains some reference (it would be great if I knew what sort of reference this is) to libpthread.so; doing so makes GL "work" for me. linking with -thread does NOT result in the .so file containing a reference to a threading library, and the rest is garbled random output instead of a GL window. (when I say "linking with" I mean passing that flag to the linker; when I say "some reference" I mean it shows up in output of ldd) I wish I knew what the cause was - I do not - I am simply providing the symptoms and hoping someone understands this enough to either explain to me why this is happening or to fix it themselves. The patch I submitted added -lpthread to fix the above as well as fixed up all of the paths and properly installed examples into /usr/local/share/examples instead of providing the (useless on their own) example .so files without supporting tcl files in /usr/local/lib. At least the port should be UNmarked DEPRECATED. It would be good if the patch I submitted that fixes paths and properly installs a complete (usable) example would be comitted, at least modulo the addition of -lpthread to LFLAGS of the Makefile (since that part breaks the build on 4.x). Ideally someone would figure out why the -lpthread is necessary, but that sounds like a stretch to me. I don't even know who to ask - threads people, GL people, ...? Thanks. Mike
Mike pí¹e v st 01. 06. 2005 v 17:03 -0500: > The patch I submitted added -lpthread to fix the above as well as fixed > up all of the paths and properly installed examples into > /usr/local/share/examples instead of providing the (useless on their own) > example .so files without supporting tcl files in /usr/local/lib. Ok, let's take a look at the patch. You removed installation of example .so files, is that correct? I thought they're needed to run examples. > At least the port should be UNmarked DEPRECATED. It would be good if the > patch I submitted that fixes paths and properly installs a complete (usable) > example would be comitted, at least modulo the addition of -lpthread to LFLAGS > of the Makefile (since that part breaks the build on 4.x). Ideally someone > would figure out why the -lpthread is necessary, but that sounds like a > stretch to me. I don't even know who to ask - threads people, GL people, ...? I don't know, perhaps you could try our X11 people, most notably, anholt -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> East or west, ~ is best.
Responsible Changed From-To: freebsd-ports-bugs->pav Looks like I'm dealing with this
>> The patch I submitted added -lpthread to fix the above as well as fixed >> up all of the paths and properly installed examples into >> /usr/local/share/examples instead of providing the (useless on their own) >> example .so files without supporting tcl files in /usr/local/lib. > > Ok, let's take a look at the patch. You removed installation of > example .so files, is that correct? I thought they're needed to run > examples. Yes, this is correct. the example .so files (other then potentially togl.so) are completely useless without the accompanying .tcl files, and even with the tcl files are almost useless without the source files. furthermore, they are just that - examples. I therefore fixed the paths and changed the install/package list to install the .c and .tcl sources into local/share/examples/togl. This way, the example directory can be a starting step in using togl for one's own project. I will email anholt@ about the threads issue. Mike
Mike pí¹e v èt 02. 06. 2005 v 13:55 -0500: > >> The patch I submitted added -lpthread to fix the above as well as fixed > >> up all of the paths and properly installed examples into > >> /usr/local/share/examples instead of providing the (useless on their own) > >> example .so files without supporting tcl files in /usr/local/lib. > > > > Ok, let's take a look at the patch. You removed installation of > > example .so files, is that correct? I thought they're needed to run > > examples. > > Yes, this is correct. the example .so files (other then potentially togl.so) > are completely useless without the accompanying .tcl files, and even with > the tcl files are almost useless without the source files. furthermore, > they are just that - examples. I therefore fixed the paths and changed > the install/package list to install the .c and .tcl sources into > local/share/examples/togl. This way, the example directory can be a > starting step in using togl for one's own project. Okay so they are examples for coding, but you can't run them out of the box now, right? -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> Go back to bed America, your government is in control again. Here's American Gladiators. Watch this, shut up. Here's 56 channels of it. Watch these pituitary retards bang their fuckin skulls together and congratulate you on living in the land of freedom. -- Bill Hicks
>> Yes, this is correct. the example .so files (other then potentially togl.so) >> are completely useless without the accompanying .tcl files, and even with >> the tcl files are almost useless without the source files. furthermore, >> they are just that - examples. I therefore fixed the paths and changed >> the install/package list to install the .c and .tcl sources into >> local/share/examples/togl. This way, the example directory can be a >> starting step in using togl for one's own project. > > Okay so they are examples for coding, but you can't run them out of the > box now, right? You could never run them "out of the box", since only .so files were installed and not the .tcl files that drove them. An alternative to moving sources to local/share/examples and deleting .so's from local/lib is to install the .tcl example files into local/bin , is it really a good idea to add a /usr/local/bin/gears.tcl though? I didn't think so, so opted for getting rid of the .so's and instead putting their code, makefile, and .tcl into examples. Mike
Mike pí¹e v èt 02. 06. 2005 v 16:04 -0500: > >> Yes, this is correct. the example .so files (other then potentially togl.so) > >> are completely useless without the accompanying .tcl files, and even with > >> the tcl files are almost useless without the source files. furthermore, > >> they are just that - examples. I therefore fixed the paths and changed > >> the install/package list to install the .c and .tcl sources into > >> local/share/examples/togl. This way, the example directory can be a > >> starting step in using togl for one's own project. > > > > Okay so they are examples for coding, but you can't run them out of the > > box now, right? > > You could never run them "out of the box", since only .so files were installed > and not the .tcl files that drove them. An alternative to moving sources to > local/share/examples and deleting .so's from local/lib is to install the .tcl > example files into local/bin , is it really a good idea to add a > /usr/local/bin/gears.tcl though? I didn't think so, so opted for getting rid > of the .so's and instead putting their code, makefile, and .tcl into examples. What about putting .c, .tcl and .so into share/examples? Would it be possible to cd share/examples/togl; ./gears.tcl ? -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> > Why do we need a film of "Lord of the Rings" when we have the book? Because watching a cg enhanced Legolas fire a flaming arrow into the heart of a warg is cool? - asdf@asdf.com in rec.games.roguelike.angband
State Changed From-To: open->closed Relevant part of patch from ports/76293 committed