Menu
▾
▴
jazzplusplus-devel — Discussion Forum for Jazz Developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(189) |
Apr
(40) |
May
(8) |
Jun
(6) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(13) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(7) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(8) |
Oct
(19) |
Nov
(19) |
Dec
(7) |
| 2007 |
Jan
(6) |
Feb
(6) |
Mar
(3) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(1) |
Mar
(40) |
Apr
(31) |
May
(174) |
Jun
(24) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(64) |
Dec
(17) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Björn P. <bjo...@gm...> - 2008-12-24 02:31:33
|
Meanwhile I have compiled wx with vc9 according to instructions on the website. That VC was idling around on my harddisk. BTW: I had to give them my e-mail for registering!!! ;-) but... I could not wait to see something. Fine. And: I found a #BUG! :-) ...in MetronomeSettingsDialog.cpp +85 (constructor) Menu: Settings->Metronome << mIndexToName is used (indexed [0]) but empty. As for ansi/unicode: I'll give it a try. Gcc on windows is basically the same as on linux but the mingw/codeblocks approach wo wx has recently gained much momentum on windows, so this might attract more people to jazz++ (how many active devs are around here actually?) On the other hand... I don't know what release-plans are, but by the time jazz++ will be ready for prime-time we might also see wx-2.9 -> 3.0 around. So maybe I'd vote for an intermediate branch, but that's not really important for now, as you stated. As for the deprecated proplist-thingy, what are your plans on this? Ok, enough now. I will spend some time looking into the source, that will keep me busy enough for the next time. Greetings, Björn Am 24.12.2008 01:32 schrieb Pete Stieber: > BP = Björn Pfeiffer > BP> Hi everybody, > BP> I just recently stumbled upon this project > BP> looking for a simple midi-recorder for windows. > > We're not recording yet, but I'm starting to work with the > portmedia/portmidi project to make this happen. > BP> Looks like something I'd like to get involved in. > > Sounds great. > > BP> I am working with a mingw (tdm-4.3) and codeblocks > BP> workbench on XP here (not too keen on setting up > BP> vc for this) so i tried to go along importing the > BP> vc projects in codeblocks, adjusting the > BP> compiler-settings, patching the source. I found > BP> that this is a pure ansi project, while my wx2.8 > BP> being built unicode. > > I would be interested in an ANSI + STL wxWidgets 2.8.9 build using MinGW > for CodeBlocks. Would you like to take a crack at that? > > BP> So having read about the new wxString implementation > BP> in wx2.9 - that has unicode/ansi merged with fancy > BP> constructors from char*, std::string etc - I > BP> continued with that, patching the source > BP> (mostly char* <> wxString conversions). > > We don't need this. Note that we build wxWidgets with wxUSE_STL and it > gets around this problem. > > BP> But after some time I had to stop short on this > BP> (marked deprecated) proplist thing, that just > BP> doesn't want to compile for 2.9 anymore. > > For now we are sticking with wx 2.8.* until 3.0.* is out and is stable > w.r.t. the API. > > BP> Long story, just a few questions: > BP> - Are there efforts for a mingw port/setup? > > No, but this would be welcome. > > BP> I do not mean to switch and not for releases > BP> (for executable size is pretty bad compared to vc), > BP> just as an alternative for the devs. > > I like the idea because the more platforms/compilers you build a code > with, the better the code gets because each platform/compiler highlights > different issues. > > BP> - Could anybody upload a binary (windows)? > BP> I'd like to get an idea of what the prop-thing > BP> practically does (plan to replace it with > BP> something else). > > I might take a crack at this over the weekend or possibly email you a > version directly. > > BP> - Why no intermediate nightly builds for win32? > > The code just isn't ready for this. > > BP> - What about migrating the wx-version to > BP> 2.9 => wx30? Maybe (probably) in a separate > BP> branch. > > I would prefer to skip 2.9 and wait until 3.0 is out and stable. To > many other problems with Jazz++ to deal with this at the moment. > > BP> Big hello for a start. > > Same here :-) > > BP> Looking forward to your opinions on these ideas. > BP> > BP> But for now: > BP> Happy Xmas everybody ! > > Merry Christmas to you Björn. > > Pete > > ------------------------------------------------------------------------------ > _______________________________________________ > jazzplusplus-devel mailing list > jaz...@li... > https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel > |
|
From: Pete S. <pst...@gm...> - 2008-12-24 00:33:06
|
BP = Björn Pfeiffer BP> Hi everybody, BP> I just recently stumbled upon this project BP> looking for a simple midi-recorder for windows. We're not recording yet, but I'm starting to work with the portmedia/portmidi project to make this happen. BP> Looks like something I'd like to get involved in. Sounds great. BP> I am working with a mingw (tdm-4.3) and codeblocks BP> workbench on XP here (not too keen on setting up BP> vc for this) so i tried to go along importing the BP> vc projects in codeblocks, adjusting the BP> compiler-settings, patching the source. I found BP> that this is a pure ansi project, while my wx2.8 BP> being built unicode. I would be interested in an ANSI + STL wxWidgets 2.8.9 build using MinGW for CodeBlocks. Would you like to take a crack at that? BP> So having read about the new wxString implementation BP> in wx2.9 - that has unicode/ansi merged with fancy BP> constructors from char*, std::string etc - I BP> continued with that, patching the source BP> (mostly char* <> wxString conversions). We don't need this. Note that we build wxWidgets with wxUSE_STL and it gets around this problem. BP> But after some time I had to stop short on this BP> (marked deprecated) proplist thing, that just BP> doesn't want to compile for 2.9 anymore. For now we are sticking with wx 2.8.* until 3.0.* is out and is stable w.r.t. the API. BP> Long story, just a few questions: BP> - Are there efforts for a mingw port/setup? No, but this would be welcome. BP> I do not mean to switch and not for releases BP> (for executable size is pretty bad compared to vc), BP> just as an alternative for the devs. I like the idea because the more platforms/compilers you build a code with, the better the code gets because each platform/compiler highlights different issues. BP> - Could anybody upload a binary (windows)? BP> I'd like to get an idea of what the prop-thing BP> practically does (plan to replace it with BP> something else). I might take a crack at this over the weekend or possibly email you a version directly. BP> - Why no intermediate nightly builds for win32? The code just isn't ready for this. BP> - What about migrating the wx-version to BP> 2.9 => wx30? Maybe (probably) in a separate BP> branch. I would prefer to skip 2.9 and wait until 3.0 is out and stable. To many other problems with Jazz++ to deal with this at the moment. BP> Big hello for a start. Same here :-) BP> Looking forward to your opinions on these ideas. BP> BP> But for now: BP> Happy Xmas everybody ! Merry Christmas to you Björn. Pete |
|
From: Björn P. <bjo...@gm...> - 2008-12-23 23:35:30
|
Hi eberybody, I just recently stumpled upon this project looking for a simple midi-recorder for windows. Looks like something I'd like to get involved in. I am working with a mingw (tdm-4.3) and codeblocks workbench on XP here (not too keen on setting up vc for this) so i tried to go along importing the vc projects in codeblocks, adjusting the compiler-settings, patching the source. I found that this is a pure ansi project, while my wx2.8 being built unicode. So having read about the new wxString implementation in wx2.9 - that has unicode/ansi merged with fancy constructors from char*, std::string etc - I continued with that, patching the source (mostly char* <> wxString conversions). But after some time I had to stop short on this (marked deprecated) proplist thing, that just doesn't want to compile for 2.9 anymore. Long story, just a few questions: - Are there efforts for a mingw port/setup? I do not mean to switch and not for releases (for executable size is pretty bad compared to vc), just as an alternative for the devs. - Could anybody upload a binary (windows)? I'd like to get an idea of what the prop-thing practically does (plan to replace it with something else). - Why no intermediate nightly builds for win32? - What about migrating the wx-version to 2.9 => wx30? Maybe (probably) in a separate branch. Big hello for a start. Looking forward to your opinions on these ideas. But for now: Happy Xmas everybody ! - Björn Pfeiffer |
|
From: Aki L. <ak...@ko...> - 2008-12-22 16:03:17
|
Could the metronome have "Metronome Click" and "Metronome Bell" as its normal click and accented clicks? Then you wouldn't need any other optional sounds for it. |
|
From: Aki L. <ak...@ko...> - 2008-12-22 16:01:26
|
Could the metronome have "Metronome Click" and "Metronome Bell" as its normal click and accented clicks? Then you wouldn't need any other aotional sounds for it. |
|
From: Kevin C. <ke...@co...> - 2008-12-08 16:33:34
|
On 5 December 2008 at 11:26, Pete Stieber <pst...@gm...> wrote: > KC = Kevin Cosgrove > KC> OK, I misunderstood about the need for both debug > KC> and release versions of wxWidgets. > > Sorry about that. Was there something in the web instructions that > misled you? No. I just took what I thought was a shortcut. I couldn't understand why I would need to have two versions of wxWidgets. We've already been over that. > KC> I started over again. My Mandriva 2008.0 laptop > KC> built everything once more, > > Thanks for taking the time to do this. No problem. > KC> and I'm happy to report that jazz runs. When it > KC> started up I had to confirm two MIDI devices and > KC> help jazz to locate the helpfile. > > The confirmation of the MIDI devices I understand. I thought I changes > the code to automatically find the help file on Linux. Did you run > "make install" and run the code from the installed location? Yes, "make install" and ran $PREFIX/bin/jazz. > Thank you for sticking with it! No problem. I might be slow. But, I lurk here. > If you do that, let me know and I'll load it on a disk here so I can > help you out. Ok. -- Kevin |
|
From: D.B. M. <db...@ho...> - 2008-12-06 00:10:55
|
> Date: Fri, 5 Dec 2008 11:26:30 -0800 > From: pstieber > To: jazzplusplus-devel > Subject: Re: [jazzplusplus-devel] Revisiting web-docs after recent changes > <snip> > > KC> and I'm happy to report that jazz runs. When it > KC> started up I had to confirm two MIDI devices and > KC> help jazz to locate the helpfile. > PS> The confirmation of the MIDI devices I understand. I thought I changes PS> the code to automatically find the help file on Linux. Did you run PS> "make install" and run the code from the installed location? > FWIW, it did find the help file here automatically after the changes - it should have worked for Kevin too in an equal world... Regards, Don _________________________________________________________________ It's simple! Sell your car for just $40 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT |
|
From: Pete S. <pst...@gm...> - 2008-12-05 19:26:40
|
KC = Kevin Cosgrove KC> OK, I misunderstood about the need for both debug KC> and release versions of wxWidgets. Sorry about that. Was there something in the web instructions that misled you? KC> I started over again. My Mandriva 2008.0 laptop KC> built everything once more, Thanks for taking the time to do this. KC> and I'm happy to report that jazz runs. When it KC> started up I had to confirm two MIDI devices and KC> help jazz to locate the helpfile. The confirmation of the MIDI devices I understand. I thought I changes the code to automatically find the help file on Linux. Did you run "make install" and run the code from the installed location? KC> Once I did that, then I loaded the jazz.mid file KC> and poked some buttons in the harmony browser. I KC> can't say what it sounds like because I have no KC> MIDI devices (soft or hard) connected to the laptop. KC> But, the program runs, and I'm quite happy about KC> that! So am I ;-) KC> Thank you, thank you! Thank you for sticking with it! KC> Maybe I'll try to use some time over Christmas KC> break to update my music machine's Mandriva KC> version to the latest, 2009.0. If you do that, let me know and I'll load it on a disk here so I can help you out. KC> Thanks again... Back at ya, Pete |
|
From: Kevin C. <ke...@co...> - 2008-12-05 18:54:43
|
OK, I misunderstood about the need for both debug and release versions of wxWidgets. I started over again. My Mandriva 2008.0 laptop built everything once more, and I'm happy to report that jazz runs. When it started up I had to confirm two MIDI devices and help jazz to locate the helpfile. Once I did that, then I loaded the jazz.mid file and poked some buttons in the harmony browser. I can't say what it sounds like because I have no MIDI devices (soft or hard) connected to the laptop. But, the program runs, and I'm quite happy about that! Thank you, thank you! Maybe I'll try to use some time over Christmas break to update my music machine's Mandriva version to the latest, 2009.0. Thanks again... -- Kevin |
|
From: Pete S. <pst...@gm...> - 2008-12-02 15:01:01
|
DM>> Well, I suppose if Kevin didn't install debug + release DM>> versions of wx. that -may- explain it... tex2rtf is built against a release version of wxWidgets. Jazz++ is built against a debug version. From the log, when tex2rtf is run it is finding the debug build of wxWidgets as indicated by... The library used 2.8 (debug,ANSI,compiler with C++ ABI 1002,STL containers) but tex2rtf want a release version as indicated by... and your program used 2.8 (no debug,ANSI,compiler with C++ ABI 1002,STL containers) where "your program" is tex2rtf. Note the "no debug" in the second entry. DM>> but then, going by his log, the jazz build -did- DM>> find the release version??? No it did not. The jazz build didn't compile any single file. The first step is building help, and that failed. No Jazz++ files were even compiled in the build log. If Kevin followed the build instructions, Jazz++ doesn't build against the release version of wxWidgets, but the debug version. DM>> ....so I presumed he did build both...otherwise things DM>> wouldn't have complained? KC> I built only the "release", not the "debug". Then you are not following the wxWidgets build instructions on the web site. The web site has you build both a release (for tex2rtf) and a debug version (for jazz) of wxWidgets. The old instructions only had you build a debug version. The Jazz++ build instructions have always used the debug build of wxWidgets. This is specified in the configure line... ../jazz/configure \ --prefix=/usr/local/Jazz++ \ --enable-debug \ --enable-alsa \ --enable-sequencer2 with --enable-debug. This triggers the use of the debug version of the wxWidgets build. KC> What's the debug for anyway? It seemed unused to me. This allows you to use gdb to get a back trace if Jazz++ crashes while you are using it. Pete |
|
From: Kevin C. <ke...@co...> - 2008-12-01 16:16:49
|
On 27 November 2008 at 20:28, "D.B. Moore" <db...@ho...> wrote: > Well, I suppose if Kevin didn't install debug + release versions of wx. that > -may- explain it...but then, going by his log, the jazz build -did- find the > release version???....so I presumed he did build both...otherwise things > wouldn't have complained? I built only the "release", not the "debug". What's the debug for anyway? It seemed unused to me. Thanks.... -- Kevin |
|
From: Kevin C. <ke...@co...> - 2008-12-01 16:13:38
|
On 27 November 2008 at 12:53, "Pete Stieber" <pst...@gm...> wrote: > We build tex2rtf against a release version of the wxWidgets library. > Did you build and install a release version of wx? I *thought* I built tex2rtf against the wxWidgets that I just downloaded. -- Kevin |
|
From: D.B. M. <db...@ho...> - 2008-11-27 20:28:44
|
> Date: Thu, 27 Nov 2008 13:04:00 -0600 > From: pstieber > To: jazzplusplus-devel > Subject: Re: [jazzplusplus-devel] Revisiting web-docs after recent changes > > DM> Hmm...when I checked the tex2rtf linkmap here, I discovered this ; > DM> > DM> ldd /usr/local/bin/tex2rtf > DM> linux-gate.so.1 => (0xffffe000) > DM> libwx_gtk2_richtext-2.8.so.0 => /usr/lib/libwx_gtk2_richtext-2.8.so.0 > DM> (0xf7e80000) > DM> > DM> ...blabla.....and, despite the fact that I didn't see the error you > DM> encountered, this is actually wrong -- we *should* be linking > DM> against the custom wx libs installed in /usr/local/wx289/.....yes?? > >PS> Correct. > > DM> Ergo, this is probably because in the tex2rtf build instructions, we don't > DM> actually specify --with-wx-prefix=PREFIX at configure time, and the > DM> result is the tex2rtf build ends up using system installed wx libs instead. > > PS>If you PATH and LD_LIBRARY_PATH are set correctly, you should need to > PS>use --with-wx-prefix. > I suppose you meant shouldn't here....and I agree....the prepended PATH & LD_LIBRARY_PATH should take precedence.. > DM> As it turns out, my system-wide wx installation is indeed a debug > DM> version build, > > PS>This is not typical. > Indeed....very little is 'typical' on my own system builds - it's part of the reason I also test&check against something typical...like Debian... > DM> and this would explain why I didn't encounter this same error > DM> building jazz itself. > > PS>That's not my current guess. I believe Kevin's error was due to not > PS>finding release versions of the wxWidgets library. > I gave that consideration....if so, how come the jazz build found the right version? (or a different version as the case may be) > DM> Kevin, my suggestion is to rebuild/reinstall tex2rtf, but at configure time > DM> doing ; > DM> > DM> ../tex2rtf/configure --with-wx-prefix=/usr/local/wx289 > DM> > DM> This should result in tex2rtf being linked against our custom wx libs, and > DM> the problem you found should go away..... > > PS>I don't think this will work. I think you need to install the release > PS>version of wxWidgets. > Well, I suppose if Kevin didn't install debug + release versions of wx. that -may- explain it...but then, going by his log, the jazz build -did- find the release version???....so I presumed he did build both...otherwise things wouldn't have complained? >PS> Don, what was your PATH when you built tex2rtf? If our version of wx >PS> (/usr/local/wx289/bin) is first in your path, you will use the proper >PS> version of wx-config. Your ldd test seems to indicate this was not >PS> the case. $export declare -x PATH="/usr/local/wx289/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin:/opt/qt4/bin:/opt/gnome/bin:/opt/jdk/jdk/bin:/opt/wine/bin" declare -x LD_LIBRARY_PATH="/usr/local/wx289/lib:" as expected and looks good to me. A bit of a weird one, but in the end I figured that it didn't -hurt- to throw tex2rtf the --with-wx-prefix switch, and such might obviate (other) problems with the wx build (if any existed). My best guess here is human error (mine ;-), probably part of the human condition (laziness)....ie; didn't leave su before building tex2rtf....certainly the deb build looks good (just checked). Regards, Don _________________________________________________________________ Time for change? Find your ideal job with SEEK. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Atl%3Ask%3Anine%3A0%3Ahottag%3Achange&_t=757263783&_r=SEEK_tagline&_m=EXT |
|
From: Pete S. <pst...@gm...> - 2008-11-27 19:04:05
|
DM> Hmm...when I checked the tex2rtf linkmap here, I discovered this ; DM> DM> ldd /usr/local/bin/tex2rtf DM> linux-gate.so.1 => (0xffffe000) DM> libwx_gtk2_richtext-2.8.so.0 => /usr/lib/libwx_gtk2_richtext-2.8.so.0 DM> (0xf7e80000) DM> DM> ...blabla.....and, despite the fact that I didn't see the error you DM> encountered, this is actually wrong -- we *should* be linking DM> against the custom wx libs installed in /usr/local/wx289/.....yes?? Correct. DM> Ergo, this is probably because in the tex2rtf build instructions, we don't DM> actually specify --with-wx-prefix=PREFIX at configure time, and the DM> result is the tex2rtf build ends up using system installed wx libs instead. If you PATH and LD_LIBRARY_PATH are set correctly, you should need to use --with-wx-prefix. DM> As it turns out, my system-wide wx installation is indeed a debug DM> version build, This is not typical. DM> and this would explain why I didn't encounter this same error DM> building jazz itself. That's not my current guess. I believe Kevin's error was due to not finding release versions of the wxWidgets library. DM> Kevin, my suggestion is to rebuild/reinstall tex2rtf, but at configure time DM> doing ; DM> DM> ../tex2rtf/configure --with-wx-prefix=/usr/local/wx289 DM> DM> This should result in tex2rtf being linked against our custom wx libs, and DM> the problem you found should go away..... I don't think this will work. I think you need to install the release version of wxWidgets. Don, what was your PATH when you built tex2rtf? If our version of wx (/usr/local/wx289/bin) is first in your path, you will use the proper version of wx-config. Your ldd test seems to indicate this was not the case. Pete |
|
From: Pete S. <pst...@gm...> - 2008-11-27 18:53:40
|
Kevin, We build tex2rtf against a release version of the wxWidgets library. Did you build and install a release version of wx? Pete |
|
From: D.B. M. <db...@ho...> - 2008-11-27 00:06:39
|
Greets,
> To: jazzplusplus-devel
> Date: Wed, 26 Nov 2008 14:37:38 -0800
> From: kevinc
> Subject: Re: [jazzplusplus-devel] Revisiting web-docs after recent changes
>
>
> On 26 November 2008 at 11:22, "Pete Stieber" <pst...@gm...> wrote:
> > Were you able to get a binary working?
>
> Kevin wrote;
>
> I got wxWidgets built & installed. Likewise with tex2rft. Then I
> tried to build jazz.
>
> I have build logs, and environment setting stuff to look at. I could
> send it all. But, maybe you'd rather have just some special stuff?
>
> Anyway. I guess I'll poke at this a little more, maybe use more
> standard paths, e.g. /usr, to see if that helps.
>
> Thanks....
>
Hmm...when I checked the tex2rtf linkmap here, I discovered this ;
ldd /usr/local/bin/tex2rtf
linux-gate.so.1 => (0xffffe000)
libwx_gtk2_richtext-2.8.so.0 => /usr/lib/libwx_gtk2_richtext-2.8.so.0 (0xf7e80000)
libwx_gtk2_aui-2.8.so.0 => /usr/lib/libwx_gtk2_aui-2.8.so.0 (0xf7e18000)
libwx_gtk2_xrc-2.8.so.0 => /usr/lib/libwx_gtk2_xrc-2.8.so.0 (0xf7d8a000)
libwx_gtk2_qa-2.8.so.0 => /usr/lib/libwx_gtk2_qa-2.8.so.0 (0xf7d6c000)
libwx_gtk2_html-2.8.so.0 => /usr/lib/libwx_gtk2_html-2.8.so.0 (0xf7cd3000)
libwx_gtk2_adv-2.8.so.0 => /usr/lib/libwx_gtk2_adv-2.8.so.0 (0xf7c14000)
libwx_gtk2_core-2.8.so.0 => /usr/lib/libwx_gtk2_core-2.8.so.0 (0xf78db000)
libwx_base_xml-2.8.so.0 => /usr/lib/libwx_base_xml-2.8.so.0 (0xf78d1000)
libwx_base_net-2.8.so.0 => /usr/lib/libwx_base_net-2.8.so.0 (0xf78a5000)
libwx_base-2.8.so.0 => /usr/lib/libwx_base-2.8.so.0 (0xf777c000)
...blabla.....and, despite the fact that I didn't see the error you encountered, this
is actually wrong -- we *should* be linking against the custom wx libs installed
in /usr/local/wx289/.....yes??
Ergo, this is probably because in the tex2rtf build instructions, we don't actually
specify --with-wx-prefix=PREFIX at configure time, and the result is the tex2rtf
build ends up using system installed wx libs instead. This would seem counter-
intuitive, as we'd be expecting the tex2rtf build to see the LD_LIBRARY_PATH
variable in our ~/.bash_profile (which was set during the wx build phase), so my
best guess here is that the tex2rtf tree isn't honoring LD_LIBRARY_PATH variable.
As it turns out, my system-wide wx installation is indeed a debug version build, and
this would explain why I didn't encounter this same error building jazz itself.
Kevin, my suggestion is to rebuild/reinstall tex2rtf, but at configure time doing ;
../tex2rtf/configure --with-wx-prefix=/usr/local/wx289
This should result in tex2rtf being linked against our custom wx libs, and the
problem you found should go away.....
Regards,
Don
_________________________________________________________________
Your dream beach house escape for summer! Sign up for the Hotmail Road Trip today.
http://www.ninemsn.com.au/hotmailroadtrip |
|
From: Kevin C. <ke...@co...> - 2008-11-26 22:37:33
|
On 26 November 2008 at 11:22, "Pete Stieber" <pst...@gm...> wrote: > Were you able to get a binary working? I got wxWidgets built & installed. Likewise with tex2rft. Then I tried to build jazz. I have build logs, and environment setting stuff to look at. I could send it all. But, maybe you'd rather have just some special stuff? Anyway. I guess I'll poke at this a little more, maybe use more standard paths, e.g. /usr, to see if that helps. Thanks.... -- Kevin |
|
From: Pete S. <pst...@gm...> - 2008-11-26 17:40:11
|
PS>> On vacation in Colorado KC> Lucky guy. Where in CO? Loveland, near Ft. Collins. My daughter lives here. I'll be back with my normal development machines on Friday. Pete |
|
From: Kevin C. <ke...@co...> - 2008-11-26 17:35:02
|
On 26 November 2008 at 11:22, "Pete Stieber" <pst...@gm...> wrote: > Were you able to get a binary working? Not yet. I haven't had enough time to let one of my laptops stay running for hours on end -- the time it takes a PIII to compile all three packages. I've got a 4-day weekend, and can let a machine chug along. > On vacation in Colorado, Lucky guy. Where in CO? I've vacationed there about 4 times from the time I was a little kid. -- Kevin |
|
From: Pete S. <pst...@gm...> - 2008-11-26 17:22:58
|
DB>> Are we happy with the revised build instructions? KC> I'm happy. So Kevin, Were you able to get a binary working? Don, Go ahead and make the other changes and send a patch. Thanks for doing this! On vacation in Colorado, Pete |
|
From: Kevin C. <ke...@co...> - 2008-11-25 16:08:44
|
On 25 November 2008 at 7:42, "D.B. Moore" <db...@ho...> wrote: > Are we happy with the revised build instructions? I'm happy. -- Kevin |
|
From: D.B. M. <db...@ho...> - 2008-11-25 07:42:05
|
Greets, Are we happy with the revised build instructions? (I am ;) The reason I ask, is that a few sections in web-docs, notably the 'reporting bugs' page, has a few path and location statements which (now..) don't align with the new build instructions...might be a tad misleading for the uninitiated. I'll rework these sections and upload a patch, just as soon as Pete confirms this query. Regards, Don _________________________________________________________________ Time for change? Find your ideal job with SEEK. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Atl%3Ask%3Anine%3A0%3Ahottag%3Achange&_t=757263783&_r=SEEK_tagline&_m=EXT |
|
From: Kevin C. <ke...@co...> - 2008-11-19 19:56:30
|
On 19 November 2008 at 10:35, Pete Stieber <pst...@gm...> wrote: > The machine I had success with was Mandrive 2008.0. Good news for me! > Kevin, a while ago you wrote... > > KC> Trying to run jazz I get X window errors, which > KC> I'm nearly certain are due to my present > KC> environment and have nothing to do with jazz. > KC> I get the same errors this morning with other > KC> apps, which I didn't get last Friday. Grr. > > Are you still having problems with other apps? No, that was a new security layer at work, which placed a new demand on my SSH config. It's all better now. > Going back through this thread, I'm seeing different problems. For > instance, when you tried to use gdb... > > <GDB session> > (gdb) run > Starting program: /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xffffe000 > /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz: error while > loading shared libraries: libwx_gtk2d_richtext-2.8.so.0: cannot open > shared object file: No such file or directory > > Gdb said the library file didn't exist, but it was in the correct > location with respect to LD_LIBRARY_PATH. > > Then you sent the result of setting LD_DEBUG=files. This logged > indicated libwx_gtk2d_richtext-2.8.so.0 was found. I'm wondering what > changed? > > The final error in your log was a missing gconv_end function. Googling > for this function, it looks like it is in glibc... > > http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_node/libc_101.html > > This thread looks similar > > https://helixcommunity.org/projects/player/forums/entry/124 > > Maybe there is a library configuration problem on your machine, but I > guess you already knew that :-( Yup. I think I need to build on something a little more controlled than what I've got. I didn't do anything other than Mandriva updates, but I did updates for years and I'm not certain what state it's in. The newer versions of the distro seem to be better in a number of ways, including the update scenario. Cheers.... -- Kevin |
|
From: Pete S. <pst...@gm...> - 2008-11-19 18:35:10
|
DM>> Regarding attachment log....it would appear not to be DM>> jazz at all, but instead the interaction between DM>> gtk_libs and glib_libs (more particularly here DM>> librsvg/pixbuf and other related libs)....although DM>> how this could happen on a mainstream distro DM>> is a bit peculiar....have you upgraded any of these DM>> related pkgs lately? KC> I haven't updated anything on this system lately. KC> It's Mandriva 2007.0 and out of it's end of update KC> period. Mandriva 2009.0 is recently out, and I just KC> burned an install DVD a couple of days ago. It KC> looks like I get to play with that. I also have a KC> couple of laptops, one Mandriva 2008.0 and the other KC> 2008.1. I could try a build on those, but it'll KC> be sloooooow. The fastest of those machines is a PIII The machine I had success with was Mandrive 2008.0. DM>> FWIW, I -could- recreate this kind of error (I've DM>> seen it before) by doing something like upgrading DM>> the version of glib but not rebuilding (or upgrading) DM>> gtk, or similarly not doing the same with librsvg DM>> after a glib change (or anything else that is glib DM>> dependent), but usually I see relocation errors, DM>> not undefined_ref errors....so maybe your problem DM>> is something different....like runtime linker DM>> failing to load something... KC> I've not had that happen when I build my own KC> software. And the log seems to say that it's KC> finding everything. Maybe I'm unclear KC> on how that works? DM>> Also...and I don't think this is a problem but it DM>> gets a mention...on the Deb systems here (and my DM>> construct), the variable LD_LIBRARY_PATH is no DM>> longer system set -- it is deduced from DM>> /etc/ld.co.conf in practise, if LD_LIBRARY_PATH DM>> is unset. (actually, it falls through to DM>> /etc/ld.so.conf if LD_LIBRARY_PATH is unset, but DM>> if LD_LIBRARY_PATH is set it takes precedence..) This is explained in http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html Just search for LD_LIBRARY_PATH using your web browser. DM>> When we add export DM>> LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH DM>> DM>> ..to the user's .bash_profile, the variable set DM>> will appear as DM>> DM>> LD_LIBRARY_PATH="/usr/local/wx289/lib:" DM>> DM>> ...with the trailing colon. AFAIK, this shouldn't DM>> be a problem...it should just delimit the string DM>> and ignore the nothingness thereafter...at least, DM>> that is what I observe in practise here -- it just DM>> looks a bit out of place. We probably have to do DM>> it as it stands though, 'just in case' the user DM>> already has LD_LIBRARY_PATH set..... Exactly. This isn't a problem. KC> Your description of LD_LIBRARY_PATH matches my KC> experience. KC> KC> I believe that my libraries are found correctly: KC> KC> ldd bin/jazz KC> KC> linux-gate.so.1 => (0xffffe000) KC> libwx_gtk2d_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD... <snip> KC> I don't doubt that there could be issues with KC> compatibility between various versions of my KC> shared object libraries. I'll see what KC> happens on a different version of Mandriva. Kevin, a while ago you wrote... KC> Trying to run jazz I get X window errors, which KC> I'm nearly certain are due to my present KC> environment and have nothing to do with jazz. KC> I get the same errors this morning with other KC> apps, which I didn't get last Friday. Grr. Are you still having problems with other apps? Going back through this thread, I'm seeing different problems. For instance, when you tried to use gdb... <GDB session> (gdb) run Starting program: /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz: error while loading shared libraries: libwx_gtk2d_richtext-2.8.so.0: cannot open shared object file: No such file or directory Gdb said the library file didn't exist, but it was in the correct location with respect to LD_LIBRARY_PATH. Then you sent the result of setting LD_DEBUG=files. This logged indicated libwx_gtk2d_richtext-2.8.so.0 was found. I'm wondering what changed? The final error in your log was a missing gconv_end function. Googling for this function, it looks like it is in glibc... http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_node/libc_101.html This thread looks similar https://helixcommunity.org/projects/player/forums/entry/124 Maybe there is a library configuration problem on your machine, but I guess you already knew that :-( Pete |
|
From: Kevin C. <ke...@co...> - 2008-11-19 05:03:56
|
On 18 November 2008 at 1:45, "D.B. Moore" <db...@ho...> wrote: > Regarding attachment log....it would appear not to be jazz at > all, but instead the interaction between gtk_libs and glib_libs > (more particularly here librsvg/pixbuf and other related > libs)....although how this could happen on a mainstream distro > is a bit peculiar....have you upgraded any of these related > pkgs lately? I haven't updated anything on this system lately. It's Mandriva 2007.0 and out of it's end of update period. Mandriva 2009.0 is recently out, and I just burned an install DVD a couple of days ago. It looks like I get to play with that. I also have a couple of laptops, one Mandriva 2008.0 and the other 2008.1. I could try a build on those, but it'll be sloooooow. The fastest of those machines is a PIII > FWIW, I -could- recreate this kind of error (I've seen it > before) by doing something like upgrading the version of glib > but not rebuilding (or upgrading) gtk, or similarly not doing > the same with librsvg after a glib change (or anything else > that is glib dependent), but usually I see relocation errors, > not undefined_ref errors....so maybe your problem is something > different....like runtime linker failing to load something... I've not had that happen when I build my own software. And the log seems to say that it's finding everything. Maybe I'm unclear on how that works? > Also...and I don't think this is a problem but it gets a > mention...on the Deb systems here (and my construct), the > variable LD_LIBRARY_PATH is no longer system set -- it is > deduced from /etc/ld.co.conf in practise, if LD_LIBRARY_PATH > is unset. (actually, it falls through to /etc/ld.so.conf if > LD_LIBRARY_PATH is unset, but if LD_LIBRARY_PATH is set it > takes precedence..) > > When we add export > LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH > > ..to the user's .bash_profile, the variable set will appear as > > LD_LIBRARY_PATH="/usr/local/wx289/lib:" > > ...with the trailing colon. AFAIK, this shouldn't be a > problem...it should just delimit the string and ignore the > nothingness thereafter...at least, that is what I observe in > practise here -- it just looks a bit out of place. We probably > have to do it as it stands though, 'just in case' the user > already has LD_LIBRARY_PATH set..... Your description of LD_LIBRARY_PATH matches my experience. I believe that my libraries are found correctly: ldd bin/jazz linux-gate.so.1 => (0xffffe000) libwx_gtk2d_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 (0xb7e03000) libwx_gtk2d_aui-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_aui-2.8.so.0 (0xb7d80000) libwx_gtk2d_xrc-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_xrc-2.8.so.0 (0xb7cda000) libwx_gtk2d_qa-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_qa-2.8.so.0 (0xb7cb4000) libwx_gtk2d_html-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_html-2.8.so.0 (0xb7beb000) libwx_gtk2d_adv-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_adv-2.8.so.0 (0xb7af1000) libwx_gtk2d_core-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_core-2.8.so.0 (0xb76f0000) libwx_based_xml-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based_xml-2.8.so.0 (0xb76e4000) libwx_based_net-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based_net-2.8.so.0 (0xb769e000) libwx_based-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based-2.8.so.0 (0xb74be000) libasound.so.2 => /usr/lib/libasound.so.2 (0xb73c9000) libdl.so.2 => /lib/libdl.so.2 (0xb73c5000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb73b2000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb72cd000) libm.so.6 => /lib/i686/libm.so.6 (0xb72a8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb729c000) libc.so.6 => /lib/i686/libc.so.6 (0xb716f000) libz.so.1 => /lib/libz.so.1 (0xb715c000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6dce000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6d41000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6d25000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6d0c000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6cce000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6c90000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6c8c000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6c87000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6beb000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6be7000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6be2000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb6bd9000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6bb3000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6b90000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6b3d000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6b1a000) /lib/ld-linux.so.2 (0xb7f17000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6b11000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6a12000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb69a2000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6974000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6965000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb695c000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb6954000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6950000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6945000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6940000) librt.so.1 => /lib/i686/librt.so.1 (0xb6937000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb691e000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb68ef000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6881000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb687e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6878000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb674b000) ldd bin/tex2rtf linux-gate.so.1 => (0xffffe000) libwx_gtk2_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_richtext-2.8.so.0 (0xb7dfa000) libwx_gtk2_aui-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_aui-2.8.so.0 (0xb7d8f000) libwx_gtk2_xrc-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_xrc-2.8.so.0 (0xb7ce5000) libwx_gtk2_qa-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_qa-2.8.so.0 (0xb7cc4000) libwx_gtk2_html-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_html-2.8.so.0 (0xb7c11000) libwx_gtk2_adv-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_adv-2.8.so.0 (0xb7b44000) libwx_gtk2_core-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_core-2.8.so.0 (0xb77e1000) libwx_base_xml-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base_xml-2.8.so.0 (0xb77d5000) libwx_base_net-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base_net-2.8.so.0 (0xb77a4000) libwx_base-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base-2.8.so.0 (0xb7649000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7545000) libm.so.6 => /lib/i686/libm.so.6 (0xb7520000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7515000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7502000) libc.so.6 => /lib/i686/libc.so.6 (0xb73d5000) libz.so.1 => /lib/libz.so.1 (0xb73c1000) libdl.so.2 => /lib/libdl.so.2 (0xb73bd000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb702f000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6fa2000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f86000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6f6e000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6f2f000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6ef1000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6eed000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6ee8000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6e4c000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6e49000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6e43000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb6e3a000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6e14000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6df1000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6d9e000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6d7b000) /lib/ld-linux.so.2 (0xb7efb000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6d72000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6c73000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6c04000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6bd5000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6bc6000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6bbd000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb6bb5000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6bb1000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6ba7000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6ba1000) librt.so.1 => /lib/i686/librt.so.1 (0xb6b98000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb6b7f000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6b50000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ae3000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb6adf000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6ad9000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb69ac000) I don't doubt that there could be issues with compatibility between various versions of my shared object libraries. I'll see what happens on a different version of Mandriva. Thanks.... -- Kevin |
86 messages has been excluded from this view by a project administrator.
