# rawstudio 2



## mathiasp (Apr 6, 2011)

Hi all,

I just compiled rawstudio 2 RC2, and it dumps core. Running it in *gdb* gives:


```
(gdb) run
Starting program: /usr/local/bin/rawstudio 
[New LWP 100559]
[New Thread 8096041c0 (LWP 100559/initial thread)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8096041c0 (LWP 100559/initial thread)]
0x0000000803e9bbe2 in g_ascii_strcasecmp () from /usr/local/lib/libglib-2.0.so.0
```

I've rebuilt glib without the collation patches, which did not help. I'm really not qualified to investigate this, at least not without help. Any hints on how to find out what's wrong here?

Thanks, Mathias

P.S.:
Compiling the current svn on 8-stable is easy:


```
svn co https://rawstudio.org/svn/rawstudio/trunk/ rawstudio # or branches/vX.Y/
$ cd rawstudio
# remove the function FloatPlanarImage::packInterleavedYUV_SSE4 from plugins/denoise/floatplanarimage-x86.cpp
$ LDFLAGS=/usr/local/lib CFLAGS=/usr/local/include ./autogen.sh
$ gmake
$ su
$ gmake install
```


----------



## SirDice (Apr 6, 2011)

Use graphics/rawstudio.


----------



## mathiasp (Apr 6, 2011)

I'm trying to get rawstudio 2.0 into shape, so graphics/rawstudio can be updated easily when 2.0 will be released (planned for april 7th)


----------



## SirDice (Apr 6, 2011)

It's possible the svn is a work in progress, have you tried any of the release candidates? 

The easiest would probably be to edit the existing port. If it crashes it's most likely a problem in the code itself and should be fixed there.

In any case I'd contact the port's maintainer, perhaps he's already working on it.


----------



## mathiasp (Apr 6, 2011)

It's rc2, and I've mailed the maintainer.

Another data point: *rawstudio -d debug* starts fine. Some UI dialogs still crash it, but otherwise everything works...

Anyone seen something like this before?

Thanks, Mathias


----------



## expl (Apr 6, 2011)

You need to look at the full backtrace not just the line that caused actual segfault, go all the way up the trace, find that line in actual source code and look at the code before it looking for possible mishandling of memory.


----------



## mathiasp (Apr 7, 2011)

Yes, I already found that out. I'm not really at home in C and gdb. And this problem is solved, rs2 works fine here.

Now on to another FreeBSD specific thing: where / how is __BSD_VISIBLE defined. If I look at the end of sys/cdefs.h, it seems as if it should be defined by default ("most general case"), but it's obviously not, since rawstudio can't find _SC_NPROCESSORS_ONLN. If I define __BSD_VISIBLE before unistd.h is included, everything works fine.

So what is the preferred was of defining __BSD_VISIBLE defined, save for just putting a define in the source file, which I guess is not really the idea here...


----------



## mathiasp (Apr 7, 2011)

Sorry for the horrible typos, using my smartphone


----------



## mathiasp (Apr 7, 2011)

*XOPEN_SOURCE vs __BSD_VISIBLE, detecting os versions*

I'm trying to port rawstudio 2, which has _XOPEN_SOURCE defined (so glibc can find realpath, it seems). 

This hides __BSD_VISIBLE, which is needed to detect the number of processors with sysconf(_SC_NPROCESSORS_ONLN) (_SC_NPROCESSORS_ONLN is not posix, it seems).

What is a good way to handle this? From the Porter's Handbook I get the impression that using __FreeBSD__ is frowned upon, but what do I test for, to not/include _XOPEN_SOURCE?

From the man page it seems _SC_NPROCESSORS_ONLN found its way into FreeBSD 5.0, but is there a BSD-wide way to find this out?


----------



## roddierod (Apr 7, 2011)

It doesn't seemed frowned on to me, just make sure your change is FreeBSD specific.

You might want to try @hackers or @ports mailing list for something like this.


----------



## DutchDaemon (Apr 7, 2011)

[ threads merged, no need for two separate ones ]


----------

