Sun 09 Nov 2008 05:26:36 PM UTC, comment #27:
It works now (tried rev 10253), thanks!
|
Sat 08 Nov 2008 06:21:26 PM UTC, comment #26:
Re-added AM_LDFLAGS, see if it works now please 10249.
|
Sat 08 Nov 2008 03:04:31 PM UTC, comment #25:
The bug was reintroduced (doesn't exist in 0.8.4, but exists in 10051 snapshot). Here's the diff:
--- gnash-0.8.4/utilities/Makefile.am 2008-10-12 17:03:32.000000000 +0400
+++ gnash-trunk/utilities/Makefile.am 2008-10-15 23:01:06.000000000 +0400
@@ -63,7 +63,7 @@
$(NULL)
if WIN32
- GNASH_LIBS += -lintl -lz -lws2_32
+ GNASH_LIBS += -lintl -lz -lws2_32
endif
if USE_FFMPEG_ENGINE
@@ -82,11 +82,9 @@
#check_PROGRAMS = gdebug.swf
gprocessor_SOURCES = processor.cpp
-gprocessor_CPPFLAGS = $(AM_CPPFLAGS)
# export our symbols so they can be used by Gnash plugins
-gprocessor_LDFLAGS = -export-dynamic $(AM_LDFLAGS)
+gprocessor_LDFLAGS = -export-dynamic
gprocessor_LDADD = $(GNASH_LIBS)
-#gprocessor_DEPENDENCIES =
dumpshm_SOURCES = dumpshm.cpp
dumpshm_LDADD = $(GNASH_LIBS)
|
Wed 11 Jun 2008 08:13:41 PM UTC, comment #24:
Backported. Thanks.
|
Wed 11 Jun 2008 07:38:21 PM UTC, comment #23:
Tested this
- gprocessor_LDFLAGS = -export-dynamic $(LIBLTDL)
+ gprocessor_LDFLAGS = -export-dynamic $(AM_LDFLAGS)
on 20080609 snapshot (sorry, had no time to bother with CVS), builds without problems in all configurations.
Yes, this needs to be backported to 0.8.3 branch as it was 0.8.3-rc3 which failed in the first place.
I'll start testing rc3 with the patch to be sure.
|
Wed 11 Jun 2008 12:11:49 PM UTC, comment #22:
Ready for test in head, please also test gnash-0.8.3-rc3
as it may need the same trheatment.
|
Wed 11 Jun 2008 12:08:07 PM UTC, comment #21:
What about adding AM_LDFLAGS to the custom LDFLAGS ?
Like:
- gprocessor_LDFLAGS = -export-dynamic $(LIBLTDL)
+ gprocessor_LDFLAGS = -export-dynamic $(AM_LDFLAGS)
Could you try that please ?
Does anyone see a problem with it?
|
Wed 11 Jun 2008 05:45:00 AM UTC, comment #20:
Sorry to report this again, but the problem still persists.
Now it only affects gprocessor, because it uses custom LDFLAGS, and LIBINTL which was added to AM_LDFLAGS last time doesn't get into linking.
Patch is attached, I'm testing it now with almost all possible knob configurations.
(file #15827)
|
Wed 21 May 2008 04:10:09 PM UTC, comment #19:
I've tested both HEAD and 0.8.3 branch, no more problems. Thanks, now it's really fixed.
|
Wed 21 May 2008 06:50:04 AM UTC, comment #18:
libbase/Makefile.am uses LIBINTL. Since both LIBINTL and INTLLIB are defined for you I used the former, to be consistent
(I think we should drop the latter, modifying macro/gettext.m4
to handle the case in which only one would be defined [if any]).
Committed in both 0.8.3 and head branches.
Tests welcome (more important in the 0.8.3 branch..)
|
Tue 20 May 2008 08:08:07 PM UTC, comment #17:
> You should touch Makefile.am, not Makefile.in
I know, that was just a quick fix for the FreeBSD port, posted here jfyi.
% gmake dumpconfig | grep INTL
INTLLIBS is /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib
LIBINTL is /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib
It's same as before - no problem with libs detection, they're just not included into the list of libraries for utilities/ and cygnal/.
The attached path fixes the problem, it's proper patch for Makefiles.am.
(file #15685)
|
Fri 16 May 2008 07:40:53 AM UTC, comment #16:
I committed that patch in head, please update, run ./autogen.sh,
./configure again and then run 'make dumpconfig | grep INTL'
reporting results here.
|
Fri 16 May 2008 07:31:00 AM UTC, comment #15:
You should touch Makefile.am, not Makefile.in.
Please, have 'make dumpconfig' print both INTLLIBS and LIBINTL
as it seem we have both:
--- Makefile.am 1 May 2008 16:30:18 -0000 1.111
+++ Makefile.am 16 May 2008 07:26:42 -0000
@@ -207,6 +207,8 @@
@echo " FREETYPE_LIBS is $(FREETYPE2_LIBS)"
@echo " FONTCONFIG_CFLAGS is $(FONTCONFIG_CFLAGS)"
@echo " FONTCONFIG_LIBS is $(FONTCONFIG_LIBS)"
+ @echo " INTLLIBS is $(INTLLIBS)"
+ @echo " LIBINTL is $(LIBINTL)"
The above patch for top-level Makefile.am.
|
Fri 16 May 2008 12:43:27 AM UTC, comment #14:
Same thing. Generated Makefile is attached.
I just fix that by adding ${INTLLIBS} to GNASH_LIBS in Makefile.in
(file #15668, file #15669)
|
Thu 15 May 2008 03:39:00 PM UTC, comment #13:
could you please try gnash CVS ?
|
Thu 15 May 2008 03:27:43 PM UTC, comment #12:
Sorry for long delay. At last I got my hands on 0.8.2 and I'm finishing updating the port now.
Unfortunately, intl problem was not fixed, INTLLIBS stil doesn't get into gcc arguments for utilities when building KDE gnash only (i.e. without GTK).
/usr/local/libexec/ccache/c++ -O2 -fno-strict-aliasing -pipe -march=nocona -pthread -D_THREAD_SAFE -pthread -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -fvisibility-inlines-hidden -Wl,--as-needed -o .libs/gprocessor gprocessor-processor.o -Wl,--export-dynamic -L/usr/local/lib ../server/.libs/libgnashserver.so /pool/shared/ports/gnash/work/gnash-0.8.2/libamf/.libs/libgnashamf.so /pool/shared/ports/gnash/work/gnash-0.8.2/libmedia/.libs/libgnashmedia.so /usr/local/lib/libxml2.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libexpat.so ../libamf/.libs/libgnashamf.so /pool/shared/ports/gnash/work/gnash-0.8.2/libbase/.libs/libgnashbase.so ../libbase/.libs/libgnashbase.so ../libmedia/.libs/libgnashmedia.so /usr/local/lib/libjpeg.so /usr/local/lib/libcurl.so /usr/local/lib/libltdl.so -lboost_thread -lboost_date_time -lpthread /usr/local/lib/libSDL.so /usr/local/lib/libiconv.so -lusbhid -pthread -lavformat -lavcodec -lz -lx264 -lxvidcore /usr/local/lib/libvorbisenc.so -lavutil /usr/local/lib/libvorbis.so /usr/local/lib/libogg.so -lrt /usr/local/lib/libXi.so /usr/local/lib/libXext.so /usr/local/lib/libX11.so /usr/local/lib/libXdmcp.so -lrpcsvc /usr/local/lib/libXau.so -lm -Wl,--rpath -Wl,/pool/shared/ports/gnash/prefix/lib/gnash -Wl,--rpath -Wl,/usr/local/lib
gprocessor-processor.o(.text+0x82): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0x8f): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0x9c): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0xa9): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0xb6): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0x156): more undefined references to `libintl_gettext' follow
gprocessor-processor.o(.text+0xc5c): In function `main':
: undefined reference to `libintl_bindtextdomain'
gprocessor-processor.o(.text+0xc66): In function `main':
: undefined reference to `libintl_textdomain'
gprocessor-processor.o(.text+0xd6e): In function `main':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0xe4a): In function `main':
: undefined reference to `libintl_gettext'
gprocessor-processor.o(.text+0xe86): In function `main':
: undefined reference to `libintl_gettext'
gmake[2]: *** [gprocessor] Error 1
gmake[2]: Leaving directory `/pool/shared/ports/gnash/work/gnash-0.8.2/utilities'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/pool/shared/ports/gnash/work/gnash-0.8.2'
gmake: *** [all] Error 2
|
Mon 25 Feb 2008 04:26:41 PM UTC, comment #11:
works for me too, since the original reporter doesn't followup I'd consider this fixed.
|
Sun 17 Feb 2008 04:42:51 PM UTC, comment #10:
After recent checkins, I can build Gnash cvs HEAD on FreeBSD, NetBSD, and OpenBSD, with zero problems. Please try now to see if it works for you too.
|
Mon 11 Feb 2008 05:19:11 PM UTC, comment #9:
I didn't think anyone would be interested in building
with no gui, it's just a nogo in the configure.ac script
if you really think it's worth it...
Anyway, apart from the value of INTLLIBS, which doesn't
sound completely fine to me (but I may be wrong)
I do see AM_LDFLAGS added to CXXLINK:
CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
and I see CXXLINK used in linking line for dumpshm and
soldumper, but I confirm it's not in the gprocessor line:
dumpshm$(EXEEXT): $(dumpshm_OBJECTS) $(dumpshm_DEPENDENCIES)
@rm -f dumpshm$(EXEEXT)
$(CXXLINK) $(dumpshm_OBJECTS) $(dumpshm_LDADD) $(LIBS)
gprocessor$(EXEEXT): $(gprocessor_OBJECTS) $(gprocessor_DEPENDENCIES)
@rm -f gprocessor$(EXEEXT)
$(gprocessor_LINK) $(gprocessor_OBJECTS) $(gprocessor_LDADD) $(LIBS)
soldumper$(EXEEXT): $(soldumper_OBJECTS) $(soldumper_DEPENDENCIES)
@rm -f soldumper$(EXEEXT)
$(CXXLINK) $(soldumper_OBJECTS) $(soldumper_LDADD) $(LIBS)
Might be due to one of the following two lines in the
Makefile.am, which are not specified for dumpshm and soldumper:
gprocessor_LDFLAGS = -export-dynamic $(LIBLTDL)
gprocessor_LDADD = $(GNASH_LIBS)
Rob, what are them needed for ? Should we add AM_LDFLAGS to
_LDADD or _LDFLAGS ?
|
Mon 11 Feb 2008 04:57:25 PM UTC, comment #8:
Erm, sorry, actually I was trying the patch on 0.8.1. Now I've checked out CVS head, but it doesn't seem that anything changed (i.e. INTLLIBS won't get into linking gprocessor), though I cannot confirm that yet, as many configure options have changed (for instance, if seems like it won't build without GUIs at all, so I need to install kdelibs to test the issue). Here's related Makefiles and result of `make dumpconfig` (from HEAD), if you're interested: http://www.amdmi3.ru/gnash.tar.bz2
|
Mon 11 Feb 2008 07:26:07 AM UTC, comment #7:
I try as well, intllibs.patch.
Also adds an INTLLIB dump on 'make dumpconfig', please
check that as well.
For me, gprocessor does use AM_LDFLAGS (checked for CURL_LIBS
for instance). Make sure you run ./autogen.sh and configure again.
(file #15020)
|
Mon 11 Feb 2008 04:01:45 AM UTC, comment #6:
sigh. Well, obviously, I'm not a build system person. I'd like to punt this off to rsavoye...
|
Mon 11 Feb 2008 03:52:10 AM UTC, comment #5:
Erm...nope. First of all, I don't think you want to add libs to CPPFLAGS. You probably meant adding $(INTLLIBS) to AM_LDFLAGS, but that won't help as well, as AM_LDFLAGS are not used when linking gparser/gprocessor.
From Makefile generated here:
gparser:
$(gparser_LINK) $(gparser_OBJECTS) $(gparser_LDADD) $(LIBS)
gparser_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) (LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(gparser_LDFLAGS) $(LDFLAGS) -o $
gparser_LDADD = $(GNASH_LIBS)
I don't really get logic of all this stuff, but in my case build is fixed by adding INTLLIBS to either GNASH_LIBS or {gparser,gprocessor,dumpshm}_LDADD in utilities/Makefile.am.
|
Mon 11 Feb 2008 01:58:56 AM UTC, comment #4:
Ah, I seem to recall that the BSD linker wants all the dependencies linked in the final link stage. How about this patch?
(file #15015)
|
Sun 10 Feb 2008 04:03:29 PM UTC, comment #3:
Doesn't help. libintl should be actually linked with binary, so changes to libbase makefile doesn't seem to change anything.
|
Sun 10 Feb 2008 02:02:40 PM UTC, comment #2:
Would you be so kind to test this patch?
(file #15010)
|
Wed 07 Nov 2007 07:12:26 PM UTC, comment #1:
I confirm there's no INTLLIB match in configure.ac nor in any Makefile.am, while it's set by macros/gettext.m4
|
Wed 07 Nov 2007 05:59:24 PM UTC, original submission:
On FreeBSD, when GTK GUI is not used (that is, when building with KDE or without any GUIs), Gnash won't build as libintl.so does not get linked.
1) Actually, configure DOES correctly identify INTLLIBS:
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib
2) But, Gnash does not use INTLLIBS anywhere:
% cd gnash-0.8.1
% find . -name Makefile.in | xargs grep INTLLIBS | grep -v "INTLLIBS = @INTLLIBS@"
%
3) Thus, the build fail:
---
c++ -O2 -fno-strict-aliasing -pipe -march=nocona -D_THREAD_SAFE -pthread -W -Wall -Wcast-align -Wcast-qual -Wpointer-arith -Wreturn-type -Wl,--as-needed -o .libs/gparser parser.o -pthread -pthread -pthread -Wl,--export-dynamic -L/usr/local/lib ../server/.libs/libgnashserver.so -L/usr/lib32 ../libbase/.libs/libgnashbase.so ../backend/.libs/libgnashbackend.so /usr/home/amdmi3/gnash/work/gnash-0.8.1/server/.libs/libgnashserver.so /usr/home/amdmi3/gnash/work/gnash-0.8.1/libamf/.libs/libgnashamf.so /usr/home/amdmi3/gnash/work/gnash-0.8.1/libgeometry/.libs/libgnashgeo.so /usr/local/lib/libxml2.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libexpat.so /usr/local/lib/libSDL.so /usr/local/lib/libiconv.so /usr/local/lib/libaa.so -lncurses /usr/local/lib/libX11.so /usr/local/lib/libXau.so /usr/local/lib/libXdmcp.so -lrpcsvc -lusbhid ../libamf/.libs/libgnashamf.so /usr/home/amdmi3/gnash/work/gnash-0.8.1/libbase/.libs/libgnashbase.so /usr/local/lib/libjpeg.so /usr/local/lib/libcurl.so -lssl -lcrypto /usr/local/lib/libltdl.so -lboost_date_time -lboost_thread -lavformat -lavcodec -lz /usr/local/lib/libfaad.so -pthread /usr/local/lib/libmp3lame.so -lx264 -lxvidcore /usr/local/lib/libtheora.so /usr/local/lib/libvorbisenc.so -lavutil /usr/local/lib/libvorbis.so /usr/local/lib/libogg.so -lrt -lm -Wl,--rpath -Wl,/usr/home/amdmi3/gnash/prefix/lib/gnash -Wl,--rpath -Wl,/usr/local/lib
parser.o(.text+0xda): In function `usage(char const*)':
: undefined reference to `libintl_gettext'
parser.o(.text+0x3b2): In function `parser::parse_end_movie(gnash::stream*, int)':
: undefined reference to `libintl_gettext'
parser.o(.text+0x5fa): In function `parser::parse_set_background_color(gnash::stream*, int)':
: undefined reference to `libintl_gettext'
parser.o(.text+0xa01): In function `parser::parse_swf(std::auto_ptr<tu_file>)':
: undefined reference to `libintl_gettext'
parser.o(.text+0xa53): In function `parser::parse_swf(std::auto_ptr<tu_file>)':
: undefined reference to `libintl_gettext'
parser.o(.text+0xc23): In function `main':
: undefined reference to `libintl_bindtextdomain'
parser.o(.text+0xc2d): In function `main':
: undefined reference to `libintl_textdomain'
parser.o(.text+0xd16): In function `main':
: undefined reference to `libintl_gettext'
parser.o(.text+0xd5f): In function `main':
: undefined reference to `libintl_gettext'
parser.o(.text+0xdfd): In function `main':
: undefined reference to `libintl_gettext'
parser.o(.text+0xec9): In function `main':
: undefined reference to `libintl_gettext'
parser.o(.text+0xef8): In function `main':
: undefined reference to `libintl_gettext'
parser.o(.text+0x11f7): more undefined references to `libintl_gettext' follow
---
In case of GTK, libintl gets linked automatically with other libs libgtk is dependent on.
The patch attached fixes the problem for me, but proper fix would be adding INTLLIBS to AM_LDFLAGS in utilities/Makefile.am (maybe even everywhere where libintl may be potentially used, but for now the problem only appears in utilities/). Please feel free to ask for any additional feedback/testing: -unavailable-
|