[QAT] r343465: 4x leftovers

[Ports-QAT]

- Stage support
-

  Build ID:  20140209111801-51562
  Job owner: m...@freebsd.org
  Buildtime: 9 minutes
  Enddate:   Sun, 09 Feb 2014 11:27:17 GMT

  Revision:  r343465
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=343465

-

Port:graphics/xli 

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140209111801-51562-273948/xli-1.17.0_13.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140209111801-51562-273949/xli-1.17.0_13.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140209111801-51562-273950/xli-1.17.0_13.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140209111801-51562-273951/xli-1.17.0_13.log


--
Buildarchive URL: 
redports 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

GraphicsMagics13

[Ajtim]

Hi!

There is update of GraphicsMagick13 which I cannot build on FreeBSD 
10.0-RELEASE (amd64) (I didn't have a problem before):

===>  GraphicsMagick13-1.3.19 Cause C++ ABI conflict between clang/libc++ and 
gcc/libstdc++.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/GraphicsMagick13

I have two ports which has dependencies on GM: gimp-gmic-plugin and math/octave.

Thank you.

-- 
Mitja
---
http://www.redbubble.com/people/lumiwa

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

On 02/08/14 18:08, Warren Block wrote:


This may very well come back to bite you in the future,


Well, as I said, this is just a temporary fix for something that, IMVHO, 
shouldn't have broken in the first place.





causing
mysterious failures long after you've forgotten you did it.


I periodically clean /usr/local/lib/compat/pkg, so it shouldn't be long 
before the links and the libraries they are aliasing are both gone.


However, what is different here from what portupgrade usually does (i.e. 
leaving old libraries in that compat dir)?





Running pkg_libchk [-q] after port upgrades has worked well for me.  It
is from sysutils/bsdadminscripts by Dominic Fandrey, and easily detects
applications that are using old libraries and should be rebuilt.  It
worked this time also.


I normally use sysutils/libchk. I never tried pkg_libchk, but I'm 
curious. What is the advantage of one over the other?




 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Bryan Drewery]

> On Feb 9, 2014, at 7:31, Andrea Venturoli  wrote:
> 
>> On 02/08/14 18:08, Warren Block wrote:
>> 
>> This may very well come back to bite you in the future,
> 
> Well, as I said, this is just a temporary fix for something that, IMVHO, 
> shouldn't have broken in the first place.
> 
> 
> 
>> causing
>> mysterious failures long after you've forgotten you did it.
> 
> I periodically clean /usr/local/lib/compat/pkg, so it shouldn't be long 
> before the links and the libraries they are aliasing are both gone.
> 
> However, what is different here from what portupgrade usually does (i.e. 
> leaving old libraries in that compat dir)?
> 

That is a portupgrade feature. Which tool did you use?


> 
> 
>> Running pkg_libchk [-q] after port upgrades has worked well for me.  It
>> is from sysutils/bsdadminscripts by Dominic Fandrey, and easily detects
>> applications that are using old libraries and should be rebuilt.  It
>> worked this time also.
> 
> I normally use sysutils/libchk. I never tried pkg_libchk, but I'm curious. 
> What is the advantage of one over the other?
> 
> 
> 
> bye & Thanks
>av.
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Warren Block]

On Sun, 9 Feb 2014, Andrea Venturoli wrote:


On 02/08/14 18:08, Warren Block wrote:


This may very well come back to bite you in the future,


Well, as I said, this is just a temporary fix for something that, IMVHO, 
shouldn't have broken in the first place.


Well, yes.


causing
mysterious failures long after you've forgotten you did it.


I periodically clean /usr/local/lib/compat/pkg, so it shouldn't be long 
before the links and the libraries they are aliasing are both gone.


However, what is different here from what portupgrade usually does (i.e. 
leaving old libraries in that compat dir)?


Sorry, I had missed that.  No, it should not be as bad in compat/pkg, 
particularly as a temporary thing.  Soft-linking libraries in the main 
shlib directories has come up as a frequent "fix" in the forums, along 
with trying to fix the long-term problems because it is usually 
considered a fix rather than a temporary workaround.



Running pkg_libchk [-q] after port upgrades has worked well for me.  It
is from sysutils/bsdadminscripts by Dominic Fandrey, and easily detects
applications that are using old libraries and should be rebuilt.  It
worked this time also.


I normally use sysutils/libchk. I never tried pkg_libchk, but I'm curious. 
What is the advantage of one over the other?


From memory, the output of pkg_libchk was more useful than that of 

libchk.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

On 02/09/14 14:43, Bryan Drewery wrote:


However, what is different here from what portupgrade usually does (i.e. 
leaving old libraries in that compat dir)?



That is a portupgrade feature.


Yes, I know.




Which tool did you use?


portupgrade.
However, it didn't save old icu libraries.



 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

On 02/09/14 14:51, Warren Block wrote:


 From memory, the output of pkg_libchk was more useful than that of libchk.


Thanks.
I'll give it a try as soon as I can.

 bye
av.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Error build the port devel/glib20

[Mark Knight]

On 09/02/2014 04:51, John Hein wrote:
> Fair enough.
> There aren't many ports using this feature from 341775 (and thus pulling
> in converters/libiconv) on 10.x yet.  If the OP doesn't have one of
> those ports in place, the effects of the note in UPDATING should be in
> force.

In a similar vein to glib20, does anyone have any tips for print/cups-base or 
converters/recode while libiconv in installed for some of the others ports that 
require it?

echo Linking websearch...
Linking websearch...
cc  -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler 
-L/usr/local/lib -Wl,-rpath=/usr/local/lib -Wl,-R/usr/local/lib   -Wall 
-Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector 
-Wno-tautological-compare -o websearch websearch.o libcupscgi.a \
../cups/libcups.a -pthread -lcrypt -lm -lssp_nonshared  -lssl -lcrypto  
\
-lz
../cups/libcups.a(transcode.o): In function `_cupsCharmapFlush':
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:64: undefined 
reference to `libiconv_close'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:70: undefined 
reference to `libiconv_close'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:64: undefined 
reference to `libiconv_close'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:70: undefined 
reference to `libiconv_close'
../cups/libcups.a(transcode.o): In function `cupsCharsetToUTF8':
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:167: undefined 
reference to `libiconv_open'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:168: undefined 
reference to `libiconv_open'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:179: undefined 
reference to `libiconv'
../cups/libcups.a(transcode.o): In function `_cupsCharmapFlush':
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:64: undefined 
reference to `libiconv_close'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:70: undefined 
reference to `libiconv_close'
../cups/libcups.a(transcode.o): In function `cupsUTF8ToCharset':
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:292: undefined 
reference to `libiconv_open'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:293: undefined 
reference to `libiconv_open'
/usr/ports/print/cups-base/work/cups-1.5.4/cups/transcode.c:304: undefined 
reference to `libiconv'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [websearch] Error 1
gmake[3]: Leaving directory `/usr/ports/print/cups-base/work/cups-1.5.4/cgi-bin'
gmake[2]: *** [libs] Error 1
gmake[2]: Leaving directory `/usr/ports/print/cups-base/work/cups-1.5.4'
*** Error code 2

or converters/recode?

--- libiconv.lo ---
/bin/sh /usr/local/bin/libtool --mode=compile cc -DLIBDIR=\"/usr/local/lib\" 
-DHAVE_CONFIG_H -I.. -I. -I../lib -I/usr/local/include  -I/usr/local/include 
-DLIBICONV_PLUG  -O2 -pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c 
libiconv.c
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 -pipe 
-fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c libiconv.c  -fPIC -DPIC -o 
.libs/libiconv.o
libiconv.c:50:3: warning: implicit declaration of function 'iconvctl' is 
invalid in C99 [-Wimplicit-function-declaration]
  iconvctl (conversion, ICONV_SET_TRANSLITERATE, &transliterate);
  ^
libiconv.c:50:25: error: use of undeclared identifier 'ICONV_SET_TRANSLITERATE'
  iconvctl (conversion, ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:51:33: error: use of undeclared identifier 'ICONV_SET_TRANSLITERATE'
  iconvctl (conversion_to_utf8, ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:102:8: error: use of undeclared identifier 'ICONV_SET_TRANSLITERATE'
ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:104:8: error: use of undeclared identifier 'ICONV_SET_TRANSLITERATE'
ICONV_SET_TRANSLITERATE, &transliterate);
^
1 warning and 4 errors generated.
*** [libiconv.lo] Error code 1

make[3]: stopped in /usr/ports/converters/recode/work/recode-3.6/src
1 error

make[3]: stopped in /usr/ports/converters/recode/work/recode-3.6/src
*** [all-recursive] Error code 1

make[2]: stopped in /usr/ports/converters/recode/work/recode-3.6
1 error


Cheers,
-- 
Mark Knight
Mobile: +44 7753 250584.  http://www.knigma.org/
Email: ma...@knigma.org.  Skype: knigma
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Squid aufs crashes under 10.0

[Mark Knight]

Without DEBUG I got this:

#0  0x00605f71 in Fs::Ufs::UFSSwapDir::UFSSwapDir ()
[New Thread 84006400 (LWP 100348/squid)]
(gdb) bt
#0  0x00605f71 in Fs::Ufs::UFSSwapDir::UFSSwapDir ()
#1  0x005ff7c5 in 
Fs::Ufs::StoreFSufs::createSwapDir ()
#2  0x004bfdf2 in strtokFile ()
#3  0x004aebdf in configFreeMemory ()
#4  0x004ac79e in parseConfigFile ()
#5  0x0055510c in SquidMain ()
#6  0x0055499c in main ()

It crashed immediately on start-up. Nothing in cache.log. Like you, with DEBUG 
gdb crashes.

Cheers,
-- 
Mark Knight
Mobile: +44 7753 250584.  http://www.knigma.org/
Email: ma...@knigma.org.  Skype: knigma
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Sage update

[Montgomery-Smith, Stephen]

On 02/05/2014 11:04 AM, Montgomery-Smith, Stephen wrote:
> On 02/05/2014 12:29 AM, Daniel Smith wrote:
>> I just tested it on my box. It gets a lot further, but crashes when
>> building scipy-0.12.0.p1. The only message in the log is a line
>> indicating that the spkg-install script failed on a line reading 
>>
>> python setup.py setup
>>
>> I'm currently working on digging through that file to see if I can
>> figure out more, but I won't be able to do much before tomorrow, I'm
>> afraid.
>>
>> I've attached the log file for details.
>>
> 
> I and one other person got the same error.
> 
> I did try the patch
> /usr/ports/devel/scons/files/patch-engine-SCons-compat-_scons_subprocess.py,
> but it didn't help at all.
> 
> If you type make again, I find that sage tries skipping the packages it
> failed to build in favor of other packages.  In this manner, you can
> find that matplotlib-1.2.1 fails to build in exactly the same way.

I built the science/py-scipy port.  Comparing the build logs, it seems
to me that sage completely builds the scipy subpackage.  And then python
crashes.  So somehow the problem is not with scipy as such.

You could just take out the error handling in the script spkg-install
inside build/pkgs/scipy.  That would be rather dangerous, but it might
provide for a temporary work around the problem.

To be honest, I am finding FreeBSD-10 to be quite a pain.  It is
something of a moving target.  One of my other ports now fails, where it
seems it used to build under FreeBSD-10 quite successfully.

If any of you have good insights, I would appreciate it.  But I may not
be able to spend a lot more time hunting down this bug until next
summer.  And I would prefer to wait until FreeBSD-10.1 is rolled out,
and things are more stable.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Squid aufs crashes under 10.0

[Dimitry Andric]

On 07 Feb 2014, at 14:24, Pavel Timofeev  wrote:
> Sorry, it has to be in freebsd-ports@ too.
> 
> 2014-02-07 Pavel Timofeev :
>> Hi!
>> There is a problem with squid under FreeBSD10.0.
>> Squid crashes immediately if storage type is set to aufs.
>> It goes down during read of config file.
>> 
>> No problem with diskd. No problem with aufs under FreeBSD9.2.
>> 
>> Someone thinks that it's related to clang which is default compiler on
>> FreeBSD 10.0.

Nope, it is a bug in Squid's configure script.  It recognizes FreeBSD
10.x and later as FreeBSD 1.x, causing it to disable pthreads support.
This leads to the required DiskThreads module being disabled too.  It
then crashes when it tries to access a NULL pointer returned by
DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc:

Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) : 
SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd (-1), 
currentIOOptions(new ConfigOptionVector()), ioType(xstrdup(anIOType)), 
cur_size(0), n_disk_objects(0)
{
/* modulename is only set to disk modules that are built, by configure,
 * so the Find call should never return NULL here.
 */
IO = new 
Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy());
}

Very bad coding practice, obviously.  It should call Find() first, and
if that returns NULL, it should abort in some sort of controlled way.

In any case, the cause is the following fragment in the configure
script:

  freebsd)
if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: pthread library 
requires FreeBSD 7 or later" >&5
$as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;}
squid_opt_use_diskthreads="no"
else

which was edited here:

http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124

I have attached a tentative patch for the port.  However, this causes
the configure script logic to run a little differently, and there is
some sort of very strange bug in it, that leads to the SQUID_CFLAGS and
SQUID_CXXFLAGS values being mangled in the default case.

With my patch the DiskThreads detection runs again, but the variables
are not mangled anymore, and this leads to -Werror being enabled again,
causing errors about deprecated kerberos5 functions later on in the
build.

For now, I would not bother with -Werror and Squid, but just add
--disable-strict-error-checking to CONFIGURE_ARGS in the Makefile.

That is, until somebody with autoconf knowledge can fix the badly broken
configure script...


>> I recompiled www/squid33 with DEBUG option. Got coredump.
>> Then I did and got this:
>> gdb /usr/local/sbin/squid /var/squid/squid.core
>> 
>> Reading symbols from /usr/lib/private/libheimipcc.so.11...done.
>> Loaded symbols for /usr/lib/private/libheimipcc.so.11
>> Reading symbols from /libexec/ld-elf.so.1...done.
>> Loaded symbols for /libexec/ld-elf.so.1
>> Segmentation fault (core dumped)
>> 
>> Gdb goes down too =)
>> Any ideas?

Yes, please don't use gdb in base for anything serious.  Use ports gdb
instead. :-)

-Dimitry


www__squid33-fix-pthreads-detection-1.diff
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

ccache and clang/llvm links

[RW]

I was wondering why the ccache compiler link options for clang and llvm
are off by default. AFAIK these links don't affect World build, so I was
wondering if there are any serious problems with ports.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Squid aufs crashes under 10.0

[Dennis Glatting]

On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> On 07 Feb 2014, at 14:24, Pavel Timofeev  wrote:
> > Sorry, it has to be in freebsd-ports@ too.
> > 
> > 2014-02-07 Pavel Timofeev :
> >> Hi!
> >> There is a problem with squid under FreeBSD10.0.
> >> Squid crashes immediately if storage type is set to aufs.
> >> It goes down during read of config file.
> >> 
> >> No problem with diskd. No problem with aufs under FreeBSD9.2.
> >> 
> >> Someone thinks that it's related to clang which is default compiler on
> >> FreeBSD 10.0.
> 
> Nope, it is a bug in Squid's configure script.  It recognizes FreeBSD
> 10.x and later as FreeBSD 1.x, causing it to disable pthreads support.
> This leads to the required DiskThreads module being disabled too.  It
> then crashes when it tries to access a NULL pointer returned by
> DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc:
> 
> Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) : 
> SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd (-1), 
> currentIOOptions(new ConfigOptionVector()), ioType(xstrdup(anIOType)), 
> cur_size(0), n_disk_objects(0)
> {
> /* modulename is only set to disk modules that are built, by configure,
>  * so the Find call should never return NULL here.
>  */
> IO = new 
> Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy());
> }
> 
> Very bad coding practice, obviously.  It should call Find() first, and
> if that returns NULL, it should abort in some sort of controlled way.
> 

Found that too but not the reason why:

(lldb) run -d -z -F -f /root/squid.conf
Process 23598 launched: './src/squid' (x86_64)
Find(): Mmapped
Find(): IpcIo
Find(): DiskDaemon
Find(): Blocking
Find(): AIO
Returning NULL

There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
example, I replaced strlen() with a custom version that first checks for
NULL and returns 0 if that is the case (strlen() was often called by
std::cstring::c_str() that was not yet initialized). That small code
fragment resolved a lot of SEGVs.


> In any case, the cause is the following fragment in the configure
> script:
> 
>   freebsd)
> if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then
> { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library 
> requires FreeBSD 7 or later" >&5
> $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;}
> squid_opt_use_diskthreads="no"
> else
> 
> which was edited here:
> 
> http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124
> 
> I have attached a tentative patch for the port.  However, this causes
> the configure script logic to run a little differently, and there is
> some sort of very strange bug in it, that leads to the SQUID_CFLAGS and
> SQUID_CXXFLAGS values being mangled in the default case.
> 
> With my patch the DiskThreads detection runs again, but the variables
> are not mangled anymore, and this leads to -Werror being enabled again,
> causing errors about deprecated kerberos5 functions later on in the
> build.
> 
> For now, I would not bother with -Werror and Squid, but just add
> --disable-strict-error-checking to CONFIGURE_ARGS in the Makefile.
> 
> That is, until somebody with autoconf knowledge can fix the badly broken
> configure script...
> 
> 
> >> I recompiled www/squid33 with DEBUG option. Got coredump.
> >> Then I did and got this:
> >> gdb /usr/local/sbin/squid /var/squid/squid.core
> >> 
> >> Reading symbols from /usr/lib/private/libheimipcc.so.11...done.
> >> Loaded symbols for /usr/lib/private/libheimipcc.so.11
> >> Reading symbols from /libexec/ld-elf.so.1...done.
> >> Loaded symbols for /libexec/ld-elf.so.1
> >> Segmentation fault (core dumped)
> >> 
> >> Gdb goes down too =)
> >> Any ideas?
> 
> Yes, please don't use gdb in base for anything serious.  Use ports gdb
> instead. :-)
> 
> -Dimitry


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

multimedia/tvheadend fails under FreeBSD 9.2-stable

[Torfinn Ingolfsen]

The port multimedia/tvheadend fails to compile under FreeBSD 9.2-stable.
Details:
root@kg-f4# uname -a
FreeBSD kg-f4.kg4.no 9.2-STABLE FreeBSD 9.2-STABLE #3 r261516: Wed Feb
 5 22:38:36 CET 2014
r...@kg-f4.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64

root@kg-f4# make showconfig
===> The following configuration options are available for
tvheadend-3.4.0.20130726.3_4:
 AVAHI=off: Zeroconf support via Avahi
 DVBCSA=on: Replace internal ffdecsa with dvbcsa
 FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...)
===> Use 'make config' to modify these settings

root@kg-f4# make
/!\ WARNING /!\
pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng
http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/
If you do not want to see this message again set
NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf

===>  License GPLv3 accepted by the user
===>  Found saved configuration for tvheadend-3.4.0.20130726.3_4
===> Fetching all distfiles required by tvheadend-3.4.0.20130726.3_4
for building
===>  Extracting for tvheadend-3.4.0.20130726.3_4
=> SHA256 Checksum OK for tvheadend-3.4.0.20130726.3.tar.gz.
=> SHA256 Checksum OK for dvb-scan-tables-20130714.tar.gz.
===>  Patching for tvheadend-3.4.0.20130726.3_4
===>  Applying FreeBSD patches for tvheadend-3.4.0.20130726.3_4
===>   tvheadend-3.4.0.20130726.3_4 depends on executable: bash - found
===>   tvheadend-3.4.0.20130726.3_4 depends on file:
/usr/local/include/linux/videodev2.h - found
===>   tvheadend-3.4.0.20130726.3_4 depends on file:
/usr/local/bin/python2.7 - found
===>   tvheadend-3.4.0.20130726.3_4 depends on executable: pkgconf - found
===>   tvheadend-3.4.0.20130726.3_4 depends on executable: gmake - found
===>   tvheadend-3.4.0.20130726.3_4 depends on shared library:
libexecinfo.so - found
===>   tvheadend-3.4.0.20130726.3_4 depends on shared library:
libcurl.so - found
===>  Configuring for tvheadend-3.4.0.20130726.3_4
Checking support/features
  checking for cc execinfo.h ...ok
  checking for cc -mmmx ... ok
  checking for cc -msse2 ...ok
  checking for cc getloadavg ...ok
  checking for cc atomic64 ...  ok
  checking for py module gzip ...   ok
  checking for bzip2 ...ok
  checking for pkg avahi-client  ...ok
  checking for pkg libavcodec <=55.0.0 ...  fail
  checking for cc sys/inotify.h ... fail
  checking for pkg libcurl  ... ok

Compiler:
  Using C compiler:cc
  Using C flags:   -O2 -pipe
-I/usr/local/include -Wno-conversion -Wno-int-to-pointer-cast
-fno-strict-aliasing
  Build for arch:  amd64

Binaries:
  Using PYTHON:/usr/local/bin/python2.7

Options:
  cwc  yes
  v4l  yes
  linuxdvb yes
  dvbscan  no
  timeshiftyes
  traceyes
  imagecache   yes
  avahiyes
  zlib no
  libavno
  inotify  no
  bundle   no
  dvbcsa   no
  epollno
  kqueue   yes
  execinfo yes
  mmx  yes
  sse2 yes
  getloadavg   yes
  atomic64 yes
  py_gzip  yes
  bin_bzip2yes
  ssl  yes

Packages:
  avahi-client 0.6.31
  libcurl  7.34.0

Installation paths:
  Prefix:  /usr/local
  Binaries:${prefix}/bin
  Libraries:   ${prefix}/lib
  Data files:  ${prefix}/share
  Man pages:   /usr/local/man

Final Binary:
  
/usr/ports/multimedia/tvheadend/work/decke-tvheadend-8a8c1a8/build.freebsd/tvheadend

Tvheadend Data Directory:
  /usr/local/share/tvheadend

===>  Building for tvheadend-3.4.0.20130726.3_4
CC  src/version.o
CC  src/main.o
CC  src/tvhlog.o
CC  src/utils.o
CC  src/wrappers.o
CC  src/access.o
CC  src/dtable.o
CC  src/tcp.o
CC  src/http.o
CC  src/notify.o
CC  src/file.o
CC  src/epg.o
CC  src/epgdb.o
CC  

Re: Sage update

[Ajtim]

On Sunday 09 February 2014 16:24:03 Montgomery-Smith, Stephen wrote:
> On 02/05/2014 11:04 AM, Montgomery-Smith, Stephen wrote:
> > On 02/05/2014 12:29 AM, Daniel Smith wrote:
> >> I just tested it on my box. It gets a lot further, but crashes when
> >> building scipy-0.12.0.p1. The only message in the log is a line
> >> indicating that the spkg-install script failed on a line reading 
> >>
> >> python setup.py setup
> >>
> >> I'm currently working on digging through that file to see if I can
> >> figure out more, but I won't be able to do much before tomorrow, I'm
> >> afraid.
> >>
> >> I've attached the log file for details.
> >>
> > 
> > I and one other person got the same error.
> > 
> > I did try the patch
> > /usr/ports/devel/scons/files/patch-engine-SCons-compat-_scons_subprocess.py,
> > but it didn't help at all.
> > 
> > If you type make again, I find that sage tries skipping the packages it
> > failed to build in favor of other packages.  In this manner, you can
> > find that matplotlib-1.2.1 fails to build in exactly the same way.
> 
> I built the science/py-scipy port.  Comparing the build logs, it seems
> to me that sage completely builds the scipy subpackage.  And then python
> crashes.  So somehow the problem is not with scipy as such.
> 
> You could just take out the error handling in the script spkg-install
> inside build/pkgs/scipy.  That would be rather dangerous, but it might
> provide for a temporary work around the problem.
> 
> To be honest, I am finding FreeBSD-10 to be quite a pain.  It is
> something of a moving target.  One of my other ports now fails, where it
> seems it used to build under FreeBSD-10 quite successfully.
> 
> If any of you have good insights, I would appreciate it.  But I may not
> be able to spend a lot more time hunting down this bug until next
> summer.  And I would prefer to wait until FreeBSD-10.1 is rolled out,
> and things are more stable.

Thank you very much for all your work. I agree that is 10.0 very 
painfulmaybe it came out to fast.

-- 
Mitja
---
http://www.redbubble.com/people/lumiwa

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Squid aufs crashes under 10.0

[Dimitry Andric]

On 09 Feb 2014, at 20:16, Dennis Glatting  wrote:
> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
...
>> Very bad coding practice, obviously.  It should call Find() first, and
>> if that returns NULL, it should abort in some sort of controlled way.
>> 
> 
> Found that too but not the reason why:
> 
> (lldb) run -d -z -F -f /root/squid.conf
> Process 23598 launched: './src/squid' (x86_64)
> Find(): Mmapped
> Find(): IpcIo
> Find(): DiskDaemon
> Find(): Blocking
> Find(): AIO
> Returning NULL
> 
> There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
> example, I replaced strlen() with a custom version that first checks for
> NULL and returns 0 if that is the case (strlen() was often called by
> std::cstring::c_str() that was not yet initialized). That small code
> fragment resolved a lot of SEGVs.

There are a bunch of places where they use std::ostream::operator<< to
output e.g. configuration strings to the debug stream, for example in
uniqueHostname(), in src/tools.cc:

const char *
uniqueHostname(void)
{
debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'");
return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname();
}

The problem case is when Config.uniqueHostname is NULL: this gets
converted into a std::string first (which is _undefined behavior_), then
it gets streamed to the debug stream.

However, there is a difference between libstdc++ and libc++ here: the
former silently accepts NULL arguments passed to the std::string
constructor, creating a sort of "empty" string for you, which seems to
work as normal.  The latter just stores your NULL pointer, and if you
actually try to do anything with it, the program will crash.

To fix at least two places where this is done, drop the attached patches
in www/squid33/files.

-Dimitry


patch-src-acl-Acl.cc
Description: Binary data


patch-src-tools.cc
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: multimedia/tvheadend fails under FreeBSD 9.2-stable

[Bernhard Fröhlich]

Am 09.02.2014 20:49 schrieb "Torfinn Ingolfsen" :
>
> The port multimedia/tvheadend fails to compile under FreeBSD 9.2-stable.
> Details:
> root@kg-f4# uname -a
> FreeBSD kg-f4.kg4.no 9.2-STABLE FreeBSD 9.2-STABLE #3 r261516: Wed Feb
>  5 22:38:36 CET 2014
> r...@kg-f4.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
>
> root@kg-f4# make showconfig
> ===> The following configuration options are available for
> tvheadend-3.4.0.20130726.3_4:
>  AVAHI=off: Zeroconf support via Avahi
>  DVBCSA=on: Replace internal ffdecsa with dvbcsa
>  FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...)
> ===> Use 'make config' to modify these settings
>
> root@kg-f4# make
> /!\ WARNING /!\
> pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to
pkgng
>
http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/
> If you do not want to see this message again set
> NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf
>
> ===>  License GPLv3 accepted by the user
> ===>  Found saved configuration for tvheadend-3.4.0.20130726.3_4
> ===> Fetching all distfiles required by tvheadend-3.4.0.20130726.3_4
> for building
> ===>  Extracting for tvheadend-3.4.0.20130726.3_4
> => SHA256 Checksum OK for tvheadend-3.4.0.20130726.3.tar.gz.
> => SHA256 Checksum OK for dvb-scan-tables-20130714.tar.gz.
> ===>  Patching for tvheadend-3.4.0.20130726.3_4
> ===>  Applying FreeBSD patches for tvheadend-3.4.0.20130726.3_4
> ===>   tvheadend-3.4.0.20130726.3_4 depends on executable: bash - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on file:
> /usr/local/include/linux/videodev2.h - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on file:
> /usr/local/bin/python2.7 - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on executable: pkgconf - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on executable: gmake - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on shared library:
> libexecinfo.so - found
> ===>   tvheadend-3.4.0.20130726.3_4 depends on shared library:
> libcurl.so - found
> ===>  Configuring for tvheadend-3.4.0.20130726.3_4
> Checking support/features
>   checking for cc execinfo.h ...ok
>   checking for cc -mmmx ... ok
>   checking for cc -msse2 ...ok
>   checking for cc getloadavg ...ok
>   checking for cc atomic64 ...  ok
>   checking for py module gzip ...   ok
>   checking for bzip2 ...ok
>   checking for pkg avahi-client  ...ok
>   checking for pkg libavcodec <=55.0.0 ...  fail
>   checking for cc sys/inotify.h ... fail
>   checking for pkg libcurl  ... ok
>
> Compiler:
>   Using C compiler:cc
>   Using C flags:   -O2 -pipe
> -I/usr/local/include -Wno-conversion -Wno-int-to-pointer-cast
> -fno-strict-aliasing
>   Build for arch:  amd64
>
> Binaries:
>   Using PYTHON:/usr/local/bin/python2.7
>
> Options:
>   cwc  yes
>   v4l  yes
>   linuxdvb yes
>   dvbscan  no
>   timeshiftyes
>   traceyes
>   imagecache   yes
>   avahiyes
>   zlib no
>   libavno
>   inotify  no
>   bundle   no
>   dvbcsa   no
>   epollno
>   kqueue   yes
>   execinfo yes
>   mmx  yes
>   sse2 yes
>   getloadavg   yes
>   atomic64 yes
>   py_gzip  yes
>   bin_bzip2yes
>   ssl  yes
>
> Packages:
>   avahi-client 0.6.31
>   libcurl  7.34.0
>
> Installation paths:
>   Prefix:  /usr/local
>   Binaries:${prefix}/bin
>   Libraries:   ${prefix}/lib
>   Data files:  ${prefix}/share
>   Man pages:   /usr/local/man
>
> Final Binary:
>
/usr/ports/multimedia/tvheadend/work/decke-tvheadend-8a8c1a8/build.freebsd/tvheadend
>
> Tvheadend Data Directory:
>   /usr/local/share/tvheadend
>
> ===>  Building for tvheadend-3.4.0.20130726.3_4
> CC  src/version.o
> CC  src/main.o
> CC  src/tvhlog.o
> CC  src/

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>
>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
>>
>>> Am 05.02.2014 21:08, schrieb Dimitry Andric:
>>>
>>>
> #17 0x484c0ee0 in std::__1::locale::id::__next_id () from
>  /usr/local/lib/libc++.so.1
>

 Hmm, is this a ports version of libc++?  I was not aware Baptiste
 had already committed this? :)
>>>
>>> Yes, it is (as a build requisite, but apparently remained installed
>>> on the destination machine), because we need to match the libraries
>>> that the requisites use (Glibmm for one).
>>>
>>> I have given up on compiling RawTherapee with clang++ for now, and
>>> use GCC 4.8 on all systems.  RawTherapee is somewhat demanding,
>>> especially at higher optimization level, and kills the 10.0-RELEASE
>>> base clang and Port GCC 4.6 and 4.7, all with internal compiler
>>> errors.  Since GCC 4.8 worked for me, I did not bother to send Gerald
>>> the details.
>>>
>>> We may want to retry with clang if we've got the next clang version.
>>> Feel free to use Rawtherapee as compiler system test ;)
>>>
>>>
>>
>> try with something like this in libmap.conf libc++.so.1
>> /usr/local/lib/libc++.so.1
>> If that fixes the problem, then a rpath with /usr/local/lib should be
>> set while building the port
>
> Hmm, I am not very familiar with libmapping. After adding it to
> /etc/libmap.conf I get
>
>
> #rawtherapee
> Shared object "/usr/local/lib/libc++.so.1" not found, required by
> "rawtherapee"
>
>
> Thanks for the tip,
> Rainer
>
>
>>
>> regards, Bapt
>>
>>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
>


Here are a few points regarding rawtherapee on 11.0-CURRENT.

1) it builds fine using clang (removing all the gcc4.8 from makefile). but
still crashes the same.

2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'

can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3

3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?

here is a sample:

#include 
#include 
#include 

int main() {

double value = 22.0 / 7.0;
std::cout << value << std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout << test << std::endl;

}


$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4` testglib.cpp
$ ./testglib
3.14286
Abort trap (core dumped)


$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
For bug reporting instructions, please see:
...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0  0x000801e313ba in kill () from /lib/libc.so.7
#1  0x000801e30069 in abort () from /lib/libc.so.7
#2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
   from /usr/local/lib/libglibmm-2.4.so.1
#4  0x00080086ed2f in Glib::Error::throw_exception(_GError*) ()
   from /usr/local/lib/libglibmm-2.4.so.1
#5  0x00080087bcc2 in Glib::ustring::FormatStream::to_string() const ()
   from /usr/local/lib/libglibmm-2.4.so.1
#6  0x00401de0 in Glib::ustring::format(std::__1::ios_base& (
const&)(std::__1::ios_base&), std::__1::__iom_t5 const&, double const&) (
a1= 0x401e50: {std::__1::ios_base &(std::__1::ios_base &)} 0x401e50
, a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158
#7  0x00401696 in main () at testglib.cpp:9
(gdb)



$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb  8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA  amd64

$ ldd testglib
testglib:
libglibmm-2.4.so.1 => /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0
(0x800a9d000

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>
>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
>>
>>> Am 05.02.2014 21:08, schrieb Dimitry Andric:
>>>
>>>
> #17 0x484c0ee0 in std::__1::locale::id::__next_id () from
>  /usr/local/lib/libc++.so.1
>

 Hmm, is this a ports version of libc++?  I was not aware Baptiste
 had already committed this? :)
>>>
>>> Yes, it is (as a build requisite, but apparently remained installed
>>> on the destination machine), because we need to match the libraries
>>> that the requisites use (Glibmm for one).
>>>
>>> I have given up on compiling RawTherapee with clang++ for now, and
>>> use GCC 4.8 on all systems.  RawTherapee is somewhat demanding,
>>> especially at higher optimization level, and kills the 10.0-RELEASE
>>> base clang and Port GCC 4.6 and 4.7, all with internal compiler
>>> errors.  Since GCC 4.8 worked for me, I did not bother to send Gerald
>>> the details.
>>>
>>> We may want to retry with clang if we've got the next clang version.
>>> Feel free to use Rawtherapee as compiler system test ;)
>>>
>>>
>>
>> try with something like this in libmap.conf libc++.so.1
>> /usr/local/lib/libc++.so.1
>> If that fixes the problem, then a rpath with /usr/local/lib should be
>> set while building the port
>
> Hmm, I am not very familiar with libmapping. After adding it to
> /etc/libmap.conf I get
>
>
> #rawtherapee
> Shared object "/usr/local/lib/libc++.so.1" not found, required by
> "rawtherapee"
>
>
> Thanks for the tip,
> Rainer
>
>
>>
>> regards, Bapt
>>
>>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
>


Here are a few points regarding rawtherapee on 11.0-CURRENT.

1) it builds fine using clang (removing all the gcc4.8 from makefile). but
still crashes the same.

2) the parse errors such as
/usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
unexpected identifier `colorize_scrollbar', expected character `}'

can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
this is the clearlooks theme ported to gtk3

3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
experimented with various examples and they all crash. Currently exploring
this problem to see what's up.. anyone have some clue?

here is a sample:

#include 
#include 
#include 

int main() {

double value = 22.0 / 7.0;
std::cout << value << std::endl;
Glib::ustring test =
Glib::ustring::format(std::fixed,std::setprecision(2),value);
std::cout << test << std::endl;

}


$ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4` testglib.cpp
$ ./testglib
3.14286
Abort trap (core dumped)


$ /usr/local/bin/gdb testglib
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
For bug reporting instructions, please see:
...
Reading symbols from /usr/home/waitman/testglib...done.
(gdb) run
Starting program: /usr/home/waitman/testglib
[New LWP 100327]
3.14286
[New Thread 803006400 (LWP 100327)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 803006400 (LWP 100327)]
0x000801e313ba in kill () from /lib/libc.so.7
(gdb) bt
#0  0x000801e313ba in kill () from /lib/libc.so.7
#1  0x000801e30069 in abort () from /lib/libc.so.7
#2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
#3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
   from /usr/local/lib/libglibmm-2.4.so.1
#4  0x00080086ed2f in Glib::Error::throw_exception(_GError*) ()
   from /usr/local/lib/libglibmm-2.4.so.1
#5  0x00080087bcc2 in Glib::ustring::FormatStream::to_string() const ()
   from /usr/local/lib/libglibmm-2.4.so.1
#6  0x00401de0 in Glib::ustring::format(std::__1::ios_base& (
const&)(std::__1::ios_base&), std::__1::__iom_t5 const&, double const&) (
a1= 0x401e50: {std::__1::ios_base &(std::__1::ios_base &)} 0x401e50
, a2=..., a3= 0x7fffd860:
3.1428571428571428)
at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158
#7  0x00401696 in main () at testglib.cpp:9
(gdb)



$ uname -a
FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r261643:
Sat Feb  8 22:11:05 PST 2014
root akira waitman net:/usr/obj/usr/src/sys/AKIRA  amd64

$ ldd testglib
testglib:
libglibmm-2.4.so.1 => /usr/local/lib/libglibmm-2.4.so.1 (0x80081e000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0
(0x800a9d000

Re: Sage update

[Kostas Oikonomou]

The main reason I haven't contributed anything to the discussion is that
I'm struggling with PCBSD10.0 also, since I use the machine for my
regular work as well. 

One particularly disheartening bug is that making a new boot environment
to do the upgrade in, and safeguard the old 9.2 boot environment, seems
to be buggy. Both the new and the backup environments are upgraded to
10.0, and you lose 9.2.

Kostas

On 02/09/2014 11:24, Montgomery-Smith, Stephen wrote:
>  To be honest, I am finding FreeBSD-10 to be quite a pain. It is
> something of a moving target. One of my other ports now fails, where
> it seems it used to build under FreeBSD-10 quite successfully. If any
> of you have good insights, I would appreciate it. But I may not be
> able to spend a lot more time hunting down this bug until next summer.
> And I would prefer to wait until FreeBSD-10.1 is rolled out, and
> things are more stable. 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Maximizing the use of binary packages and minimizing building packages

[Chad Perrin]

On Tue, Jan 14, 2014 at 11:16:52PM +, Matthew Seaman wrote:
> On 14/01/2014 19:35, Matt Reimer wrote:
> > That's good news. What should I watch for in order to know when Really
> > Soon Now becomes Now?
> > 
> 
> The release of pkg-1.3.x

After most of a month (yes, I know that's not all that long), as I
upgrade Mumble from pkgng to portmaster install to avoid having Qt
binary package libs destroy X11 functionality with KMS again and watch
the process destroy my browser instead, I wonder . . .

Do you have any estimate on how many months Real Soon Now might mean?  I
swear I won't hold you to a deadline; I would rather it be done right
than done quickly.  I'm just interested in having something like an
order-of-magnitude guesstimate for how far in the future Real Soon Now
will happen.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
>

> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
>
>> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>>
>>
>>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
>>>
>>>
 Am 05.02.2014 21:08, schrieb Dimitry Andric:



>> #17 0x484c0ee0 in std::__1::locale::id::__next_id ()
>> from /usr/local/lib/libc++.so.1
>>
>>
>
> Hmm, is this a ports version of libc++?  I was not aware Baptiste
>  had already committed this? :)

 Yes, it is (as a build requisite, but apparently remained installed
  on the destination machine), because we need to match the
 libraries that the requisites use (Glibmm for one).

 I have given up on compiling RawTherapee with clang++ for now, and
 use GCC 4.8 on all systems.  RawTherapee is somewhat demanding,
 especially at higher optimization level, and kills the 10.0-RELEASE
  base clang and Port GCC 4.6 and 4.7, all with internal compiler
 errors.  Since GCC 4.8 worked for me, I did not bother to send
 Gerald
 the details.

 We may want to retry with clang if we've got the next clang
 version. Feel free to use Rawtherapee as compiler system test ;)



>>>
>>> try with something like this in libmap.conf libc++.so.1
>>> /usr/local/lib/libc++.so.1
>>> If that fixes the problem, then a rpath with /usr/local/lib should be
>>> set while building the port
>>
>> Hmm, I am not very familiar with libmapping. After adding it to
>> /etc/libmap.conf I get
>>
>>
>>
>> #rawtherapee
>> Shared object "/usr/local/lib/libc++.so.1" not found, required by
>> "rawtherapee"
>>
>>
>>
>> Thanks for the tip,
>> Rainer
>>
>>
>>
>>>
>>> regards, Bapt
>>>
>>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
>>
>>
>
>
> Here are a few points regarding rawtherapee on 11.0-CURRENT.
>
>
> 1) it builds fine using clang (removing all the gcc4.8 from makefile).
> but still crashes the same.
>
> 2) the parse errors such as
> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> unexpected identifier `colorize_scrollbar', expected character `}'
>
> can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
>  this is the clearlooks theme ported to gtk3
>
> 3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
> experimented with various examples and they all crash. Currently exploring
>  this problem to see what's up.. anyone have some clue?
>
> here is a sample:
>
> #include 
> #include 
> #include 
>
>
> int main() {
>
> double value = 22.0 / 7.0; std::cout << value << std::endl;
> Glib::ustring test =
> Glib::ustring::format(std::fixed,std::setprecision(2),value);
> std::cout << test << std::endl;
>
>
> }
>
>
>
> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> testglib.cpp $ ./testglib
> 3.14286
> Abort trap (core dumped)
>
>
>
> $ /usr/local/bin/gdb testglib
> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>  and "show warranty" for details. This GDB was configured as
> "x86_64-portbld-freebsd11.0".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/home/waitman/testglib...done.
> (gdb) run
> Starting program: /usr/home/waitman/testglib
> [New LWP 100327]
> 3.14286
> [New Thread 803006400 (LWP 100327)]
>
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 803006400 (LWP 100327)]
> 0x000801e313ba in kill () from /lib/libc.so.7
> (gdb) bt
> #0  0x000801e313ba in kill () from /lib/libc.so.7
> #1  0x000801e30069 in abort () from /lib/libc.so.7
> #2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
> #3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
> from /usr/local/lib/libglibmm-2.4.so.1 #4  0x00080086ed2f in
> Glib::Error::throw_exception(_GError*) ()
> from /usr/local/lib/libglibmm-2.4.so.1 #5  0x00080087bcc2 in
> Glib::ustring::FormatStream::to_string() const ()
> from /usr/local/lib/libglibmm-2.4.so.1 #6  0x00401de0 in
> Glib::ustring::format (std::__1::ios_base&), std::__1::__iom_t5, double>(std::__1::ios_base& (
> const&)(std::__1::ios_base&), std::__1::__iom_t5 const&, double const&) (
> a1= 0x401e50: {std::__1::ios_base &(std::__1::ios_base &)} 0x401e50
> , a2=..., a3= 0x7fffd860:
> 3.1428571428571428)
> at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
> 0x00401696 in main () at testglib.cpp:9
> (gdb)
>
>
>
>
> $ uname -a
> FreeBSD a

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
>

> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
>
>> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>>
>>
>>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
>>>
>>>
 Am 05.02.2014 21:08, schrieb Dimitry Andric:



>> #17 0x484c0ee0 in std::__1::locale::id::__next_id ()
>> from /usr/local/lib/libc++.so.1
>>
>>
>
> Hmm, is this a ports version of libc++?  I was not aware Baptiste
>  had already committed this? :)

 Yes, it is (as a build requisite, but apparently remained installed
  on the destination machine), because we need to match the
 libraries that the requisites use (Glibmm for one).

 I have given up on compiling RawTherapee with clang++ for now, and
 use GCC 4.8 on all systems.  RawTherapee is somewhat demanding,
 especially at higher optimization level, and kills the 10.0-RELEASE
  base clang and Port GCC 4.6 and 4.7, all with internal compiler
 errors.  Since GCC 4.8 worked for me, I did not bother to send
 Gerald
 the details.

 We may want to retry with clang if we've got the next clang
 version. Feel free to use Rawtherapee as compiler system test ;)



>>>
>>> try with something like this in libmap.conf libc++.so.1
>>> /usr/local/lib/libc++.so.1
>>> If that fixes the problem, then a rpath with /usr/local/lib should be
>>> set while building the port
>>
>> Hmm, I am not very familiar with libmapping. After adding it to
>> /etc/libmap.conf I get
>>
>>
>>
>> #rawtherapee
>> Shared object "/usr/local/lib/libc++.so.1" not found, required by
>> "rawtherapee"
>>
>>
>>
>> Thanks for the tip,
>> Rainer
>>
>>
>>
>>>
>>> regards, Bapt
>>>
>>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
>>
>>
>
>
> Here are a few points regarding rawtherapee on 11.0-CURRENT.
>
>
> 1) it builds fine using clang (removing all the gcc4.8 from makefile).
> but still crashes the same.
>
> 2) the parse errors such as
> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> unexpected identifier `colorize_scrollbar', expected character `}'
>
> can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
>  this is the clearlooks theme ported to gtk3
>
> 3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
> experimented with various examples and they all crash. Currently exploring
>  this problem to see what's up.. anyone have some clue?
>
> here is a sample:
>
> #include 
> #include 
> #include 
>
>
> int main() {
>
> double value = 22.0 / 7.0; std::cout << value << std::endl;
> Glib::ustring test =
> Glib::ustring::format(std::fixed,std::setprecision(2),value);
> std::cout << test << std::endl;
>
>
> }
>
>
>
> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> testglib.cpp $ ./testglib
> 3.14286
> Abort trap (core dumped)
>
>
>
> $ /usr/local/bin/gdb testglib
> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>  and "show warranty" for details. This GDB was configured as
> "x86_64-portbld-freebsd11.0".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/home/waitman/testglib...done.
> (gdb) run
> Starting program: /usr/home/waitman/testglib
> [New LWP 100327]
> 3.14286
> [New Thread 803006400 (LWP 100327)]
>
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 803006400 (LWP 100327)]
> 0x000801e313ba in kill () from /lib/libc.so.7
> (gdb) bt
> #0  0x000801e313ba in kill () from /lib/libc.so.7
> #1  0x000801e30069 in abort () from /lib/libc.so.7
> #2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
> #3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
> from /usr/local/lib/libglibmm-2.4.so.1 #4  0x00080086ed2f in
> Glib::Error::throw_exception(_GError*) ()
> from /usr/local/lib/libglibmm-2.4.so.1 #5  0x00080087bcc2 in
> Glib::ustring::FormatStream::to_string() const ()
> from /usr/local/lib/libglibmm-2.4.so.1 #6  0x00401de0 in
> Glib::ustring::format (std::__1::ios_base&), std::__1::__iom_t5, double>(std::__1::ios_base& (
> const&)(std::__1::ios_base&), std::__1::__iom_t5 const&, double const&) (
> a1= 0x401e50: {std::__1::ios_base &(std::__1::ios_base &)} 0x401e50
> , a2=..., a3= 0x7fffd860:
> 3.1428571428571428)
> at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158 #7
> 0x00401696 in main () at testglib.cpp:9
> (gdb)
>
>
>
>
> $ uname -a
> FreeBSD 

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
> 
> 
> On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
> >
> 
> > On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
> >
> >> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
> >>
> >>
> >>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
> >>>
> >>>
>  Am 05.02.2014 21:08, schrieb Dimitry Andric:
> 
> 
> 
> >> #17 0x484c0ee0 in std::__1::locale::id::__next_id ()
> >> from /usr/local/lib/libc++.so.1
> >>
> >>
> >
> > Hmm, is this a ports version of libc++?  I was not aware Baptiste
> >  had already committed this? :)
> 
>  Yes, it is (as a build requisite, but apparently remained installed
>   on the destination machine), because we need to match the
>  libraries that the requisites use (Glibmm for one).
> 
>  I have given up on compiling RawTherapee with clang++ for now, and
>  use GCC 4.8 on all systems.  RawTherapee is somewhat demanding,
>  especially at higher optimization level, and kills the 10.0-RELEASE
>   base clang and Port GCC 4.6 and 4.7, all with internal compiler
>  errors.  Since GCC 4.8 worked for me, I did not bother to send
>  Gerald
>  the details.
> 
>  We may want to retry with clang if we've got the next clang
>  version. Feel free to use Rawtherapee as compiler system test ;)
> 
> 
> 
> >>>
> >>> try with something like this in libmap.conf libc++.so.1
> >>> /usr/local/lib/libc++.so.1
> >>> If that fixes the problem, then a rpath with /usr/local/lib should be
> >>> set while building the port
> >>
> >> Hmm, I am not very familiar with libmapping. After adding it to
> >> /etc/libmap.conf I get
> >>
> >>
> >>
> >> #rawtherapee
> >> Shared object "/usr/local/lib/libc++.so.1" not found, required by
> >> "rawtherapee"
> >>
> >>
> >>
> >> Thanks for the tip,
> >> Rainer
> >>
> >>
> >>
> >>>
> >>> regards, Bapt
> >>>
> >>>
> >> ___
> >> freebsd-ports@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> >>
> >>
> >>
> >
> >
> > Here are a few points regarding rawtherapee on 11.0-CURRENT.
> >
> >
> > 1) it builds fine using clang (removing all the gcc4.8 from makefile).
> > but still crashes the same.
> >
> > 2) the parse errors such as
> > /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> > unexpected identifier `colorize_scrollbar', expected character `}'
> >
> > can be eliminated by installing ports/x11-themes/clearlooks-phenix-theme,
> >  this is the clearlooks theme ported to gtk3
> >
> > 3) I believe i'be narrowed the crash down to Glib::ustring::format. I've
> > experimented with various examples and they all crash. Currently exploring
> >  this problem to see what's up.. anyone have some clue?
> >
> > here is a sample:
> >
> > #include 
> > #include 
> > #include 
> >
> >
> > int main() {
> >
> > double value = 22.0 / 7.0; std::cout << value << std::endl;
> > Glib::ustring test =
> > Glib::ustring::format(std::fixed,std::setprecision(2),value);
> > std::cout << test << std::endl;
> >
> >
> > }
> >
> >
> >
> > $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> > testglib.cpp $ ./testglib
> > 3.14286
> > Abort trap (core dumped)
> >
> >
> >
> > $ /usr/local/bin/gdb testglib
> > GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> > Copyright (C) 2013 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> >  and "show warranty" for details. This GDB was configured as
> > "x86_64-portbld-freebsd11.0".
> > For bug reporting instructions, please see:
> > ...
> > Reading symbols from /usr/home/waitman/testglib...done.
> > (gdb) run
> > Starting program: /usr/home/waitman/testglib
> > [New LWP 100327]
> > 3.14286
> > [New Thread 803006400 (LWP 100327)]
> >
> >
> > Program received signal SIGABRT, Aborted.
> > [Switching to Thread 803006400 (LWP 100327)]
> > 0x000801e313ba in kill () from /lib/libc.so.7
> > (gdb) bt
> > #0  0x000801e313ba in kill () from /lib/libc.so.7
> > #1  0x000801e30069 in abort () from /lib/libc.so.7
> > #2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
> > #3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
> > from /usr/local/lib/libglibmm-2.4.so.1 #4  0x00080086ed2f in
> > Glib::Error::throw_exception(_GError*) ()
> > from /usr/local/lib/libglibmm-2.4.so.1 #5  0x00080087bcc2 in
> > Glib::ustring::FormatStream::to_string() const ()
> > from /usr/local/lib/libglibmm-2.4.so.1 #6  0x00401de0 in
> > Glib::ustring::format > (std::__1::ios_base&), std::__1::__iom_t5, double>

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
> On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
>
>>
>>
>> On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
>>
>>>
>>
>>> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
>>>
>>>
 Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:



> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
>
>
>
>> Am 05.02.2014 21:08, schrieb Dimitry Andric:
>>
>>
>>
>>
 #17 0x484c0ee0 in std::__1::locale::id::__next_id
 ()
 from /usr/local/lib/libc++.so.1


>>>
>>> Hmm, is this a ports version of libc++?  I was not aware
>>> Baptiste
>>> had already committed this? :)
>>
>> Yes, it is (as a build requisite, but apparently remained
>> installed on the destination machine), because we need to match
>> the libraries that the requisites use (Glibmm for one).
>>
>> I have given up on compiling RawTherapee with clang++ for now,
>> and use GCC 4.8 on all systems.  RawTherapee is somewhat
>> demanding, especially at higher optimization level, and kills
>> the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with
>> internal compiler errors.  Since GCC 4.8 worked for me, I did
>> not bother to send Gerald
>> the details.
>>
>> We may want to retry with clang if we've got the next clang
>> version. Feel free to use Rawtherapee as compiler system test ;)
>>
>>
>>
>>
>
> try with something like this in libmap.conf libc++.so.1
> /usr/local/lib/libc++.so.1
> If that fixes the problem, then a rpath with /usr/local/lib should
> be set while building the port

 Hmm, I am not very familiar with libmapping. After adding it to
 /etc/libmap.conf I get




 #rawtherapee
 Shared object "/usr/local/lib/libc++.so.1" not found, required by
 "rawtherapee"




 Thanks for the tip,
 Rainer




>
> regards, Bapt
>
>
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to
 "freebsd-ports-unsubscr...@freebsd.org"




>>>
>>>
>>> Here are a few points regarding rawtherapee on 11.0-CURRENT.
>>>
>>>
>>>
>>> 1) it builds fine using clang (removing all the gcc4.8 from
>>> makefile). but still crashes the same.
>>>
>>> 2) the parse errors such as
>>> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
>>> unexpected identifier `colorize_scrollbar', expected character `}'
>>>
>>> can be eliminated by installing
>>> ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks theme
>>> ported to gtk3
>>>
>>> 3) I believe i'be narrowed the crash down to Glib::ustring::format.
>>> I've
>>> experimented with various examples and they all crash. Currently
>>> exploring this problem to see what's up.. anyone have some clue?
>>>
>>> here is a sample:
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>>
>>>
>>> int main() {
>>>
>>> double value = 22.0 / 7.0; std::cout << value << std::endl;
>>> Glib::ustring test =
>>> Glib::ustring::format(std::fixed,std::setprecision(2),value);
>>> std::cout << test << std::endl;
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>>
>>> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
>>> testglib.cpp $ ./testglib 3.14286
>>> Abort trap (core dumped)
>>>
>>>
>>>
>>>
>>> $ /usr/local/bin/gdb testglib
>>> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>>> copying" and "show warranty" for details. This GDB was configured as
>>> "x86_64-portbld-freebsd11.0".
>>> For bug reporting instructions, please see:
>>> ...
>>> Reading symbols from /usr/home/waitman/testglib...done.
>>> (gdb) run
>>> Starting program: /usr/home/waitman/testglib
>>> [New LWP 100327]
>>> 3.14286
>>> [New Thread 803006400 (LWP 100327)]
>>>
>>>
>>>
>>> Program received signal SIGABRT, Aborted.
>>> [Switching to Thread 803006400 (LWP 100327)]
>>> 0x000801e313ba in kill () from /lib/libc.so.7
>>> (gdb) bt
>>> #0  0x000801e313ba in kill () from /lib/libc.so.7
>>> #1  0x000801e30069 in abort () from /lib/libc.so.7
>>> #2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
>>> #3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
>>> from /usr/local/lib/libglibmm-2.4.so.1 #4  0x00080086ed2f in
>>> Glib::Error::throw_exception(_GError*) ()
>>> from /usr/local/lib/libglibmm-2.4.so.1 #5  0x00080087bcc2 in
>>> Glib::ustring::FormatStream::to_str

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
> 
> On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
> > On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
> >
> >>
> >>
> >> On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
> >>
> >>>
> >>
> >>> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
> >>>
> >>>
>  Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
> 
> 
> 
> > On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote:
> >
> >
> >
> >> Am 05.02.2014 21:08, schrieb Dimitry Andric:
> >>
> >>
> >>
> >>
>  #17 0x484c0ee0 in std::__1::locale::id::__next_id
>  ()
>  from /usr/local/lib/libc++.so.1
> 
> 
> >>>
> >>> Hmm, is this a ports version of libc++?  I was not aware
> >>> Baptiste
> >>> had already committed this? :)
> >>
> >> Yes, it is (as a build requisite, but apparently remained
> >> installed on the destination machine), because we need to match
> >> the libraries that the requisites use (Glibmm for one).
> >>
> >> I have given up on compiling RawTherapee with clang++ for now,
> >> and use GCC 4.8 on all systems.  RawTherapee is somewhat
> >> demanding, especially at higher optimization level, and kills
> >> the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with
> >> internal compiler errors.  Since GCC 4.8 worked for me, I did
> >> not bother to send Gerald
> >> the details.
> >>
> >> We may want to retry with clang if we've got the next clang
> >> version. Feel free to use Rawtherapee as compiler system test ;)
> >>
> >>
> >>
> >>
> >
> > try with something like this in libmap.conf libc++.so.1
> > /usr/local/lib/libc++.so.1
> > If that fixes the problem, then a rpath with /usr/local/lib should
> > be set while building the port
> 
>  Hmm, I am not very familiar with libmapping. After adding it to
>  /etc/libmap.conf I get
> 
> 
> 
> 
>  #rawtherapee
>  Shared object "/usr/local/lib/libc++.so.1" not found, required by
>  "rawtherapee"
> 
> 
> 
> 
>  Thanks for the tip,
>  Rainer
> 
> 
> 
> 
> >
> > regards, Bapt
> >
> >
>  ___
>  freebsd-ports@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>  To unsubscribe, send any mail to
>  "freebsd-ports-unsubscr...@freebsd.org"
> 
> 
> 
> 
> >>>
> >>>
> >>> Here are a few points regarding rawtherapee on 11.0-CURRENT.
> >>>
> >>>
> >>>
> >>> 1) it builds fine using clang (removing all the gcc4.8 from
> >>> makefile). but still crashes the same.
> >>>
> >>> 2) the parse errors such as
> >>> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> >>> unexpected identifier `colorize_scrollbar', expected character `}'
> >>>
> >>> can be eliminated by installing
> >>> ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks theme
> >>> ported to gtk3
> >>>
> >>> 3) I believe i'be narrowed the crash down to Glib::ustring::format.
> >>> I've
> >>> experimented with various examples and they all crash. Currently
> >>> exploring this problem to see what's up.. anyone have some clue?
> >>>
> >>> here is a sample:
> >>>
> >>> #include 
> >>> #include 
> >>> #include 
> >>>
> >>>
> >>>
> >>> int main() {
> >>>
> >>> double value = 22.0 / 7.0; std::cout << value << std::endl;
> >>> Glib::ustring test =
> >>> Glib::ustring::format(std::fixed,std::setprecision(2),value);
> >>> std::cout << test << std::endl;
> >>>
> >>>
> >>>
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> >>> testglib.cpp $ ./testglib 3.14286
> >>> Abort trap (core dumped)
> >>>
> >>>
> >>>
> >>>
> >>> $ /usr/local/bin/gdb testglib
> >>> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> >>> Copyright (C) 2013 Free Software Foundation, Inc.
> >>> License GPLv3+: GNU GPL version 3 or later
> >>> 
> >>> This is free software: you are free to change and redistribute it.
> >>> There is NO WARRANTY, to the extent permitted by law.  Type "show
> >>> copying" and "show warranty" for details. This GDB was configured as
> >>> "x86_64-portbld-freebsd11.0".
> >>> For bug reporting instructions, please see:
> >>> ...
> >>> Reading symbols from /usr/home/waitman/testglib...done.
> >>> (gdb) run
> >>> Starting program: /usr/home/waitman/testglib
> >>> [New LWP 100327]
> >>> 3.14286
> >>> [New Thread 803006400 (LWP 100327)]
> >>>
> >>>
> >>>
> >>> Program received signal SIGABRT, Aborted.
> >>> [Switching to Thread 803006400 (LWP 100327)]
> >>> 0x000801e313ba in kill () from /lib/libc.so.7
> >>> (gdb) bt
> >>> #0  0x000801e313ba in kill () from /lib/libc.so.7
> >>> #1  0x

Re: Maximizing the use of binary packages and minimizing building packages

[Matthew Seaman]

On 09/02/2014 22:18, Chad Perrin wrote:
> On Tue, Jan 14, 2014 at 11:16:52PM +, Matthew Seaman wrote:
>> On 14/01/2014 19:35, Matt Reimer wrote:
>>> That's good news. What should I watch for in order to know when Really
>>> Soon Now becomes Now?
>>>
>>
>> The release of pkg-1.3.x
> 
> After most of a month (yes, I know that's not all that long), as I
> upgrade Mumble from pkgng to portmaster install to avoid having Qt
> binary package libs destroy X11 functionality with KMS again and watch
> the process destroy my browser instead, I wonder . . .
> 
> Do you have any estimate on how many months Real Soon Now might mean?  I
> swear I won't hold you to a deadline; I would rather it be done right
> than done quickly.  I'm just interested in having something like an
> order-of-magnitude guesstimate for how far in the future Real Soon Now
> will happen.

I can't really say.  The essential code -- the new solver -- has been
committed to the Github master branch.  But there's a lot of work to do
yet to bed that in properly and debug any problems.

We did at one point mutter about making a new branch about every three
months or so, which would put 1.3 release sometime in March.  But that's
way too early IMHO.  "When it's ready."

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
> On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
>
>>
>> On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
>>
>>> On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
>>>
>>>


 On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:


>

> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
>
>
>
>> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>>
>>
>>
>>
>>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
>>> wrote:
>>>
>>>
>>>
>>>
 Am 05.02.2014 21:08, schrieb Dimitry Andric:





>> #17 0x484c0ee0 in
>> std::__1::locale::id::__next_id
>> ()
>> from /usr/local/lib/libc++.so.1
>>
>>
>
> Hmm, is this a ports version of libc++?  I was not aware
> Baptiste
> had already committed this? :)

 Yes, it is (as a build requisite, but apparently remained
 installed on the destination machine), because we need to
 match the libraries that the requisites use (Glibmm for
 one).

 I have given up on compiling RawTherapee with clang++ for
 now, and use GCC 4.8 on all systems.  RawTherapee is
 somewhat demanding, especially at higher optimization level,
 and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
 4.7, all with
 internal compiler errors.  Since GCC 4.8 worked for me, I
 did not bother to send Gerald the details.

 We may want to retry with clang if we've got the next clang
  version. Feel free to use Rawtherapee as compiler system
 test ;)




>>>
>>> try with something like this in libmap.conf libc++.so.1
>>> /usr/local/lib/libc++.so.1
>>> If that fixes the problem, then a rpath with /usr/local/lib
>>> should be set while building the port
>>
>> Hmm, I am not very familiar with libmapping. After adding it to
>>  /etc/libmap.conf I get
>>
>>
>>
>>
>>
>> #rawtherapee
>> Shared object "/usr/local/lib/libc++.so.1" not found, required
>> by "rawtherapee"
>>
>>
>>
>>
>>
>> Thanks for the tip,
>> Rainer
>>
>>
>>
>>
>>
>>>
>>> regards, Bapt
>>>
>>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to
>> "freebsd-ports-unsubscr...@freebsd.org"
>>
>>
>>
>>
>>
>
>
> Here are a few points regarding rawtherapee on 11.0-CURRENT.
>
>
>
>
> 1) it builds fine using clang (removing all the gcc4.8 from
> makefile). but still crashes the same.
>
> 2) the parse errors such as
> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> unexpected identifier `colorize_scrollbar', expected character `}'
>
>
> can be eliminated by installing
> ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
> theme ported to gtk3
>
> 3) I believe i'be narrowed the crash down to
> Glib::ustring::format.
> I've
> experimented with various examples and they all crash. Currently
> exploring this problem to see what's up.. anyone have some clue?
>
> here is a sample:
>
> #include 
> #include 
> #include 
>
>
>
>
> int main() {
>
> double value = 22.0 / 7.0; std::cout << value << std::endl;
> Glib::ustring test =
> Glib::ustring::format(std::fixed,std::setprecision(2),value);
> std::cout << test << std::endl;
>
>
>
>
> }
>
>
>
>
>
> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
>
>
>
>
>
> $ /usr/local/bin/gdb testglib
> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
>  There is NO WARRANTY, to the extent permitted by law.  Type
> "show
> copying" and "show warranty" for details. This GDB was configured
> as "x86_64-portbld-freebsd11.0".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/home/waitman/testglib...done.
> (gdb) run
> Starting program: /usr/home/waitman/testglib
> [New LWP 100327]
> 3.14286
> [New Thread 803006400 (LWP 100327)]
>
>
>
>
> Program received

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Baptiste Daroussin]

On Sun, Feb 09, 2014 at 06:51:28AM -0800, Waitman Gobble wrote:
> 
> On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
> > On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
> >
> >>
> >> On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
> >>
> >>> On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
> >>>
> >>>
> 
> 
>  On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:
> 
> 
> >
> 
> > On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
> >
> >
> >
> >> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
> >>
> >>
> >>
> >>
> >>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
> >>> wrote:
> >>>
> >>>
> >>>
> >>>
>  Am 05.02.2014 21:08, schrieb Dimitry Andric:
> 
> 
> 
> 
> 
> >> #17 0x484c0ee0 in
> >> std::__1::locale::id::__next_id
> >> ()
> >> from /usr/local/lib/libc++.so.1
> >>
> >>
> >
> > Hmm, is this a ports version of libc++?  I was not aware
> > Baptiste
> > had already committed this? :)
> 
>  Yes, it is (as a build requisite, but apparently remained
>  installed on the destination machine), because we need to
>  match the libraries that the requisites use (Glibmm for
>  one).
> 
>  I have given up on compiling RawTherapee with clang++ for
>  now, and use GCC 4.8 on all systems.  RawTherapee is
>  somewhat demanding, especially at higher optimization level,
>  and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
>  4.7, all with
>  internal compiler errors.  Since GCC 4.8 worked for me, I
>  did not bother to send Gerald the details.
> 
>  We may want to retry with clang if we've got the next clang
>   version. Feel free to use Rawtherapee as compiler system
>  test ;)
> 
> 
> 
> 
> >>>
> >>> try with something like this in libmap.conf libc++.so.1
> >>> /usr/local/lib/libc++.so.1
> >>> If that fixes the problem, then a rpath with /usr/local/lib
> >>> should be set while building the port
> >>
> >> Hmm, I am not very familiar with libmapping. After adding it to
> >>  /etc/libmap.conf I get
> >>
> >>
> >>
> >>
> >>
> >> #rawtherapee
> >> Shared object "/usr/local/lib/libc++.so.1" not found, required
> >> by "rawtherapee"
> >>
> >>
> >>
> >>
> >>
> >> Thanks for the tip,
> >> Rainer
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> regards, Bapt
> >>>
> >>>
> >> ___
> >> freebsd-ports@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >> To unsubscribe, send any mail to
> >> "freebsd-ports-unsubscr...@freebsd.org"
> >>
> >>
> >>
> >>
> >>
> >
> >
> > Here are a few points regarding rawtherapee on 11.0-CURRENT.
> >
> >
> >
> >
> > 1) it builds fine using clang (removing all the gcc4.8 from
> > makefile). but still crashes the same.
> >
> > 2) the parse errors such as
> > /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> > unexpected identifier `colorize_scrollbar', expected character `}'
> >
> >
> > can be eliminated by installing
> > ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
> > theme ported to gtk3
> >
> > 3) I believe i'be narrowed the crash down to
> > Glib::ustring::format.
> > I've
> > experimented with various examples and they all crash. Currently
> > exploring this problem to see what's up.. anyone have some clue?
> >
> > here is a sample:
> >
> > #include 
> > #include 
> > #include 
> >
> >
> >
> >
> > int main() {
> >
> > double value = 22.0 / 7.0; std::cout << value << std::endl;
> > Glib::ustring test =
> > Glib::ustring::format(std::fixed,std::setprecision(2),value);
> > std::cout << test << std::endl;
> >
> >
> >
> >
> > }
> >
> >
> >
> >
> >
> > $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> > testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
> >
> >
> >
> >
> >
> > $ /usr/local/bin/gdb testglib
> > GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> > Copyright (C) 2013 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> >  There is NO WARRANTY, to the extent permitted by law.  Type
> > "show
> > copying" and "show warranty" for details

graphics/ufraw fails after icu change

[Lowell Gilbert]

Hi.

The ufraw port has a pre-build target that pulls in a mkinstalldirs
script from (the now outdated) icu. I don't know why that was done, but
it seems to be fine with the one packaged in ufraw.

 - Lowell Gilbert
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Waitman Gobble]

On Sun, February 9, 2014 2:38 pm, Baptiste Daroussin wrote:
> On Sun, Feb 09, 2014 at 06:43:00AM -0800, Waitman Gobble wrote:
>
>>
>> On Sun, February 9, 2014 2:32 pm, Baptiste Daroussin wrote:
>>
>>> On Sun, Feb 09, 2014 at 06:30:02AM -0800, Waitman Gobble wrote:
>>>
>>>


 On Sun, February 9, 2014 4:54 am, Waitman Gobble wrote:


>

> On Wed, February 5, 2014 10:03 pm, Rainer Hurling wrote:
>
>
>
>> Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin:
>>
>>
>>
>>
>>> On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree
>>> wrote:
>>>
>>>
>>>
>>>
 Am 05.02.2014 21:08, schrieb Dimitry Andric:





>> #17 0x484c0ee0 in
>> std::__1::locale::id::__next_id
>> ()
>> from /usr/local/lib/libc++.so.1
>>
>>
>
> Hmm, is this a ports version of libc++?  I was not aware
> Baptiste
> had already committed this? :)

 Yes, it is (as a build requisite, but apparently remained
 installed on the destination machine), because we need to
 match the libraries that the requisites use (Glibmm for
 one).

 I have given up on compiling RawTherapee with clang++ for
 now, and use GCC 4.8 on all systems.  RawTherapee is
 somewhat demanding, especially at higher optimization level,
 and kills the 10.0-RELEASE base clang and Port GCC 4.6 and
 4.7, all with
 internal compiler errors.  Since GCC 4.8 worked for me, I
 did not bother to send Gerald the details.

 We may want to retry with clang if we've got the next clang
  version. Feel free to use Rawtherapee as compiler system
 test ;)




>>>
>>> try with something like this in libmap.conf libc++.so.1
>>> /usr/local/lib/libc++.so.1
>>> If that fixes the problem, then a rpath with /usr/local/lib
>>> should be set while building the port
>>
>> Hmm, I am not very familiar with libmapping. After adding it to
>>  /etc/libmap.conf I get
>>
>>
>>
>>
>>
>> #rawtherapee
>> Shared object "/usr/local/lib/libc++.so.1" not found, required
>> by "rawtherapee"
>>
>>
>>
>>
>>
>> Thanks for the tip,
>> Rainer
>>
>>
>>
>>
>>
>>>
>>> regards, Bapt
>>>
>>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to
>> "freebsd-ports-unsubscr...@freebsd.org"
>>
>>
>>
>>
>>
>
>
> Here are a few points regarding rawtherapee on 11.0-CURRENT.
>
>
>
>
> 1) it builds fine using clang (removing all the gcc4.8 from
> makefile). but still crashes the same.
>
> 2) the parse errors such as
> /usr/local/share/rawtherapee/themes/25-Gray-Gray.gtkrc:96: error:
> unexpected identifier `colorize_scrollbar', expected character `}'
>
>
> can be eliminated by installing
> ports/x11-themes/clearlooks-phenix-theme, this is the clearlooks
> theme ported to gtk3
>
> 3) I believe i'be narrowed the crash down to
> Glib::ustring::format.
> I've
> experimented with various examples and they all crash. Currently
> exploring this problem to see what's up.. anyone have some clue?
>
> here is a sample:
>
> #include 
> #include 
> #include 
>
>
>
>
> int main() {
>
> double value = 22.0 / 7.0; std::cout << value << std::endl;
> Glib::ustring test =
> Glib::ustring::format(std::fixed,std::setprecision(2),value);
> std::cout << test << std::endl;
>
>
>
>
> }
>
>
>
>
>
> $ clang++ -o testglib `pkg-config --cflags --libs glibmm-2.4`
> testglib.cpp $ ./testglib 3.14286 Abort trap (core dumped)
>
>
>
>
>
> $ /usr/local/bin/gdb testglib
> GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
>  There is NO WARRANTY, to the extent permitted by law.  Type
> "show
> copying" and "show warranty" for details. This GDB was configured
> as "x86_64-portbld-freebsd11.0".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/home/waitman/testglib...done.
> (gdb) run
> Starting program: /usr/home/waitman/testglib
> [New LWP 100327]
> 3.14286
> [New Thread 803006400 (LWP 100327)]
>
>
>
>
> Program received

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Dimitry Andric]

On 09 Feb 2014, at 16:07, Waitman Gobble  wrote:
...
> ok, so changing the Makefile for port/devel/glib20
> 
> USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5
> 
> 
> finally solves the problem with graphics/rawtherapee. The program works on
> my FreeBSD 11.0-CURRENT machine without crashing.
> 
> (although it's not really a rawtherapee issue, it's related to glib20).

So, we can cross another one off clang's list? :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

Am 09.02.2014 23:38, schrieb Baptiste Daroussin:

>> "Conversion from character set 'UTF-8' to 'WCHAR_T' is not supported"
>>
> I don't know if glib or glibmm should gain USES=libiconv:wchar_t but that 
> should
> fix it.

Thanks to Waitman for debugging this - very useful work indeed.

Now since that USES= on glib20 fixes the unhandled exceptions on FreeBSD
11, how do we solve this?  Are we making glib20 use the ports iconv by
means of USES=libiconv:wchar_t, or is there a way that I can check from
the Rawtherapee Makefile, so that I can mark Rawtherapee BROKEN or
IGNORE in case glib20 was built without wchar_t support?




signature.asc
Description: OpenPGP digital signature

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Matthias Andree]

Am 10.02.2014 00:01, schrieb Dimitry Andric:
> On 09 Feb 2014, at 16:07, Waitman Gobble  wrote:
> ...
>> ok, so changing the Makefile for port/devel/glib20
>>
>> USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5
>>
>>
>> finally solves the problem with graphics/rawtherapee. The program works on
>> my FreeBSD 11.0-CURRENT machine without crashing.
>>
>> (although it's not really a rawtherapee issue, it's related to glib20).
> 
> So, we can cross another one off clang's list? :-)

No we can't.  Rawtherapee 4.0.12 is using GCC 4.8 exclusively:

- base clang lacks OpenMP support - and OpenMP really speeds up RT if
there are multiple processors to distribute load onto

- base clang still has the pathological compile time/RAM use issue you
filed bugs about when we were discussing Rawtherapee 4.0.11, and GCC 4.6
and 4.7 also crash with internal compiler errors.  Since 4.8 works, I
forwent filing reports because I did not intend to hunt down all those
cases and waive most of the optimizing.

If you want to see how clang fares compiling rawtherapee, use a 10.x
system, remove the USE_GCC and force OpenMP to off (unless you happen to
have an OpenMP-aware clang).



signature.asc
Description: OpenPGP digital signature

Re: graphics/rawtherapee: r342622 crashes on HEAD

[Erich Dollansky]

Hi,

On Sun, 9 Feb 2014 07:07:00 -0800
"Waitman Gobble"  wrote:

> USES=gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5
> 
as you might have expected, this also fixes rawtherapee on 10.0.

Erich
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Mediatomb // recode error.

[justin]

Hi - I just installed:

root@yeaguy:~ # uname -a
FreeBSD yeaguy.com 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 
16 22:34:59 UTC 2014 
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


and I am trying to install:

/usr/ports/net/mediatomb

For some reason, the install is failing at recode.

I am seeing:


===>  Building for recode-3.6_9
--- all-recursive-am ---
/usr/bin/make  all-recursive
--- all-recursive ---
Making all in m4
Making all in doc
Making all in lib
Making all in i18n
Making all in src
--- libiconv.lo ---
--- mule.lo ---
--- names.lo ---
--- libiconv.lo ---
/bin/sh /usr/local/bin/libtool --mode=compile cc 
-DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../lib 
-I/usr/local/include  -I/usr/local/include -DLIBICONV_PLUG  -O2 -pipe 
-fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c libiconv.c

--- mule.lo ---
/bin/sh /usr/local/bin/libtool --mode=compile cc 
-DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../lib 
-I/usr/local/include  -I/usr/local/include -DLIBICONV_PLUG  -O2 -pipe 
-fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c mule.c

--- names.lo ---
/bin/sh /usr/local/bin/libtool --mode=compile cc 
-DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../lib 
-I/usr/local/include  -I/usr/local/include -DLIBICONV_PLUG  -O2 -pipe 
-fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c names.c

--- libiconv.lo ---
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 
-pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c libiconv.c  -fPIC 
-DPIC -o .libs/libiconv.o

--- mule.lo ---
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 
-pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c mule.c  -fPIC -DPIC -o 
.libs/mule.o

--- names.lo ---
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 
-pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c names.c  -fPIC -DPIC 
-o .libs/names.o

--- libiconv.lo ---
libiconv.c:50:3: warning: implicit declaration of function 'iconvctl' is 
invalid in C99 [-Wimplicit-function-declaration]

  iconvctl (conversion, ICONV_SET_TRANSLITERATE, &transliterate);
  ^
libiconv.c:50:25: error: use of undeclared identifier 
'ICONV_SET_TRANSLITERATE'

  iconvctl (conversion, ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:51:33: error: use of undeclared identifier 
'ICONV_SET_TRANSLITERATE'

  iconvctl (conversion_to_utf8, ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:102:8: error: use of undeclared identifier 
'ICONV_SET_TRANSLITERATE'

ICONV_SET_TRANSLITERATE, &transliterate);
^
libiconv.c:104:8: error: use of undeclared identifier 
'ICONV_SET_TRANSLITERATE'

ICONV_SET_TRANSLITERATE, &transliterate);
^
--- names.lo ---
names.c:910:16: warning: format string is not a string literal 
(potentially insecure) [-Wformat-security]

  printf (blanks);
  ^~
--- libiconv.lo ---
1 warning and 4 errors generated.
*** [libiconv.lo] Error code 1

make[3]: stopped in /usr/ports/converters/recode/work/recode-3.6/src
--- mule.lo ---
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 
-pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c mule.c -o mule.o 

/dev/null 2>&1

--- names.lo ---
1 warning generated.
libtool: compile:  cc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. 
-I../lib -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -O2 
-pipe -fPIC -DLIBICONV_PLUG -fno-strict-aliasing -c names.c -o names.o 

/dev/null 2>&1

1 error

make[3]: stopped in /usr/ports/converters/recode/work/recode-3.6/src
*** [all-recursive] Error code 1

make[2]: stopped in /usr/ports/converters/recode/work/recode-3.6
1 error

make[2]: stopped in /usr/ports/converters/recode/work/recode-3.6
*** [all-recursive-am] Error code 2

make[1]: stopped in /usr/ports/converters/recode/work/recode-3.6
1 error

make[1]: stopped in /usr/ports/converters/recode/work/recode-3.6
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure 
to

the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/converters/recode
root@yeaguy:/usr/ports/converters/recode #





Just wondering if there is a work around?


Thanks so much,


Justin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Squid aufs crashes under 10.0

[Pavel Timofeev]

So what should I do?
Write a PR to squid's bugzilla with link to this thread?
Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't
look at PRs about squid).
And it seems like this problem is retaled to all of squid ports, not
only to www/squid33.

2014-02-09 23:56 GMT+04:00 Dimitry Andric :
> On 09 Feb 2014, at 20:16, Dennis Glatting  wrote:
>> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> ...
>>> Very bad coding practice, obviously.  It should call Find() first, and
>>> if that returns NULL, it should abort in some sort of controlled way.
>>>
>>
>> Found that too but not the reason why:
>>
>> (lldb) run -d -z -F -f /root/squid.conf
>> Process 23598 launched: './src/squid' (x86_64)
>> Find(): Mmapped
>> Find(): IpcIo
>> Find(): DiskDaemon
>> Find(): Blocking
>> Find(): AIO
>> Returning NULL
>>
>> There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
>> example, I replaced strlen() with a custom version that first checks for
>> NULL and returns 0 if that is the case (strlen() was often called by
>> std::cstring::c_str() that was not yet initialized). That small code
>> fragment resolved a lot of SEGVs.
>
> There are a bunch of places where they use std::ostream::operator<< to
> output e.g. configuration strings to the debug stream, for example in
> uniqueHostname(), in src/tools.cc:
>
> const char *
> uniqueHostname(void)
> {
> debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'");
> return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname();
> }
>
> The problem case is when Config.uniqueHostname is NULL: this gets
> converted into a std::string first (which is _undefined behavior_), then
> it gets streamed to the debug stream.
>
> However, there is a difference between libstdc++ and libc++ here: the
> former silently accepts NULL arguments passed to the std::string
> constructor, creating a sort of "empty" string for you, which seems to
> work as normal.  The latter just stores your NULL pointer, and if you
> actually try to do anything with it, the program will crash.
>
> To fix at least two places where this is done, drop the attached patches
> in www/squid33/files.
>
> -Dimitry
>
>
>
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"