I used the word hierarchy, but I'm not sure if it's the right one! Let me explain.
I have A.h with:
#include <iostream>
#include <vector>
using namespace std;
I have B.h with:
typedef vector<int> int_vector;
int_vector my_function(int x, int y);
Finally I have X.h, which is:
#include "A.h"
#include "B.h"
And X.cpp:
#include "X.h"
// and the rest
But when I compile that with GCC, it says in B.h, vector not defined and so on. Note that this is an example to explain the problem. The project I'm trying to convert to compile on linux compiles perfectly on Windows under Visual Studio.
I could change the files, but it a 300+ files project, so any help or suggestion that would be incredibly efficient ?
There's nothing wrong with the code that you've posted, and it seems unlikely that there would be a bug of this nature in gcc.
More likely the problem isn't what it seems. For example, it could be that there are multiple A.h (or B.h, or X.h) files in your project, and the wrong file is being included somewhere.
My advice would be to run one problematic .cpp file through the preprocessor (gcc -E) and examine the result. That will tell you exactly what is being included when.
Related
I'm trying to compile the c code generated by Embeddinator-4000 but Xcode can't find the specified path to Mono.
These are the headers that are currently giving me problems:
#include <mono/jit/jit.h>
#include <mono/metadata/mono-config.h>
#include <mono/metadata/assembly.h>
#include <mono/metadata/debug-helpers.h>
#include <mono/metadata/object.h>
However these paths work:
#include <Mono/mono-2.0/mono/jit/jit.h>
#include <Mono/mono-2.0/mono/metadata/mono-config.h>
#include <Mono/mono-2.0/mono/metadata/assembly.h>
#include <Mono/mono-2.0/mono/metadata/debug-helpers.h>
#include <Mono/mono-2.0/mono/metadata/object.h>
The problem is that jit.h includes <mono/metadata/appdomain.h> and Xcode can't find it.
Is there a way to alias the framework so I don't have to modify my current install of Mono?
Thanks!
The following snippet of ffmpeg-based code is building and working on Windows VC2012, VC20155, VC2017.
With gcc on Ubuntu LTS 16.04 this is giving me issues, more specifically it does not seem to recognize avcodec_send_packet, avcodec_receive_frame and struct AVCodecParameters, and possibly more functions and structures that I'm not currently using.
error: ‘AVCodecParameters’ was not declared in this scope
error: ‘avcodec_send_packet’ was not declared in this scope
error: ‘avcodec_receive_frame ’ was not declared in this scope
The code snippet is:
// the includes are actually in a precompiled header, included in cmake
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavdevice/avdevice.h>
#include <libavfilter/avfilter.h>
#include <libpostproc/postprocess.h>
#include <libswresample/swresample.h>
#include <libswscale/swscale.h>
#include <libavformat/avformat.h>
#include <libavutil/avutil.h>
#include <libavutil/avassert.h>
#include <libavutil/avstring.h>
#include <libavutil/bprint.h>
#include <libavutil/display.h>
#include <libavutil/mathematics.h>
#include <libavutil/imgutils.h>
//#include <libavutil/libm.h>
#include <libavutil/parseutils.h>
#include <libavutil/pixdesc.h>
#include <libavutil/eval.h>
#include <libavutil/dict.h>
#include <libavutil/opt.h>
#include <libavutil/cpu.h>
#include <libavutil/ffversion.h>
#include <libavutil/version.h>
}
//
...
{
if (av_read_frame(m_FormatContext, m_Packet) < 0) {
av_packet_unref(m_Packet);
m_AllPacketsSent = true;
} else {
if (m_Packet->stream_index == m_StreamIndex) {
avcodec_send_packet(m_CodecContext, m_Packet);
}
}
}
...
I read up on the ffmpeg history and learned that on Debian based systems at one point they followed the fork to libavutil when that came about, and then recently some of the platforms switched back to the ffmpeg branch due to the fact that ffmpeg was much more actively supported in terms of bugfixes, features and support. As a result, some of the interfaces were possibly broken.
I've seen git fixes on a library called mediatombs who seem to have ecountered the same if not very similar issues with codecpar (which I initially also had and fixed the same way):
https://github.com/gerbera/gerbera/issues/52
https://github.com/gerbera/gerbera/commit/32efd463f138557c54535225d84136df95bab3dd#diff-af3b638bc2a3e6c650974192a53c7291
Here the commit seems to fix their specific issue by wrapping the codecpar field that is being renamed back to codec, which I also applied and works.
I wonder if anyone knows which functions can be used for the errors given above, since in fact these functions are themselves replacing deprecated functionality according the ffmpeg avcodec.h header comments. (https://www.ffmpeg.org/doxygen/trunk/avcodec_8h_source.html). I hope this does not mean I would have to settle back into avcodec_encode_video2() type of functions?
Update:
For reference, it seems it has also popped up here: https://github.com/Motion-Project/motion/issues/338. The issue seems to be resolved if you can rebuild your ffmpeg stack.
Update:
To resolve the version API mingle, I ended up wiping out any ffmpeg reference and rebuilding ffmpeg from sources. This seems to push things further along in the right direction; I have my source compiling correctly but there is still something wrong with the way I'm linking things together.
Also, I'm using CMake to set up my makefiles, and using find_package for some of the dependencies and handwritten find_path / find_library stuff for everything else. I've seen other people complain about the following linking issue, and a ton of case-specific replies but none of them really shed some light on what the actual problem is. My installed Ubuntu version of ALSA is 1.1.xx but still I get complaints about a 0.9 version I'm supposedly linking. Anyone knows what's wrong with this?
Also, my libasound.so is symbol linked into libasound.so.2.0.0 if that clears anything up. (Hope that double slashed path at the end is correct also).
/usr/bin/ld: /usr/lib/ffmpeg/libavdevice.a(alsa.o): undefined reference to symbol 'snd_pcm_hw_params_any##ALSA_0.9' //usr/lib/x86_64-linux-gnu/libasound.so.2:
So the problem was indeed a version mixup of avcodec and ffmpeg sources, where I would be linking to the right library but compiled against the wrong source package. I found out by following Andrew's suggestion to check the API versions in the header.
The solution was, as halfelf suggested, to uninstall both ffmpeg and avcodec and then manually download the source trunk from the latest repository version of ffmpeg, and build from source. This is quite a process, but it all worked out and resolved the linking issue.
Hi I have a problem with getting ffmpeg libraries to build in my Xcode project. It is in C++ . I have installed it using homebrew and have checked that all the correct libraries have installed via terminal. I have tried with and without extern C as I know it is a c library.
#include <iostream>
#include <opencv2/opencv.hpp>
#include <libavformat>
//extern "C" {
// #include <libavformat>
//}
The linker flags have been set by using (e.g. pkg-config --libs libavcodec) in terminal and these flags do not throw up an error when building. The header files are also found with no problems as the autocomplete flags them top while typing.
Please see attached pictures for Xcode build settings. Really stuck pease help
I identified the problem as being related to the path that the include statement relates to. The header files were one down in the hierarchy from the folders so:
#include <libavformat>
produces an error that the library was not found. The change below sorted the problem out.
#include <libavformat/avformat.h>
I have an OpenGL file called wglew.h which I downloaded from http://glew.sourceforge.net/. Using the wglew.h as I downloaded it, I receive the following error when compiling a program that I have (I am using MacOSX):
/Users/Downloads/glew-1.11.0/include/GL/wglew.h:70:10: fatal error:'windows.h' file not found
I am trying to go back into the source code of that file and change its dependency from windows.h to something that my Mac could recognize. The source code snippet in the wglew.h file is:
#if !defined(WINAPI)
# ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN 1
# endif
#include <windows.h>
# undef WIN32_LEAN_AND_MEAN
#endif
Is it possible to work around this windows.h dependency so that my program does not error out at this step? I asked a similar, but not identical question about a parallel concept at: Where can I get windows.h for Mac? Perhaps instead of looking for an equivalent windows.h file (if such exists for the Mac), I can try to devise a more subtle approach of changing the source code within the wglew.h file to get my program to work and accommodate the windows dependency that I am experiencing?
Here we go again: GLEW is not part of OpenGL. It's a third party library.
You don't need GLEW on MacOS X !
You're barking up the wrong tree!
Instead of trying to fix GLEW (which you don't have to). Just fix your program to not use GLEW when being compiled for MacOS X.
Everywhere in your program where you find a
#include <glew.h>
or
#include <GL/glew.h>
Change it into
#ifndef __APPLE__
#include <GL/glew.h>
#else
#include <OpenGL/gl.h>
#endif/*__APPLE__*/
Put any occurance where a GLEW function is called between a
#ifndef __APPLE__
…
#endif/*__APPLE__*/
block as well.
You don't need GLEW on MacOS X ! Don't use it there.
I don't know where is the function savePolygonFileSTL in pcl 1.6. Which file do I have to include?
Here it says that it is part of
#include <pcl/pcl_config.h>
#include <boost/cstdint.hpp>
#include <cstdlib>
#include <iostream>
#include <stdarg.h>
#include <stdio.h>
#include <math.h>
Anyway VS2010 doesn't find it, and also with manually search I didn't find the definition of that function in all pcl 1.6 folders. Neither savePolygonFile exists or similar.
How is it possible? There is something that I don't know? Please help me.
Thanks a lot
As mentioned in this tutorial, you could try to include the following include at the top of your code:
#include <pcl/io/pcd_io.h>
Update: by looking at the PCL 1.6 source code here, it looks like the savePolygonFileSTL function is defined in the vtk_lib_io.h header. Try to include it adding this line to your code:
#include <pcl/io/vtk_lib_io.h>
Please be sure to have a VTK enabled PCL build.