Summary: | www-misc/zoneminder-1.24.2 fails to build with ffmpeg-0.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Shawn Rutledge <s> |
Component: | [OLD] Server | Assignee: | Andreas K. Hüttel <dilfridge> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christophe_y2k, erict, root, tanderson |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | [dilfridge overlay] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 359605 | ||
Bug Blocks: | 324255 | ||
Attachments: |
updated ebuild appending CXXFLAG(S)
re-updated ebuild |
Description
Shawn Rutledge
2010-05-17 01:30:37 UTC
There is a lame excuse for this bug though: http://www.zoneminder.com/wiki/index.php/FAQ#I_cannot_build_ZoneMinder_and_am_getting_lots_of_undefined_C.2B.2B_template_errors After turning off ccache, I get different errors: In file included from zm_local_camera.cpp:20: zm_local_camera.h:96: error: ‘PixelFormat’ does not name a type zm_local_camera.h:97: error: ‘PixelFormat’ does not name a type zm_local_camera.h:98: error: ISO C++ forbids declaration of ‘AVFrame’ with no type zm_local_camera.h:98: error: expected ‘;’ before ‘*’ token (etc) So the next couple of problems are fixed by adding this in zm_local_camera.h: #if HAVE_LIBSWSCALE #include <libswscale/swscale.h> #endif #include <libavcodec/avcodec.h> (I'm sure the avcodec needs to be #if'd as well) And then we have collect: relinking zm_local_camera.o: In function `LocalCamera::Capture(Image&)': zm_local_camera.cpp:(.text+0x1c1b): undefined reference to `sws_scale(SwsContext*, unsigned char const* const*, int const*, int, int, unsigned char* const*, int const*)' zm_local_camera.cpp:(.text+0x20b1): undefined reference to `sws_getContext(int, int, PixelFormat, int, int, PixelFormat, int, SwsFilter*, SwsFilter*, double const*)' zm_local_camera.cpp:(.text+0x20c6): undefined reference to `avcodec_alloc_frame()' zm_local_camera.cpp:(.text+0x20e4): undefined reference to `avpicture_get_size(PixelFormat, int, int)' zm_local_camera.cpp:(.text+0x20eb): undefined reference to `av_malloc(unsigned int)' zm_local_camera.cpp:(.text+0x210c): undefined reference to `avpicture_fill(AVPicture*, unsigned char*, PixelFormat, int, int)' zm_local_camera.o: In function `LocalCamera::Initialise()': zm_local_camera.cpp:(.text+0x465a): undefined reference to `av_log_set_level(int)' zm_local_camera.cpp:(.text+0x4c1b): undefined reference to `avpicture_fill(AVPicture*, unsigned char*, PixelFormat, int, int)' zm_local_camera.cpp:(.text+0x4c70): undefined reference to `avcodec_alloc_frame()' zm_local_camera.cpp:(.text+0x4fc8): undefined reference to `avcodec_alloc_frame()' zm_local_camera.cpp:(.text+0x4ffd): undefined reference to `avpicture_fill(AVPicture*, unsigned char*, PixelFormat, int, int)' zm_local_camera.cpp:(.text+0x511f): undefined reference to `av_log_set_level(int)' collect2: ld returned 1 exit status because they didn't add -lavutil -lavcodec... basically the autoconf seems to be broken. BTW is there a way to disable ccache for specific packages? That might be a good feature for a future portage, if not. OK needs to be more like this in zm_local_camera.h: #if HAVE_LIBSWSCALE #ifdef __cplusplus extern "C" { #include <libswscale/swscale.h> #include <libavcodec/avcodec.h> } #endif #endif I was able to build it finally. (In reply to comment #3) > BTW is there a way to disable ccache for specific packages? Per the ccache man page: ENVIRONMENT VARIABLES CCACHE_DISABLE If you set the environment variable CCACHE_DISABLE then ccache will just call the real compiler, bypassing the cache com- pletely. Thus, you could export CCACHE_DISABLE=1 before the relevant stage(s) of compilation for the affected package. It should be harmless if ccache is not actually present on the system. After reading the URL cited in comment #1, I am curious what exactly ZoneMinder did to break their package. In theory, ccache should never disrupt a build like this, so it is likely that they found an option combination that confuses it into producing an object file without updating one or more secondary files. If this is so, it would be worthwhile to patch ccache so that it automatically bypasses in such scenarios. Extending it to handle those options correctly would be even better, but applying an automatic bypass based on command line options should be a quick and easy fix, and will allow it to resume caching if upstream changes to options that do not produce bad output. Found Solution: You need to add CXXFLAGS=-D__STDC_CONSTANT_MACROS to the build for zoneminder to compile with ffpmeg-0.6 The easest way to to create the file: /etc/portage/env/www-misc/zoneminder and paste: CXXFLAGS=-D__STDC_CONSTANT_MACROS Save the file and emerge zoneminder. it will build just fine. (In reply to comment #6) > Found Solution: > You need to add CXXFLAGS=-D__STDC_CONSTANT_MACROS to the build for zoneminder > to compile with ffpmeg-0.6 > The easest way to to create the file: > /etc/portage/env/www-misc/zoneminder > and paste: > CXXFLAGS=-D__STDC_CONSTANT_MACROS > > Save the file and emerge zoneminder. it will build just fine. That wasn't adequate in my case, but maybe you mean along with (some of) the other modifications I mentioned here? >That wasn't adequate in my case, but maybe you mean along with (some of) the
>other modifications I mentioned here?
OK, try creating an env file for ffmpeg and add the same CXFLAGS statement.
recompile ffmpeg-0.6 and then zoneminder.
I found the CXXFLAG ffmpeg-0.6 issue with a google search. It wasn't clear if the CXXFLAGS had to be on the ffmpeg or the application that was linking to ffmpeg. I had compiled ffmpeg first with the CXXFLAGS setting and recomplied Zoneminder without the setting and Zoneminder failed to compile. I later added the CXXFLAGS setting to zoneminder and it compiled successfully. Try adding the CXXFLAGS settings to both ffmpeg and zoneminder, and let us know if that corrected the problem. Sorry for my assumption that adding CXXFLAGS just to zoneminder corrected the issue.
I can also confirm that applying the fix from comment #6 resolved my issue of compiling zoneminder with ffmpeg-0.6. Thank you! (In reply to comment #8) > >That wasn't adequate in my case, but maybe you mean along with (some of) the > >other modifications I mentioned here? > > OK, try creating an env file for ffmpeg and add the same CXFLAGS statement. > recompile ffmpeg-0.6 and then zoneminder. That also didn't work. ffmpeg built fine but zoneminder didn't. I don't understand why it's working for some people and not others. > > OK, try creating an env file for ffmpeg and add the same CXFLAGS statement.
> > recompile ffmpeg-0.6 and then zoneminder.
> That also didn't work. ffmpeg built fine but zoneminder didn't. I don't
> understand why it's working for some people and not others.
The only other difference I spotted is that your using "march=athlon64" and I have mine set to "march=core2" Perhaps something to do with the compiler optimizations between althon and pentium system.
my /etc/portage/env/www-misc/zoneminder file has to have all three of the following to build: CCACHE_DISABLE=1 CXXFLAGS=-D__STDC_CONSTANT_MACROS ZM_SSL_LIB=openssl the second one is for this issue. the last one is for "error: 'MD5_DIGEST_LENGTH' was not declared in this scope" issue. haven't found a bug report on that one yet. might add it > my /etc/portage/env/www-misc/zoneminder file has to have all three of the > following to build: > > CCACHE_DISABLE=1 > CXXFLAGS=-D__STDC_CONSTANT_MACROS > ZM_SSL_LIB=openssl I tried putting all 3 lines just like that in mine. > The only other difference I spotted is that your using "march=athlon64" and I > have mine set to "march=core2" Perhaps something to do with the compiler > optimizations between althon and pentium system. > CFLAGS="-march=core2 -O2 -pipe -fno-ident -fomit-frame-pointer" ACCEPT_KEYWORDS=~amd64 emerge -av zoneminder ... it still fails with undefined references to a bunch of std:: stuff. Could be that the whole system needs rebuilding with core2, but that's probably a wild goose chase. For purposes of testing the suggestions here, I'm testing this on my usual workstation machine (a core i7 which nevertheless has march=athlon64, for historical reasons), where I don't need zoneminder; the machine I actually run it on is an athlon64 though, so it needs to work there. As I said in comment 4, I got it to build eventually, and the steps I did to get it to build are documented in comments 1-4. So one way to fix it is just a matter of making patches to be included with the ebuild. Another way is to get upstream to fix it. Unless there is some other random thing wrong with my systems, which is the reason it builds on some people's systems and not on either of mine... fyi, my march is "nocona" which, BTW has nothing to do with the amd64 gentoo keyword (In reply to comment #14) > fyi, my march is "nocona" OK > which, BTW has nothing to do with the amd64 gentoo keyword I know, I did that because it's a masked ebuild. Also I tried prepending CFLAGS in front of the emerge command, as you can see, but not sure if that works or not, to actually change the "arch" for one ebuild. Shawn: I been running into numerous problems with Zoneminder on a 64 bit system. See this entry: http://bugs.gentoo.org/show_bug.cgi?id=338400 I also am having issues with shared memory as ZM creates a shm handle as root when ZM_USER is set to apache. The only way I can can get zm to work is if I manually launch /usr/bin/zmc as root. I also tried using MMAP, which does appear to work even though the shm handle is open by root. but does generate frequent errors. I was thinking of building a 32-bit VM and see if the problems with shm go away. If I have sometime this weekend I will give a shot. So my point is that even if you get through the ffmpeg issue you may have the 64-bit issue. (In reply to comment #16) > Shawn: I been running into numerous problems with Zoneminder on a 64 bit > system. See this entry: > http://bugs.gentoo.org/show_bug.cgi?id=338400 just FYI, i'm 64bit and zoneminder _mostly_ works for me. i haven't played with it enough after i've gotten it going again, but i can finally get to the webserver. i can't presently see any video, but i'm not sure yet if that's ZM's fault or not. (In reply to comment #17) > (In reply to comment #16) > > Shawn: I been running into numerous problems with Zoneminder on a 64 bit > > system. See this entry: > > http://bugs.gentoo.org/show_bug.cgi?id=338400 > just FYI, i'm 64bit and zoneminder _mostly_ works for me. i haven't played > with it enough after i've gotten it going again, but i can finally get to the > webserver. i can't presently see any video, but i'm not sure yet if that's > ZM's fault or not. Thats the problem on 64-bit systems. if you enable debug mode you'll see a bunch of errors trying to communicate over the shm, if you run "ipcs -m" you'll see that the perm is set to root, while the zm instance runs under apache. if you manually run "zmc -m 1" from a shell logged into root you probably will see it start to work. There is another issue wit ZM because of bad varible types bacause the author assumes that long, int, etc remain as 32-bit values instead of 64-bit values on 64-bit machines. This 32/64 mismatch will cause zmc to crash on 64-bit system. if you look at this link, you can manually apply the 64-bit fix patch to zm. http://bugs.gentoo.org/show_bug.cgi?id=338400 I looked through the zm_monitor.cpp code where it creates the shm and there is no code to set the user ID. Perhaps this is automatically assigned using the userID that the process is running. It doesn't appear to work on 64-bit system, at least not my system. FWIW: I am running under linux-2.6.29-xen (64-bit dom0), with zm running on a 64-bit domU kernel. I am going to try running under a 32-bit DomU VM to see if it fixes the issue. http://bugs.gentoo.org/show_bug.cgi?id=338400 (In reply to comment #6) > Found Solution: > You need to add CXXFLAGS=-D__STDC_CONSTANT_MACROS to the build for zoneminder > to compile with ffpmeg-0.6 > The easest way to to create the file: > /etc/portage/env/www-misc/zoneminder > and paste: > CXXFLAGS=-D__STDC_CONSTANT_MACROS > > Save the file and emerge zoneminder. it will build just fine. > Perfect. That did it for me when compiling with ffmpeg support. Thanks. -- emerge info: -- Portage 2.1.8.3 (hardened/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.32-hardened-r9 x86_64) ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-O2 -pipe" FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" I send you a big thank you ! after full gentoo upgrade and perl upgrade
zoneminder wan't to re-emerge and impossible to install until chage the make.conf with your tips !!!
>> Found Solution:
>> You need to add CXXFLAGS=-D__STDC_CONSTANT_MACROS to the build for zoneminder
>> to compile with ffpmeg-0.6
>> The easest way to to create the file:
>> /etc/portage/env/www-misc/zoneminder
>> and paste:
>> CXXFLAGS=-D__STDC_CONSTANT_MACROS
Created attachment 266823 [details]
updated ebuild appending CXXFLAG(S)
Tested on ~amd64 with all other requisite patches. Doesn't pass repoman, though neither did the original 1.24.2 ebuild.
Added ebuild that incorporates these changes, so you don't have to go mucking about with per-package env note: as some will have seen, this is unmaintained by upstream, has been for ~2 years, and is marked for removal from portage. Snag your ebuilds and dump in a local overlay while you can, because it looks like this one's going byebye in not too long. Created attachment 266825 [details]
re-updated ebuild
copied wrong revision, sorry about that.
Please see https://bugs.gentoo.org/show_bug.cgi?id=359605 for a working ebuild. Removed from main tree. Reopened for tracking and hopefully zoneminder revival ffmpeg-0.6 is not in the tree anymore |