volume now in PMO?
I take it that volume stuff will now be exclusively in the PMO, and that there'll now be no VolumeManager classes any more?
Re: cvs configure.in
> The following patch is needed in cvs to sync up configure and > Makefile-plugin. Fixed. (also fixed the ncurses and esound instances, too.)
a small reminder about the freeamp-lignux.ui => freeamp.ui change...
You'll probably want to edit your ~/.freeamp_prefs file so that it doesn't mention your OS in the ui section. i.e. UI: freeamp-solaris.ui => UI: freeamp.ui
NAME_MAX in win32impl.cpp (branch-1-5)?
Should NAME_MAX (around line 160 in base/unix/src/win32impl.cpp in the release-1-5 branch) be PATH_MAX? NAME_MAX isn't defined on Solaris (and I think it only refers to the old, old sysV max length of filenames - i.e. 14 chars)
Re: MAX_PATH
> someone had brought up the question about the length of a path. does > anyone have a good way of figuring it out for a platform? I'd use some arbitrary number, like 256, because a) there seems to be few standard #defines for it, and b) filename length is filesystem dependent anyway.
just remember with release-1-5...
That you probably want to do a 'make depend; make' or 'make clean; make' after particularly large numbers of files have changed OR .h files get modified; not doing so can cause some nasty (and nearly untracable) things to happen. FWIW, it compiled and seems to be running fine on solaris (except for one niggling 'cannot find symbol' error.) Also, it looks like the most recent set o' changes to Makefile.in weren't propogated to the 1-5 branch; I may check those in relatively soon.
release-1-5 theme.ui needs a 'Initialize' symbol
That's pretty much about it. theme.ui needs 'Initialize', or the loader (and gdb) get cranky.
Re: Maximizing Bandwidth
> I am working on the download manager that will be included in 1.5. What > I would like to do is offer the option to maximize your available > bandwidth. Maybe that is not the correct term. What I want to do is > given n items to download figure out how many concurrent items can be > downloaded without oversaturating your connection. What I was thinking > of doing was to add downloads until i saw a drop in the amount of data > being received across all the downloads. Then pause the last one and > wait till one of the previous items finished then continue. This sounds > over simplistic though. Perhaps I should just let users specify the > total number of downloads they want concurrently but it would be great > if we could figure itout for them. Anyone with any experience in this > stuff? You may want to do downloads with UDP, and have the client send a "whoa, I'm losing too many packets; throttle back n%" when things start getting lossy (with perhaps a creep-back-up timer, too.)
Re: Maximizing Bandwidth
> > You may want to do downloads with UDP, and have the client send a "whoa, > > I'm losing too many packets; throttle back n%" when things start getting > > lossy (with perhaps a creep-back-up timer, too.) > > As long as your window size is set greater than or equal to the > bandwidth delay product, that's exactly what TCP achieves. Except > that it does it with at least 20 years of experience behind it. ;-} > > In general, trying to reproduce what TCP does on lossy networks using > any datagram protocol is a losing proposition, usually because most > implementors get the congestion control aspects wrong the first half > dozen or so times they try to implement it. Yes, I agree with this. However, if you're trying to do something like play an mp3 stream while downloading other streams in the background, TCP won't let you do prioritized connections. (I suppose I was answering a question Elrod hadn't asked. :) )
Re: your mail
> i need an advice, which is the simpler: > 1. rip off the xing player to use it in my car mp3 player or > 2. build a full freeamp ui? > > for me it seems that to extract the xing player module is pretty easy and > can be done by slightly modifying the surrounding lmc object to make it a > bit more independent from freeamp. > but i prefer to code a ui, because you already have the majority of the > classes i will also need. > can anybody tell me how big deal is to code a full ui? Have you looked at the lcd UI? It's designed for a LCD screen, as would be used in a portable or car mp3 player. (FWIW, the command-line UI plugin is 200 lines of code.)
gcc & Themes
gcc 2.95 doesn't like Theme.cpp: ui/theme/src/Theme.cpp: In method `enum Error Theme::BeginElement(string &, map,__default_alloc_template >,basic_string,__default_alloc_template >,less,__default_alloc_template > >,allocator,__default_alloc_template > > > &)': ui/theme/src/Theme.cpp:150: cannot allocate an object of type `GTKWindow' ui/theme/src/Theme.cpp:150: since the following virtual functions are abstract: ui/theme/include/Window.h:89: enum Error Window::Run(Pos &) ui/theme/include/Window.h:90: enum Error Window::Close() ui/theme/include/Window.h:102: enum Error Window::SetWindowPosition(Rect &) ui/theme/include/Window.h:103: enum Error Window::GetWindowPosition(Rect &) ui/theme/src/Theme.cpp:196: warning: unused variable `struct Rect oRect' make[1]: *** [ui/theme/src/Theme.o] Error 1 (nice method line, eh?)
Re: 1.5 on linux?
> I can compile it, but can't run. I get this: > flocsy@crux:~/work/freeamp/freeamp15$ ./freeamp > /mp3/Ellenorzott/D/Dragana\ -\ Up\ And\ Down.mp3 > /home/flocsy/work/freeamp/freeamp/plugins/freeampcmd.ui: undefined symbol: > SetFirst__15PlayListManager make clean; make. If your system can handle `make depend`, you should do so after CVS updates; changes in the header files can cause things to not link properly.
extreme solaris wackiness
Well, I think I'm getting closer to finding what's causing the Solaris strangeness; for one, it appears that sometimes the LWP or Reader gets stuck, and so WasteTime() gets called an awful lot. A side effect seems to be the creation of several hundred threads. :) (gdb) info threads 640 Thread 511 0xff04b7dc in _restorefsr () from /usr/lib/libthread.so.1 639 Thread 510 0xff04b7dc in _restorefsr () from /usr/lib/libthread.so.1 and so on.
LocalFileInput race condition, somewhere.
When I click too quickly on the 'next song' button, it appears that m_pSleepSem gets set somewhere, but doesn't get released. I suspect that there's something funny going on with the ->Signal() call, but I can't say for sure yet.
even more solaris ranting
I've gotten the strangest hang yet. It's hanging inside of Player::EventServiceThreadfunc, at pP->m_eventSem->Wait(). The kicker is that there are no other threads alive that even reference that semaphore! In fact, the only place that this particular variable is used is player.cpp. a (long) backtrace follows. (gdb) set height 0 (gdb) thr ap al bt Thread 14 (Thread 4 (LWP 6)): #0 0xff115c90 in _poll () from /usr/lib/libc.so.1 #1 0xff0ce674 in select () from /usr/lib/libc.so.1 #2 0xff04b1d4 in select () from /usr/lib/libthread.so.1 #3 0xff2f3514 in _XRead () from /usr/openwin/lib/libX11.so.4 #4 0xff2f7e58 in _XReadEvents () from /usr/openwin/lib/libX11.so.4 #5 0xff2f445c in XNextEvent () from /usr/openwin/lib/libX11.so.4 #6 0xfe5325ec in FreeAmpUI::X11EventService (this=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:545 #7 0xfe532528 in FreeAmpUI::x11ServiceFunction (p=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:509 #8 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #9 0x417a8 in solarisThread::internalThreadFunction (arg=0x87768) at base/unix/solaris/src/solaristhread.cpp:64 Thread 13 (LWP13): #0 0xff11501c in door_restart () from /usr/lib/libc.so.1 Thread 12 (LWP12): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 11 (LWP11): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 10 (LWP10): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 9 (LWP9): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 8 (LWP8): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 7 (LWP7): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 6 (LWP6): #0 0xff115c90 in _poll () from /usr/lib/libc.so.1 #1 0xff0ce674 in select () from /usr/lib/libc.so.1 #2 0xff04b1d4 in select () from /usr/lib/libthread.so.1 #3 0xff2f3514 in _XRead () from /usr/openwin/lib/libX11.so.4 #4 0xff2f7e58 in _XReadEvents () from /usr/openwin/lib/libX11.so.4 #5 0xff2f445c in XNextEvent () from /usr/openwin/lib/libX11.so.4 #6 0xfe5325ec in FreeAmpUI::X11EventService (this=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:545 #7 0xfe532528 in FreeAmpUI::x11ServiceFunction (p=0x8cb08) at ui/freeamp/unix/src/freeamp.cpp:509 #8 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #9 0x417a8 in solarisThread::internalThreadFunction (arg=0x87768) at base/unix/solaris/src/solaristhread.cpp:64 Thread 5 (LWP5): #0 0xff117a28 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff10f7c0 in _lwp_cond_timedwait () from /usr/lib/libc.so.1 #2 0xff03a730 in _age () from /usr/lib/libthread.so.1 Thread 4 (LWP4): #0 0xff117544 in _sigsuspend () from /usr/lib/libc.so.1 #1 0xff0499f4 in sigsuspend () from /usr/lib/libthread.so.1 #2 0xff0d6c44 in _usleep () from /usr/lib/libc.so.1 #3 0xff04b274 in usleep () from /usr/lib/libthread.so.1 #4 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #5 0x417a8 in solarisThread::internalThreadFunction (arg=0x87790) at base/unix/solaris/src/solaristhread.cpp:64 Thread 3 (LWP3): #0 0xff117a74 in _lwp_sema_wait () from /usr/lib/libc.so.1 #1 0xff03b04c in _park () from /usr/lib/libthread.so.1 #2 0xff03ad40 in _swtch () from /usr/lib/libthread.so.1 #3 0xff039a00 in cond_wait () from /usr/lib/libthread.so.1 #4 0xff039924 in pthread_cond_wait () from /usr/lib/libthread.so.1 #5 0x41b5c in Semaphore::Wait (this=0x886e8) at base/unix/solaris/src/semaphore.cpp:50 #6 0x313c8 in Player::EventServiceThreadFunc (pPlayer=0x885a0) at base/src/player.cpp:585 #7 0x417d0 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #8 0x417a8 in solarisThread::internalThreadFunction (arg=0x877b8) at base/unix/solaris/src/solaristhread.cpp:64 Thread 2 (LWP2): #0 0xff117444 in _signotifywait () from /usr/lib/libc.so.1 #1 0xff03f598 in _dynamiclwps () from /usr/lib/libthread.so.1 Thread 1 (LWP1
Re: 1.5 on linux?
> > If your system can handle `make depend`, you should do so after CVS > > Hmm. The problem is that I do this every time: > cd freeamp/cvs ; cvs -d update ; cd .. > cp -R cvs/freeamp freeamp ; cd freeamp > ./configure ; make Right after ./configure, you still want to do `make clean` before doing `make`.
Re: extreme solaris wackiness
> > Well, I think I'm getting closer to finding what's causing the > > Solaris strangeness; for one, it appears that sometimes the LWP > > or Reader gets stuck, and so WasteTime() gets called an awful > > lot. A side effect seems to be the creation of several hundred > > threads. :) > > Wow -- there is some *strange* shit going on over there. Have you taken > a look at the solaris implementation of all the Thread/Mutex/Semaphore > stuff? Yeah, I have. With the difference of everything that says 'linux' saying 'solaris' instead, minor differences in spacing, and the fact that the solaris bit does pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK); if under Sol 2.7, the two sources are identical. I'm gonna try disabling the errorcheck mutexen, but I ain't hopeful that it'll do much good.
Re: Half success
> ./plugins/ncurses.ui: undefined symbol: color_set > > I have ncurses4.2, gdk1.0.6 from potato(debian). > Is it the same at your linux? Do they work on any potato? Well, I don't have a linux, but I'll answer anyway. :) It seems that only newer versions of ncurses have color_set; since yours doesn't, just add #define color_set(a,b) ; somewhere near the beginning of ncursesUI.cpp (or .h)
Re: buttons.bmp
> H. The buttons.bmp bitmap in the ui/theme/default directory keeps > getting corrupted in check in. I did > > cvs admin -kb buttons.bmp mask.bmp background.bmp > > But the files still get screwed up. What other magic incantations do I need > to carry out for CVS to be happy? We have rcs 5.7 installed on the server... did you cvs ci -kb the files, too? (I believe you have to co -kb or up -kb as well so that they don't get zorched.)
worrisome error in 1-5 downloadmanager.cpp
base/src/downloadmanager.cpp:799: warning: name lookup of `end' changed for new ANSI `for' scoping base/src/downloadmanager.cpp:796: warning: using obsolete binding at `end' and cvs.freeamp.org needs to start running ntp. :)
more 1-5 build woes with gcc-2.95.1
c++ -I. -I. -I./config -DUNIX_LIBDIR=\"/usr/local/lib\" -Dsolaris -Ilib/gdbm -Ibase/include -Iconfig -Iio/include -Iui/include -Ilmc/include -Ibase/unix/include -Ibase/unix/solaris/include -Iui/freeamp/unix/include -Iui/freeamp/unix/res -Iio/soundcard/unix/solaris/include -Iui/lcd/include -Iui/irman/include -Ilmc/xingmp3/include -Iplm/portable/pmp300/sba -Ilib/xml/include -Wall -Wno-return-type -g -O2 -I/usr/openwin/include -fpermissive -DSOLDEBUGMUTEX -D_REENTRANT -c base/src/downloadmanager.cpp -o base/src/downloadmanager.o /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/stl_deque.h: In method `struct _Deque_iterator deque,0>::erase(_Deque_iterator)': base/src/downloadmanager.cpp:307: instantiated from here /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/stl_deque.h:818: warning: comparison between signed and unsigned base/src/downloadmanager.cpp: In method `enum Error DownloadManager::Download(DownloadItem *)': base/src/downloadmanager.cpp:597: warning: int format, different type arg (arg 4) base/src/downloadmanager.cpp:605: warning: int format, different type arg (arg 4) base/src/downloadmanager.cpp:746: warning: comparison between signed and unsigned base/src/downloadmanager.cpp:855: warning: comparison between signed and unsigned base/src/downloadmanager.cpp:567: warning: `char * file' might be used uninitialized in this function base/src/downloadmanager.cpp: In method `void DownloadManager::SaveResumableDownloadItems()': base/src/downloadmanager.cpp:1155: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1156: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1158: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1159: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1169: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1170: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1172: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1173: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1175: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1176: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1178: request for member `size' in `num.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp:1179: no matching function for call to `ostrstream::str (const char[1])' /usr/local/pkg/gcc-2.95.1-full/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../include/g++-3/strstream.h:97: candidates are: char * ostrstream::str() base/src/downloadmanager.cpp:1199: request for member `c_str' in `ost.ostrstream::str()', which is of non-aggregate type `char *' base/src/downloadmanager.cpp: In method `void DownloadManager::LoadResumableDownloadItems()': base/src/downloadmanager.cpp:1223: warning: suggest parentheses around assignment used as truth value make: *** [base/src/downloadmanager.o] Error 1
Re: theme.ui architecture
> I must say I am a little lost. Where is that theme.ui everybody's > talking about ? I took the latest freeamp from CVS but I can't find anything > about a theme UI in it. Any idea ? it's on the release-1-5 branch. And it and gcc-2.95.1 do not seem to want to play nicely. I'm working on it, though... stupid templates.
Re: theme.ui architecture
> > it's on the release-1-5 branch. > > > > And it and gcc-2.95.1 do not seem to want to play nicely. I'm working on > > it, though... stupid templates. > > Compiles with 2 minor warnings in FreeAmpTheme.cpp with gcc-2.95.2pre2 here... Oh, it _compiles_... it just fails when you try to run the sucker: ld.so.1: ./freeamp: fatal: relocation error: file ./plugins/theme.ui: symbol cop y__t18string_char_traits1ZcPcPCcUi: referenced symbol not found However, compiling with -fsquangle seems to get around this. It's definitely a bug in gcc 2.95.1, though. Incidentally, adding -fsquangle makes everything compile _and_ run, but it fails with "base/src/database.cpp:47: failed assertion `m_dbase'"
GetPrefString(kSaveMusicDirPref...) fails.
Specifically, at line 149: m_context->prefs->GetPrefString(kSaveMusicDirPref, tempDir, &length); It goes into happy hash land and fails miserably, and returns null; then, because it's null it fails on the MKDIR, the metadatabase stuff goes in the toilet, and then the lovely error base/src/database.cpp:47: failed assertion `m_dbase' pops up. (This is sol 2.7, gcc 2.95.1.)
sigh.
Well, it looks like there are some rather nasty lurking bugs in
gcc-2.95.1; bugs that popped up when things were compiled with -O2 went
away when compiled with -O; I'm beginning to suspect that the alias
analysis code is a bit stricter than a lot of programmers out there.
Anyway, I was getting crashes in code Theme.cpp in ParseColor, when
I inserted the extra lines (@845)
char *foo = oColorstring.c_str();
printf("colors: %s; ocolor: %lx", foo, &oColor);
And then the crashing stopped; unfortunately, the printf never showed
itself, and the crash has occured deeper in the code in GTK/glib land:
(gdb) bt
#0 0xff2fdd74 in XGetWindowAttributes () from /usr/openwin/lib/libX11.so.4
#1 0xfe3dcae8 in gdk_window_foreign_new (anid=0) at gdkwindow.c:508
#2 0xfe2ce478 in GTKBitmap::GTKBitmap (this=0x171198, oName=@0x99a9c)
at ui/theme/unix/src/GTKBitmap.cpp:59
#3 0xfe2a2294 in Theme::BeginElement (this=0x16d2c4, oElement=@0xffbe34f0,
oAttrMap=@0xffbe33f0) at ui/theme/src/Theme.cpp:296
#4 0x4ff94 in Parse::DoParse (this=0x16d2c4) at lib/xml/src/Parse.cpp:225
#5 0x4efcc in Parse::ParseFile (this=0x16d2c4, oFile=@0xffbe38d0)
at lib/xml/src/Parse.cpp:61
#6 0xfe2a0748 in Theme::LoadTheme (this=0x16d2c4, oFile=@0xffbe3b08)
at ui/theme/src/Theme.cpp:155
#7 0xfe2c0254 in FreeAmpTheme::LoadFreeAmpTheme (this=0x16d2c0)
at ui/theme/src/FreeAmpTheme.cpp:151
#8 0xfe2bfb10 in FreeAmpTheme::FreeAmpTheme (this=0x16d2c0, context=0x966f0)
at ui/theme/src/FreeAmpTheme.cpp:83
#9 0xfe2bf72c in Initialize (context=0x966f0)
at ui/theme/src/FreeAmpTheme.cpp:59
#10 0x3243c in Player::Run (this=0x98708) at base/src/player.cpp:645
#11 0x49508 in main (argc=709, argv=0xffbe3f44)
at base/unix/src/bootstrap.cpp:132
the last bit of code that's in freeamp proper is frame #3,
#3 0xfe2a2294 in Theme::BeginElement (this=0x16d2c4, oElement=@0xffbe34f0,
oAttrMap=@0xffbe33f0) at ui/theme/src/Theme.cpp:296
296pBitmap = new GTKBitmap(oAttrMap["Name"]);
Which isn't inspiring confidence in me.
At this point, I'm thinking of trying the egcs-current source, and
seeing if those mollify any bugs; it looks like the bleeding-edge
template stuff is causing gcc (or me, for that matter) to not be a
Happy Boy. (The fact that linkage problems mysteriously go away
with -fsquangle do not fill me with joy, either.)
Does any of this crap show up in linux, particularly the x86 flavors?
(solaris) hang in theme.ui playlist editor
This is after opening a playlist. It whirs quite a bit, and then hangs here in this gigantic backtrace: Thread 4 (LWP4): #0 0xff1179b0 in ___lwp_mutex_lock () from /usr/lib/libc.so.1 #1 0xff03c674 in _mutex_lwp_lock () from /usr/lib/libthread.so.1 #2 0xff03c370 in _cmutex_lock () from /usr/lib/libthread.so.1 #3 0xfe3befb4 in gdk_threads_enter () at gdk.c:1415 #4 0xfe5c2544 in MusicBrowserUI::LoadPlaylist (this=0x16ca38, path=0x16cb90 "/usr/local/src/fa15/biteme.m3u") at ui/musicbrowser/unix/musicbrowser.cpp:312 #5 0xfe5bfeac in open_list () at ui/musicbrowser/unix/gtkmusicbrowser.cpp:765 #6 0xfe4b4f28 in gtk_item_factory_callback_marshal (widget=0x0, func_data=0x191d00) at gtkitemfactory.c:258 #7 0xfe4cb200 in gtk_marshal_NONE__NONE (object=0x18fce8, func=0xfe4b4f00 , func_data=0x191d00, args=0xfde7ee20) at gtkmarshal.c:312 #8 0xfe50cb30 in gtk_handlers_run (handlers=0x183b10, signal=0xfde7ed68, object=0x18fce8, params=0xfde7ee20, after=0) at gtksignal.c:1909 #9 0xfe50ba0c in gtk_signal_real_emit (object=0x18fce8, signal_id=71, params=0xfde7ee20) at gtksignal.c:1469 #10 0xfe508aac in gtk_signal_emit (object=0x18fce8, signal_id=71) at gtksignal.c:552 #11 0xfe553630 in gtk_widget_activate (widget=0x1) at gtkwidget.c:2869 #12 0xfe4d61c8 in gtk_menu_shell_activate_item (menu_shell=0x191970, menu_item=0x18fce8, force_deactivate=1) at gtkmenushell.c:839 #13 0xfe4d4cc8 in gtk_menu_shell_button_release (widget=0x191970, event=0x184a78) at gtkmenushell.c:485 #14 0xfe4caf90 in gtk_marshal_BOOL__POINTER (object=0x191970, func=0xfe4d4a30 , func_data=0x0, args=0xfde7f460) at gtkmarshal.c:28 #15 0xfe50ba54 in gtk_signal_real_emit (object=0x191970, signal_id=21, params=0xfde7f460) at gtksignal.c:1484 #16 0xfe508aac in gtk_signal_emit (object=0x191970, signal_id=21) at gtksignal.c:552 #17 0xfe553390 in gtk_widget_event (widget=0x191970, event=0x184a78) at gtkwidget.c:2843 #18 0xfe4caf1c in gtk_propagate_event (widget=0x191970, event=0x184a78) at gtkmain.c:1313 #19 0xfe4c9d54 in gtk_main_do_event (event=0x184a78) at gtkmain.c:770 #20 0xfe3ccd7c in gdk_event_dispatch (source_data=0x184a78, current_time=0xfde7fa30, user_data=0x0) at gdkevents.c:2129 #21 0xfe326fe8 in g_main_dispatch (current_time=0xfde7fa30) at gmain.c:656 #22 0xfe327800 in g_main_iterate (block=-30096544, dispatch=1) at gmain.c:874 #23 0xfe327a10 in g_main_run (loop=0x174b78) at gmain.c:932 #24 0xfe4c9444 in gtk_main () at gtkmain.c:476 #25 0xfe5c1804 in MusicBrowserUI::GTKEventService (this=0x16ca38) at ui/musicbrowser/unix/musicbrowser.cpp:99 #26 0xfe5c16c4 in MusicBrowserUI::gtkServiceFunction (p=0x16ca38) at ui/musicbrowser/unix/musicbrowser.cpp:75 #27 0x48e94 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #28 0x48e6c in solarisThread::internalThreadFunction (arg=0x9bdf0) at base/unix/solaris/src/solaristhread.cpp:64 Thread 1 (LWP1): #0 0xff117a74 in _lwp_sema_wait () from /usr/lib/libc.so.1 #1 0xff03b04c in _park () from /usr/lib/libthread.so.1 #2 0xff03ad40 in _swtch () from /usr/lib/libthread.so.1 #3 0xff039654 in cond_timedwait () from /usr/lib/libthread.so.1 #4 0xff049838 in sleep () from /usr/lib/libthread.so.1 #5 0xfe251554 in GTKWindow::Run (this=0x17c220, oPos=@0x400) at ui/theme/unix/src/GTKWindow.cpp:156 #6 0xfe224e1c in Theme::Run (this=0x17c17c, oWindowPos=@0x17c200) at ui/theme/src/Theme.cpp:339 #7 0xfe2438c8 in FreeAmpTheme::WorkerThread (this=0x17c178) at ui/theme/src/FreeAmpTheme.cpp:106 #8 0xfe2439ac in WorkerThreadStart (arg=0x17c178) at ui/theme/src/FreeAmpTheme.cpp:119 #9 0x48e94 in solarisThread::InternalThreadFunction (this=0x0) at base/unix/solaris/src/solaristhread.cpp:78 #10 0x48e6c in solarisThread::internalThreadFunction (arg=0x17e6d0) at base/unix/solaris/src/solaristhread.cpp:64 #0 0xff117a74 in _lwp_sema_wait () from /usr/lib/libc.so.1 (the last line is wacky because I attached with gdb after the fact. At least, I hope that's the reason.)
dropping out for a while...
I've switched jobs, and no longer have as ready access to Sun boxen, and even less Copious Free Time than I had before; I'm afraid I won't be able for quite a while to be the Solaris Compatability Nazi :)
Re: ANNOUNCE: FreeAmp 2.0 Beta 2 released
> no problem with ./configure and make, but when tried to run: > > ./plugins/musicbrowser.ui: undefined symbol: g_thread_init > ./plugins/freeamp.ui: undefined symbol: g_thread_init > ./plugins/download.ui: undefined symbol: g_thread_init >./plugins/freeamp.ui: undefined symbol: g_thread_init > > my gthread lib is libgthread-1.2.so.0.0.3 > > any clues? This probably means that glib was not compiled with threads enabled; if so, you get to recompile glib AND gtk! woo woo!
Re: placement of Makefile.header.in?
> Is there any strong reason for putting Makefile.header.in in the config/ > subdir? I'm attempting to get freeamp building in a dir other than the srcdir, > and having Makefile.header.in in a subdir is messing things up.. If there's no > objections, I'll move it to the root source dir. Not that I'm aware of.
