Am 08.01.2013 um 10:30 schrieb Jerry <lancebo...@qwest.net>: > On Jan 8, 2013, at 12:21 AM, Stephan Witt wrote: > >> Am 08.01.2013 um 07:17 schrieb Jerry <lancebo...@qwest.net>: >> >>> On Jan 5, 2013, at 8:30 PM, Jerry wrote: >>> >>>> Hi List, >>>> >>>> Since I have probably complained the most about the scrolling problem on >>>> OS X, I thought I would (finally) try a bisection. >>>> >>>> Here is what I already know based on downloaded binaries: The problem >>>> occurred in at least two stages, between 1.6.10 and 2.0 and again between >>>> 2.0 and 2.0.4. I would rate these versions as: >>>> >>>> 1.6.10 Very Good >>>> 2.0 Fair >>>> 2.0.4 Bad >>>> >>>> (I speculate that 1.6.10 is not "Excellent" only because the smallest >>>> scrolling increment is substantially greater than one pixel, causing the >>>> scrolling to be very fast but not "glassy smooth".) >>>> >>>> I have installed Git and studied the manpage at git help bisect. However, >>>> I am going to need some help as I'm a little wobbly on what to do. I can >>>> find my way around SVN but Git seems to be a different creature. In SVN, >>>> each commit creates a new version of trunk that is labeled with a serial >>>> version number, thus making it easy to make the local repository match any >>>> version number. I haven't yet figured out how to do that with Git. Also, I >>>> need help to learn how to actually compile the code. I think I have all >>>> the prerequisites already installed on my machine. >>>> >>>> These notes and questions might be pertinent: >>>> >>>> I am building on OS X 10.7.5 (Lion). >>>> >>>> Do I need to worry about 32-bit versus 64-bit builds? I'm sure this >>>> depends on my Qt libraries which are: >>>> >>>> Qt version is 4.8.3_1+quartz (via MacPorts). (I also have an older >>>> version, probably 4.7, that I downloaded as a binary from Nokia or >>>> Trolltech. If I don't do anything special, the build will be against the >>>> MacPorts version.) >>>> >>>> How do I build without debugging code present that could potentially skew >>>> the results? >>>> >>>> I have a version of LyX that I built from SVN almost exactly one year >>>> ago--its version is given as 2.1.0svn. It has a corresponding >>>> (preferences???) file in which I added or edited a line according to >>>> suggestions from this list which caused the scrolling behavior to improve >>>> substantially but which also caused the cursor position to be slightly >>>> wrong. I don't think other 2.x builds see this but I'm not 100% certain. I >>>> forget the details of how I edited that file but my recollection is that >>>> it is not seen by other 2.0.x builds. (I don't want to touch that 2.1.0svn >>>> build because it works pretty well.) >>>> >>>> SO IN SUMMARY: >>>> * How do I update my my local repository to perform the above-mentioned >>>> two bisections? >>>> >>>> * How do I compile? >>>> >>>> Jerry >>> >>> >>> I did this: >>> >>> >>> ./autogen.sh >>> ./configure \ >>> --with-version-suffix=-2.0 \ >>> --with-libiconv-prefix=/usr \ >>> --with-x=no \ >>> --disable-stdlib-debug \ >>> >>> --prefix=/Applications/Words/LyX_outer_folder/lyx-build-develop-jb-debug/LyX.app >>> \ >>> --with-qt4-dir=/opt/local/lib \ >>> --enable-build-type=release >>> make >>> make install-strip >>> >>> >>> >>> and got this: >>> >>> >>> >>> <snip> >>> CXX Thesaurus.o >>> CXXLD lyx >>> Undefined symbols for architecture x86_64: >>> "_libiconv_close", referenced from: >>> (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet()in >>> liblyxsupport.a(docstream.o) >>> (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet()in >>> liblyxsupport.a(docstream.o) >>> lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned >>> long)in liblyxsupport.a(unicode.o) >>> lyx::IconvProcessor::Impl::~Impl()in liblyxsupport.a(unicode.o) >>> "_libiconv", referenced from: >>> (anonymous namespace)::iconv_codecvt_facet::do_out(__mbstate_t&, wchar_t >>> const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) constin >>> liblyxsupport.a(docstream.o) >>> (anonymous namespace)::iconv_codecvt_facet::do_in(__mbstate_t&, char >>> const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) constin >>> liblyxsupport.a(docstream.o) >>> lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned >>> long)in liblyxsupport.a(unicode.o) >>> "_libiconv_open", referenced from: >>> (anonymous >>> namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > const&, std::_Ios_Openmode, >>> unsigned long)in liblyxsupport.a(docstream.o) >>> lyx::IconvProcessor::init() in liblyxsupport.a(unicode.o) >>> ld: symbol(s) not found for architecture x86_64 >>> collect2: ld returned 1 exit status >>> make[4]: *** [lyx] Error 1 >>> make[3]: *** [install-recursive] Error 1 >>> make[2]: *** [install] Error 2 >>> make[1]: *** [install-recursive] Error 1 >>> make: *** [install-strip] Error 2 >>> >>> >>> >>> What went wrong? Recall that I'm on OS X 10.7.5. I have the following >>> libraries installed: >>> >>> >>> /opt/local/lib/libiconv.2.dylib >>> /opt/local/lib/libiconv.a >>> /opt/local/lib/libiconv.dylib >>> /opt/local/lib/libiconv.la >>> >>> /usr/lib/libiconv.2.4.0.dylib >>> /usr/lib/libiconv.2.dylib >>> /usr/lib/libiconv.dylib >>> >>> My PATH is: >>> >>> /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin:/usr/local/sbin:/Applications:/usr/local/adacore-gnat-2011/bin >> >> You didn't answer my mail. Did you read it? > > I did but I'm aware that I might not have fully honored it/knew what to do > about it. Obviously, I'm not building for a release so I don't need a > self-contained bundle. I would have to check, but I think the downloaded > Nokia version is somewhere in /usr/local which comes after the Macports > version in /opt/local in my PATH. Is that sufficient isolation?
Nokia provides Qt-libraries as frameworks and you should find them in the folder /Library/Frameworks. The linker looks for frameworks there by default. >> I'm actively avoid the mix of system and MacPorts libraries. But this might >> not be your problem. >> >> Check the architecture of all relevant (this is sometimes difficult to >> decide) libraries. >> $ file /opt/local/lib/libiconv.2.dylib >> $ otool -L /opt/local/lib/libiconv.2.dylib > > I will do that soon but I have to sleep now. > > Can you tell from build commands above if I'm building 64-bit? I assume that > on OS X 10.7.x that the default is 64-bit builds. I also note in the slightly > stale INSTALL.MacOSX that 64-bit Lyx builds won't launch or words to that > effect. Is that no longer true? Have you built for 64-bit arch? Should I > revert to 32-bit build? (I know--do otool first.) I'll review the INSTALL.MacOSX, at the time of writing 64bit didn't work indeed. It's not true anymore. Reading your linker error message I'd say you build LyX with 64bit, but you don't have a matching iconv library. That's strange, because your system library (in /usr/lib) should at least provide i386 and x86_64. Here this is the case: $ file /usr/lib/libiconv.2.4.0.dylib /usr/lib/libiconv.2.4.0.dylib: Mach-O universal binary with 2 architectures /usr/lib/libiconv.2.4.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libiconv.2.4.0.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 But I got these effects in the past when using some MacPorts library (accidentally) too. >> BTW, what version of LyX are you trying to build? In your case I'd rather >> start without or with an special version suffix. > > I'm building from master which I downloaded about two days ago. This is just > for practice. As noted in my original post, the bisection will start looking > between 2.0 and 2.0.4. Then I'd recommend the use of a special or of no suffix. Otherwise you may mix it with your stable 2.0 LyX installation. Stephan
