Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

2015-09-25 Thread Matt Smith 

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

2015-09-25 Thread Kurt Jaeger 
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

2015-09-25 Thread Matt Smith 

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

2015-09-25 Thread Don Lewis 
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

2015-09-25 Thread Matt Smith 

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

2015-09-25 Thread Don Lewis 
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

2015-09-24 Thread Kurt Jaeger 
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

2015-09-23 Thread Dimitry Andric 
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

Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

2015-09-23 Thread Dimitry Andric 
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

2015-09-23 Thread Kurt Jaeger 
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

2015-09-23 Thread Kevin Oberman 
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"