Opened 18 years ago
Closed 18 years ago
#2230 closed defect (fixed)
mytharchivehelper Makefile needs an additional -L
Reported by: | Owned by: | paulh | |
---|---|---|---|
Priority: | trivial | Milestone: | unknown |
Component: | mytharchive | Version: | |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | no |
Description
g++ -o mytharchivehelper main.o archiveutil.o -L/usr/lib64/ -L/usr/kde/3.3/lib -L/usr/lib/qt3/lib64/ -L/usr/lib64/ -L/usr/local/lib -lmyth-0.19 -lmythtv-0.19 -lmythui-0.19 -lmythfreemheg-0.19 -lmythlivemedia-0.19 -lqt-mt -lGLU -lGL -lXmu -lXext -lX11 -lm -lpthread /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: cannot find -lX11
--
-L/usr/X11R6/lib64/ is missing here for mytharchivehelper on my SUSE 10.1 machine. Every other plugin properly discovers that location. If I edit the mytharchive/mytharchivehelper/Makefile and add that argument, it compiles fine. (latest SVN)
Change History (11)
comment:1 Changed 18 years ago by
comment:2 Changed 18 years ago by
I had two other issues though. The first being that the freemheg lib option was spelled incorrectly. The Makefile produced has -lfreemheg instead of -lmythfreemheg. The second issue is that mythlivemedia is needed in the link stage but not included on the LIBS line. In the end the Makefile needs:
-lmythfreemheg-0.19 -lmythlivemedia-0.19
This is with SVN rev 10939 on a current Gentoo system.
comment:3 follow-up: 4 Changed 18 years ago by
Jason, does adding
LIBS += -L$$QMAKE_LIBDIR_X11
to the bottom of mytharchivehelper.pro fix things?
comment:4 Changed 18 years ago by
Replying to paulh:
Jason, does adding
LIBS += -L$$QMAKE_LIBDIR_X11to the bottom of mytharchivehelper.pro fix things?
It doesn't, but adding:
LIBS += -L/usr/X11R6/lib64
does..
comment:5 Changed 18 years ago by
In the qmake.conf file you are using what is QMAKE_LIBDIR_X11 set to. I would expect it to be set to /usr/X11R6/lib64 for your system but if it was set incorrectly I would have thought the rest of Myth would have problems compiling unless there's some magic in the configure script or in a .pro file somewhere that is adding the correct -L setting.
comment:6 Changed 18 years ago by
/usr/lib/qt3/mkspecs/default/qmake.conf:
QMAKE_LIBDIR_X11 = /usr/X11R6/lib64/
--
This is bizzare. I'll poke around some more later this evening and see if I can track it down.
comment:7 Changed 18 years ago by
OK, I think I got it.
mytharchivehelper.pro is using TEMPLATE = app, so I believe that's giving you a different set of default libs than most of the other plugins. I saw that mythbrowser also uses TEMPLATE = app and as I haven't had trouble compiling that, I looked at how they handle libs.
mythbrowser/mythbrowser/mythbrowser.pro:
LIBS += -lmyth-$$LIBVERSION -lmythui-$$LIBVERSION $$EXTRA_LIBS
So mytharchive/mytharchivehelper/mytharchivehelper.pro:
LIBS += -L$${PREFIX}/lib $$EXTRA_LIBS
and a make clean;qmake mytharchivehelper.pro;make and it now compiles perfectly.
comment:8 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
As of Repository version 11013:
mytharchive does not build against the libs in the src tree, but rather expects a make install to already have been done on the main mythtv src. This makes updating from the repository problematic at best. It is the only plugin to require such. The other plugins will build without the need to have done a make install. This was noticed on the transition from -0.19 libs to -0.20 libs.
g++ -o mytharchivehelper main.o archiveutil.o -L/usr/kde/3.3/lib -L/usr/qt/3/lib -L/usr/X11R6/lib -L/usr/lib -lmyth-0.20 -lmythtv-0.20 -lmythui-0.20 -lmythfreemheg-0.20 -lmythlivemedia-0.20 -lqt-mt -lGLU -lGL -lXmu -lXext -lX11 -lm -lpthread /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lmyth-0.20
comment:10 Changed 18 years ago by
Priority: | minor → trivial |
---|---|
Severity: | medium → low |
Compiling mythplugins before installing mythtv has always been problematic for me, often resulting in version mismatch errors and such. I believe the general consensus is simply: don't.
If this is still an issue, please open in a new ticket.
Thanks, Jason
comment:11 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Confirmed with version repos version 10939. Was about to add another ticket till I saw this.