| bilsch <king621@comcast.net>: Apr 22 11:12AM Error messages are listed below. My OS is Linux Ubuntu 14.04. An OpenGL tutorial lesson requires installing devIL image loading libraries and headers I have just updated these libraries located in /usr/lib/i386- linux-gnu/ and header files located in /usr/include/. These are the usual locations where linker looks for these kinds of files. I'm getting 'undefined reference' errors for a lot of names associated with devIL. The tutorial says make sure that the linker can find the libraries. Well it seems like it isn't finding something it needs. Also, the tutorial says I need to link against devIL and ilu. Those names are not uniquely associated with specific files. I tried linking with -ldevIL and -lilu flags but the linker doesn't recognize those. The problem began with the introduction of devIL (no pun intended). I'm thinking I need to add something to an environment variable associated with g++ linker. But I looked in the environment and I don't recognize anything associated with running g++ (or gcc for that matter). Though I ran g++ my knowledge is not at C++ level. I write my own OpenGL programs using C and gcc. So far I muddle through with limited C++ knowledge. TIA. Bill S. /tmp/ccahLqPY.o: In function `initGL()': LUtil.cpp:(.text+0xe3): undefined reference to `ilInit' LUtil.cpp:(.text+0x10b): undefined reference to `ilClearColour' LUtil.cpp:(.text+0x110): undefined reference to `ilGetError' LUtil.cpp:(.text+0x124): undefined reference to `iluErrorString' /tmp/cceC2IEh.o: In function `LTexture::loadTextureFromFile(std::string)': LTexture.cpp:(.text+0x58): undefined reference to `ilGenImages' LTexture.cpp:(.text+0x63): undefined reference to `ilBindImage' LTexture.cpp:(.text+0x76): undefined reference to `ilLoadImage' LTexture.cpp:(.text+0x93): undefined reference to `ilConvertImage' LTexture.cpp:(.text+0xa8): undefined reference to `ilGetInteger' LTexture.cpp:(.text+0xb6): undefined reference to `ilGetInteger' LTexture.cpp:(.text+0xbd): undefined reference to `ilGetData' LTexture.cpp:(.text+0xea): undefined reference to `ilDeleteImages' |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Apr 22 09:00AM -0600 On Wed, 22 Apr 2015 11:12:33 +0000 (UTC), bilsch <king621@comcast.net> wrote: <snip> >I tried linking with -ldevIL and -lilu >flags but the linker doesn't recognize those. When you use "-ldevIL", exactly what do your compile and/or link commands look like, and exactly what errors do you get? Louis |
| bilsch <king621@comcast.net>: Apr 22 10:32PM On Wed, 22 Apr 2015 09:00:04 -0600, Louis Krupp wrote: > When you use "-ldevIL", exactly what do your compile and/or link > commands look like, and exactly what errors do you get? > Louis g++ LUtil.cpp main.cpp LTexture.cpp -w -lGL -lGLU -lglut -ldevIL -o 06_loading_a_texture /usr/bin/ld: cannot find -ldevIL collect2: error: ld returned 1 exit status |
| "K. Frank" <kfrank29.c@gmail.com>: Apr 22 09:15AM -0700 Hello Group! A couple of quick questions: override: If starting with a clean slate, would it have made sense to make the use of override mandatory? (I understand that making it mandatory would have severely broken backward compatibility.) That is: struct A { virtual void f(); virtual void g(); }; struct B : A { void f() override; // remains legal with mandatory override void g(); // not legal with mandatory override }; (I like override -- state your intentions, make code more readable, help catch errors -- but would have making it mandatory have been going to far?) final: I understand that there is debate about whether using final ever makes sense, but leaving that aside: Would declaring a virtual function final in a base class ever make sense? I.e., struct A { virtual void f() final; }; The only thing I can think of would be to force A to be a "polymorphic" class, e.g., trigger RTTI, etc., but this seems pretty contrived. Thanks for any insight. K. Frank |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 22 12:44PM -0400 On 4/22/2015 12:15 PM, K. Frank wrote: > override: > If starting with a clean slate, would it have made > sense to make the use of override mandatory? "Would it *have made* sense"? Why subjunctive? Why not just "does it make sense"? Yes, it does make sense just as much as without it. I suppose you are referring to a convention of some kind, or a coding standard... Those are like religion. If I don't like your standards, I won't work for your group. If I care to work for your group more than I care to argue with your standards, I will follow your standards... No more and no less. > (I understand that making it mandatory would have > severely broken backward compatibility.) I struggle to comprehend your tenses and moods, sorry. Coding standards are rarely retroactive. If you want to fix the existing code to force adherence to some kind of a standard, it's done in maintenance and a certain protocol (with lots of reviews and testing) should be established. And it's a topic for 'comp.software-eng' more than for c.l.c++... > (I like override -- state your intentions, make code more > readable, help catch errors -- but would have making it > mandatory have been going to far?) No. > The only thing I can think of would be to force A to > be a "polymorphic" class, e.g., trigger RTTI, etc., > but this seems pretty contrived. If the calling code is to be left unchanged, and the struct A is to be left untouched, and A::f is not declared 'final', then I can circumvent the call to that function by deriving from A and overriding 'f'. The only way to ensure that 'f' is called by the caller (without changing the calling code) is to declare 'f' final. It's a rare situation, but I am sure it's encountered often enough to justify that feature to exist in the language. V -- I do not respond to top-posted replies, please don't ask |
| drew@furrfu.invalid (Drew Lawson): Apr 22 05:27PM In article <mh8j2p$k50$1@dont-email.me> >> sense to make the use of override mandatory? >"Would it *have made* sense"? Why subjunctive? Why not just "does it >make sense"? Probably because C++ is not "starting with a clean slate." The language has been around for decades without "override." But would it have made sense for the draft in 1983 to have required it? >> (I understand that making it mandatory would have >> severely broken backward compatibility.) >I struggle to comprehend your tenses and moods, sorry. Then perhaps you shouldn't critique things you don't comprehend. -- Drew Lawson | "But the senator, while insisting he was not | intoxicated, could not explain his nudity." |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 22 02:07PM -0400 On 4/22/2015 1:27 PM, Drew Lawson wrote: >>> severely broken backward compatibility.) >> I struggle to comprehend your tenses and moods, sorry. > Then perhaps you shouldn't critique things you don't comprehend. I am sorry. I took it the OP was talking about setting up requirements for a new project, not development of the language in the early 1980s. V -- I do not respond to top-posted replies, please don't ask |
| "K. Frank" <kfrank29.c@gmail.com>: Apr 22 11:47AM -0700 Hi Victor! On Wednesday, April 22, 2015 at 12:44:19 PM UTC-4, Victor Bazarov wrote: > > sense to make the use of override mandatory? > "Would it *have made* sense"? Why subjunctive? Why not just "does it > make sense"? Yes, sorry, I should have been more clear. Yes (anticipating some of the comments downthread), I was thinking about the language standard (not about coding standards for a specific group or project), hypothetically what one would have done in the early 80's, hence the subjunctive. > If the calling code is to be left unchanged, and the struct A is to be > left untouched, and A::f is not declared 'final', then I can circumvent > the call to that function by deriving from A and overriding 'f'. To clarify: Just to complete that thought, if, furthermore, I didn't declare the function virtual (and no final) so that it couldn't be overridden, then the derived class could simply hide A::f by declaring its own B::f, also circumventing forcing A::f to be called. Does this fit logically with your train of thought? > am sure it's encountered often enough to justify that feature to exist > in the language. > V Thanks for your comments and perspective. K. Frank |
| legalize+jeeves@mail.xmission.com (Richard): Apr 22 06:48PM [Please do not mail me a copy of your followup] "K. Frank" <kfrank29.c@gmail.com> spake the secret code >struct A { > virtual void f() final; >}; In languages that have "final", I have found that it makes unit testing against those interfaces quite painful because most methods of mocking interfaces use derive-and-override. IMO, language features that make unit testing/mocking more difficult are best avoided. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 22 03:07PM -0400 On 4/22/2015 2:47 PM, K. Frank wrote: > hide A::f by declaring its own B::f, also circumventing forcing > A::f to be called. > Does this fit logically with your train of thought? Well, if the function is not virtual, and the caller uses the inherited type (not the derived one), the call is going to be statically resolved, not polymorphically, so the problem of substituting does not really exist. struct B { void foo(); }; void bar(B& b) { b.foo(); // calls B::foo } struct D : B { void foo(int); }; // hides B::foo int main() { D d; bar(d); // no problem here, no need of 'final' } V -- I do not respond to top-posted replies, please don't ask |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 22 02:12PM -0500 "K. Frank" <kfrank29.c@gmail.com> wrote in news:6de96531-40e2-421c-9cb0- > override: > If starting with a clean slate, would it have made > sense to make the use of override mandatory? Yes, I would vote for it, 'override' is quite helpful during refactoring. > Would declaring a virtual function final in a base class > ever make sense? I.e., Probably not, but this has never been a reason for banning something in C++ (not that you proposed that). |
| "Öö Tiib" <ootiib@hot.ee>: Apr 22 12:44PM -0700 On Wednesday, 22 April 2015 19:15:33 UTC+3, K. Frank wrote: > (I like override -- state your intentions, make code more > readable, help catch errors -- but would have making it > mandatory have been going to far?) It adds difficulties to those who have to compile same code with decade old compiler and with new compiler. It usually means preprocessor usage like that: #include "A.hpp" #if HAVE_OVERRIDE #define OVERRIDE override #else #define OVERRIDE 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment