I have few questions about getting started with OpenGL development under Linux. Please bear in mind that I have never used Linux in my life until two days ago. I have done a lot of research but I'm confused about few things.
1- What is mesa? Is it a driver or something like GLEW? if it is a driver why would you use it rather than Nvidia or AMD driver? Also how can I use OpenGL without installing libgl1-mesa-dev package? doesn't libgl come with Nvidia or AMD drivers or even with linux itself?
Mesa is a big amorphous thing.
In Mesa you will find a software implementation of OpenGL and OpenGL|ES, the official Intel video drivers, the official Gallium video drivers, and an unofficial implementation of the OpenGL development libraries (it's unofficial because the Khronos group, who owns the OpenGL brand, requires a fee of US$ 10 000 per year for official recognition, and Mesa is a penniless Free software project).
Generally speaking on desktop-oriented Linux-based and BSD-based OSes, you develop against Mesa and you run against the official OpenGL or OpenGL|ES drivers, which may or may not include Mesa, Free, or proprietary binary blob drivers from chip vendors like those from AMD or nVidia. What your OS ships in its userspace is up to the distributor, but libGL.so is usually defaulted to the one supplied by Mesa and softlinked to the AMD or nVidia binary blobs during setup.
You still need an extension wrangler library like GLEW because OpenGL uses plenty of extensions.
If I try to compile my code without installing libgl1-mesa-dev package I get an error saying "cannot find -lgl". Doesn't Linux already have the latest version of OpenGL? and if it does how can i link to it? where is it located?
The classic Linux desktop OS, like all POSIX systems, has a case-sensitive filesystem. The correct linker switch to pull in libGL.so is "-lGL".
2-Why would you use GLEW under linux? I thought GLEW only job to implement functions that links to the driver under windows. The reason for this is because windows only support OpenGL 1.0. So GLEW gives access to OpenGL 1.0+ functions. So Linux doesn't need that since Linux support every version of OpenGL natively. Doesn't it?
The job of an OpenGL extension wrangler library like GLEW is to wrangle extensions for OpenGL. Not only do different version of OpenGL have different sets of optional functionality (extensions), but different vendors supply different extensions to take advantage of their specialized hardware designs. The use of GLEW to wrangle extensions is independent of the OS on which you are using OpenGL. If you have access to a shell command line, try typing 'glxinfo|less' and return to see, among other things, a list of extensions the driver you are currently using offers.
3- What does the "-l" stands for in "-lgl" or "-lX11"? does it stand for library?
Yes, the "-l" command-line switch tells the compiler driver (which in turn drives the symbolic linker) to look for a certain library in its library search path and use it to resolve any outstanding unresolved symbols. A switch of "-lGL" would tell it to look for a library named "libGL.so" which would be installed by the development package for GL. On Ubuntu, that would be the package called libgl1-mesa-dev but your OS or distribution may differ.
What I want to do is basically create a window and an OpenGL 3.2+ context under Linux. So I assume I only need to use glx and OpenGL. I don't want to use any other dependency that I don't have to. Can I do that under Linux? I know in windows all I need is glew, wgl and windows API.
Yes, you can just assume that Linux == X11 and write software like it's 1999. I'd strongly recommend that if you're going to write software for Linux, you target Linux and not X11 because the assumption that they're the same thing has not been a valid one for years. If you're just writing for yourself and don't plan on distributing your code or upgrading your system, of course you can stick with GLX. It's bundled as a part of Mesa.
I would recommend that if you want to write software for Linux and need an OpenGL context (or better yet, and OpenGL or OpenGL|ES context), you use libSDL to handle your context creation and input. The overhead is not large, the code is minimal, and your software will also work with a modern Linux OS running Mir or a Wayland display server, on desktops, laptops, tablets, phones, refrigerators, and so on. Also, it will work on Windows and Mac OS. One code base to rule them all. That's a good thing.
so I my final question is, How can I find glx.h and link to OpenGL under Linux without using mesa or GLEW?
You can't. Well, you could grab the header from khronos.org, but you're still going to need the development libraries to link to. Using Mesa is how you do it.
You will need to install the development packages required to develop against OpenGL. I really strongly recommend not using GLX directly, but use libSDL2 instead. If you install the libSDL2 development packages (on Ubuntu, that's 'sudo apt install libsdl2-dev') it should pull in all the other required development packages as dependencies -- that's how Linux distribution package managers work.
This is the cause of your problem. You end up with a reference to a deleted object because the referent goes out of scope after the return statement. Very bad.
Global variables need to be in static storage. Either make temp a static local, a cass variable, or move it out of your class entirely and make it a namespace-level variable. It's your disguising the global as something else that's hiding your problem in the first place. Another lesson in why globals are poor practice.
that's what i thought so too, like in windows, SDL uses win32 api, etc. i asked coz i thought they are using another way..
It's not just a compile-time option. For example, on Linux, libSDL2 autodetects whether the system renderer is X11, Mir, or Wayland automatically, then instantiates the appropriate back end (by loading a DSO) to handle the required operations. On top of that, there's an EGL layer for handling OpenGL vs. OpenGL|ES and EGL itself needs to know the native renderer and window manager for context creation. That gives you nine possible combinations of dynamically determined back ends on Linux alone. None of that is compile-time, although the order in which back ends are autodetected is set at compile time (and at Ubuntu we switch the order so X11 is tried last instead of first).
Other supported platforms are simpler because they have a choice of one system renderer.
The stacktrace in the original post indicates a double deletion of an object of static storage duration (ie. a global object). The likely cause is the lack of a proper copy constructor or copy assignment operator in a class that contains pointers and inattention to the copy semantics of the objects.
A grand tool to use to analyze exactly these errors is 'valgrind'.
Back in the early 1970s I stumbled on the little gem of a CARDIAC computer, which turned me on to programming and then I learned to dig computer science in general. If you want to learn how computers work at the opcode and register level there is nothing better, and you can join the maker set and build one yourself (complete with manual). I still have mine.
So from my understanding then, with the current 'shallow' copy the vector is causing the destructor to be called which is then deleting cleaning up 'memblock' making the pointer to the copy of 'memblock' invalid. This sound right?
Google 'C++ rule of three' for some greater enlightenment.
Redhat is also a long time player. Its server version is RedHat Enterprise, which comes with commercial support iirc. For just the software, you can use Centos (copy of Enterprise, but no (or not much) support from them). At the other end is Fedora, very close to bleeding edge. Release cycle is 6 months, life time of a release is 1 year.
Red Hat is a commercial server operating system. Not recommended for beginners or for game dev. The first time you run up against the mysteries of SELinux you will understand. Or maybe not understand, which is the root of the problem.
Centos is the free version of Red Hat for people who don't want to pay thousands per year for support. It's effectively identical to Red Hat, and owned by Red Hat, but you get zero support. Many less expensive ISPs run Centos in their server farms.
Fedora is the desktop version of Red Hat, run by an arms-length community sponsored by Red Hat. It tends to be more leading-edge and is used as a testing ground for new technology and software before it lands in Red Hat. It uses Gnome Shell as the UI, which is backed primarily by Red Hat.
SuSE is another enterprise-oriented distro. It used to be Novell before Microsoft turned their attention to networking.
Debian is a purely volunteer-run general distribution, mostly focused on server because that's where most of the volunteer's interests lie. It's not an organization per se, it's more of an anarchy that offers downloads and the occasional sneer if you ask for help.
Ubuntu is roughly based on Debian, but with more testing (many Debian packages are patched for Ubuntu to fix bugs found in testing). It has a commercial company sponsoring it (Canonical), which also sponsors various community help channels. Also has a server edition and runs on phones and tablets. There are some official flavour of Ubuntu that sport different default UIs (eg. Ubuntu Gnome, Kubuntu (KDE), Lubuntu (LXDE), Ubuntu Mate). Generally works out of the box except you have to install closed-source codecs and drivers explicitly because distributing them together with Free software is of questionable legality. Companies like Valve and Google use Ubuntu internally and Canaonical regularly works with Intel, AMD, and nVidia to keep their video drivers working.
Mint is a popular rebranded Ubuntu with either the Mate desktop or the Cinnamon desktop and bundled with commercial codecs and drivers. They usually refer you to Ubuntu for help.
Arch is popular among the set where it's popular to measure the size of your hard drive in public change rooms. Many users have unbridled enthusiasm about their choice of distro.
I would recommend, if you're a beginner, to stick with either Fedora, Ubuntu, or Mint. They're generally stable and well-tested and have active, welcoming (mostly) communities and user support.
Disclaimer: I work for Canonical and develop parts of Ubuntu. I also contribute to Debian.