Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On 25 Sep, Matt Smith wrote: > On Sep 25 01:00, Don Lewis wrote: >>On 25 Sep, Matt Smith wrote: >>> On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > > Try dropping the attached patch in net/mediatomb/files. I > > > submitted it in March, in PR198436: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > > > Eh, now with an actual patch. :) > > Thanks, helps to build it. Still fails on 9.3a, but I *have* to go > to bed now. It's done. >>> >>> This seems to create a run time dependency on GCC. Should it not >>> just be a build time dependency which allows you to uninstall GCC >>> afterwards? >> >>If the executable(s) link to any of the shared libraries bundled with >>the gcc port, then gcc needs to be a run time dependency. If you >>point ldd at one of the executables, what does it say? >> > > Good point. I remember now that some things like against libgcc > provided with the GCC package. If this is the case then I apologise > for the noise and feel free to ignore me! Unfortunately I don't > currently have access to the box where I compiled it using GCC last > night using the updated port. I only have access to another box where > it was compiled using clang (on -STABLE). This shows the below. So I > can see that it is linked against libgcc, although in this case the > base system version. > > $ ldd `which mediatomb` > /usr/local/bin/mediatomb: > libthr.so.3 => /lib/libthr.so.3 (0x80094b000) > librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000) > libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000) > libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000) > libz.so.6 => /lib/libz.so.6 (0x801248000) > libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000) > libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) > libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 > (0x801a86000) > libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000) Since this is a c++ thing, you'll probably find that the version compiled with gcc from ports is linked to libstdc++ bundled with the ports version of gcc. BTW, if it gets linked to both libstdc++ and libc++, it will blow up at runtime. If this ports links to other libraries that contain c++ code built with clang, then USES=compiler:gcc-c++11-lib won't work because the two c++ implementations don't play well together. > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218) > libm.so.5 => /lib/libm.so.5 (0x80239c000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000) > libc.so.7 => /lib/libc.so.7 (0x8027d3000) > libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0) > libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000) > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420) > libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000) > libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000) > libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000) > libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000) > libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8) > libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000) > libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000) > libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 01:00, Don Lewis wrote: On 25 Sep, Matt Smith wrote: On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? If the executable(s) link to any of the shared libraries bundled with the gcc port, then gcc needs to be a run time dependency. If you point ldd at one of the executables, what does it say? Good point. I remember now that some things like against libgcc provided with the GCC package. If this is the case then I apologise for the noise and feel free to ignore me! Unfortunately I don't currently have access to the box where I compiled it using GCC last night using the updated port. I only have access to another box where it was compiled using clang (on -STABLE). This shows the below. So I can see that it is linked against libgcc, although in this case the base system version. $ ldd `which mediatomb` /usr/local/bin/mediatomb: libthr.so.3 => /lib/libthr.so.3 (0x80094b000) librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000) libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000) libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000) libz.so.6 => /lib/libz.so.6 (0x801248000) libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000) libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 (0x801a86000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218) libm.so.5 => /lib/libm.so.5 (0x80239c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000) libc.so.7 => /lib/libc.so.7 (0x8027d3000) libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000) libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000) libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000) libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8) libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000) libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000) libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000) -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On 25 Sep, Matt Smith wrote: > On Sep 24 21:52, Kurt Jaeger wrote: >>Hi! >> >>> > > Try dropping the attached patch in net/mediatomb/files. I submitted it >>> > > in March, in PR198436: >>> > > >>> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 >>> > >>> > Eh, now with an actual patch. :) >>> >>> Thanks, helps to build it. Still fails on 9.3a, but I *have* to go >>> to bed now. >> >>It's done. >> > > This seems to create a run time dependency on GCC. Should it not just be > a build time dependency which allows you to uninstall GCC afterwards? If the executable(s) link to any of the shared libraries bundled with the gcc port, then gcc needs to be a run time dependency. If you point ldd at one of the executables, what does it say? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 09:18, Kurt Jaeger wrote: Hi! >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can you suggest a patch ? Unfortunately not I'm afraid. I'm not familiar enough with the newer intricacies of the ports system these days. I'm just a little OCD about only having ports installed which are needed for runtime and I usually run pkg_clean after every port update run to remove unneeded things. GCC just popped out as being unneeded to run mediatomb. -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
Hi! > >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > This seems to create a run time dependency on GCC. Should it not just be > a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can you suggest a patch ? -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
Hi! > > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > > in March, in PR198436: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > > > Eh, now with an actual patch. :) > > Thanks, helps to build it. Still fails on 9.3a, but I *have* to go > to bed now. It's done. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Wed, Sep 23, 2015 at 1:39 PM, Kurt Jaeger wrote: > Hi! > > > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > > in March, in PR198436: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > > > Eh, now with an actual patch. :) > > Thanks, helps to build it. Still fails on 9.3a, but I *have* to go > to bed now. > > -- > p...@opsec.eu+49 171 3101372 5 years to > go ! > Hmm. Looks like something is going wrong with Mk/Uses/iconv. The failing test for iconv builds without -liconv. Now it's time for me to get some sleep. Here is the relevant section of the log: configure:8520: checking iconv.h usability configure:8537: cc -c -O2 -pipe -fstack-protector -fno-strict-aliasing -I/usr/local/include conftest.c >&5 configure:8544: $? = 0 configure:8558: result: yes configure:8562: checking iconv.h presence configure:8577: cpp -I/usr/local/include conftest.c configure:8584: $? = 0 configure:8598: result: yes configure:8631: checking for iconv.h configure:8638: result: yes configure:9290: checking for iconv configure:9346: cc -o conftest -O2 -pipe -fstack-protector -fno-strict-aliasing -I/usr/local/include -lpthread -fstack-protector conftest.c >&5 /tmp/ccLEMR46.o: In function `main': conftest.c:(.text+0x7): undefined reference to `iconv' configure:9353: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "MediaTomb" | #define PACKAGE_TARNAME "mediatomb" | #define PACKAGE_VERSION "0.12.1" | #define PACKAGE_STRING "MediaTomb 0.12.1" | #define PACKAGE_BUGREPORT "j...@mediatomb.cc" #define PACKAGE "mediatomb" | #define VERSION "0.12.1" | #define EXTEND_PROTOCOLINFO 1 | #define UPNP_VERSION_STRING "0.12.1" | #define UPNP_VERSION_MAJOR 0 | #define UPNP_VERSION_MINOR 4 | #define UPNP_VERSION_PATCH 1 | #define HAVE_DIRENT_H 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE__BOOL 1 | #define HAVE_STDBOOL_H 1 | #define TIME_WITH_SYS_TIME 1 | #define HAVE_TIME_H 1 | #define HAVE_SYSLOG_H 1 | #define HAVE_STDDEF_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_NETDB_H 1 | #define HAVE_NETINET_IN_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_IOCTL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_LOCALE_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SCHED_H 1 | #define HAVE_CTYPE_H 1 | #define HAVE_SCHED_GETPARAM 1 | #define HAVE_SCHED_SETPARAM 1 | #define HAVE_SCHED_GET_PRIORITY_MIN 1 | #define HAVE_SCHED_GET_PRIORITY_MAX 1 | #define HAVE_MKDIR 1 | #define HAVE_GETOPT_H 1 | #define HAVE_GETOPT_LONG 1 | #define HAVE_MKFIFO 1 | #define EXTERNAL_TRANSCODING 1 | /* end confdefs.h. */ | /* Define iconv to an innocuous variant, in case declares iconv. |For example, HP-UX 11i declares gettimeofday. */ | #define iconv innocuous_iconv | | /* System header to define __stub macros and hopefully few prototypes, | which can conflict with char iconv (); below. | Prefer to if __STDC__ is defined, since | exists even on freestanding compilers. */ | | #ifdef __STDC__ | # include | #else | # include | #endif | | #undef iconv | | /* Override any GCC internal prototype to avoid an error. |Use char because int might match the return type of a GCC |builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char iconv (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined __stub_iconv || defined __stub___iconv | choke me | #endif | | int | main () | { | return iconv (); | ; | return 0; | } configure:9373: result: no -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On 23 Sep 2015, at 17:38, Kevin Oberman wrote: > > met/mediatomb fails to compile with clang++36. Works fine with gcc++ and > older versions of clang++. Try dropping the attached patch in net/mediatomb/files. I submitted it in March, in PR198436: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 but it did not get applied, because it apparently caused a build failure on 8.4 (for which the log is not available anymore, so no idea what the problem was). -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On 23 Sep 2015, at 21:57, Dimitry Andric wrote: > On 23 Sep 2015, at 17:38, Kevin Oberman wrote: >> >> met/mediatomb fails to compile with clang++36. Works fine with gcc++ and >> older versions of clang++. > > Try dropping the attached patch in net/mediatomb/files. I submitted it > in March, in PR198436: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 Eh, now with an actual patch. :) -Dimitry patch-timer.cc Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Port compilation fails on HEAD. works on 9 and 10 STABLE
met/mediatomb fails to compile with clang++36. Works fine with gcc++ and older versions of clang++. /usr/local/bin/clang++36 -DHAVE_CONFIG_H -I. -I.. -I../tombupnp/upnp/inc -I/usr/local/include -DLIBICONV_PLUG -I../src -I../tombupnp/ixml/inc -I../tombupnp/threadutil/inc -I../tombupnp/upnp/inc -I.. -I/usr/local/include-I/usr/local/include -I/usr/local/include/taglib -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -DLIBICONV_PLUG -MT libmediatomb_a-timer.o -MD -MP -MF .deps/libmediatomb_a-timer.Tpo -c -o libmediatomb_a-timer.o `test -f '../src/timer.cc' || echo './'`../src/timer.cc ../src/timer.cc:40:1: error: explicit specialization of 'mutex' after instantiation SINGLETON_MUTEX(Timer, true); ^ ../src/singleton.h:112:89: note: expanded from macro 'SINGLETON_MUTEX' ...recursive) template <> zmm::Ref Singleton::mutex = zmm::Re... ^ ../src/timer.h:82:18: note: implicit instantiation first required here AUTOLOCK(mutex); ^ ../src/sync.h:40:66: note: expanded from macro 'AUTOLOCK' #define AUTOLOCK(mutex) zmm::Ref mutex_autolock = mutex->... ^ 1 error generated. The macro in question is: #define SINGLETON_MUTEX(klass, recursive) template <> zmm::Ref Singleton::mutex = zmm::Ref(new Mutex(recursive)) //template zmm::Ref Singleton::mutex = zmm::Ref(new Mutex()); template zmm::Ref Singleton::instance = nil; template bool Singleton::singletonActive = true; Is this a problem with the code or the compiler? If it is the code, any suggestions on fixing it? I have no clue about C++, but I'd really like to get this working on HEAD. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"