Am 09.09.2010 um 07:32 schrieb Cyrille Artho:
> Hi Stephan,
> in the earlier attempt from my previous e-mail, I unfortunately still had
> remnants of a system-wide installation of qt3 left. I have since then removed
> that, and the number of linking problems has gone down significantly.
I cannot say anything about fink - but is it really Qt3 which is part of it?
Seems to be very outdated now.
> I am using fink, but for the purpose of using LyX, I use a fresh QT
> installation that has been compiled from source and installed in ~/qt4:
>
> ./configure -opensource -silent -shared -release -universal -fast
> -no-exceptions -no-webkit -no-qt3support -no-javascript-jit -no-dbus -nomake
> examples -nomake demos -nomake docs -nomake tools -no-framework -prefix
> ${HOME}/qt4 && make && make install
>
> Note that while pkg-config is installed, it is probably not used in such an
> installation that resides within the user-home, and not carried out with
> super-user rights.
>
> Under fink, pkgconfig is installed as version 0.23-2. But I think that
> without any qt installation managed by fink (or ports), fink does not cause
> the problem here.
>
> gcc version 4.2.1 is Standard on 10.6.4, I think:
>
> % gcc -v
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5664~38/src/configure --disable-checking
> --enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
> --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
> --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
> --with-gxx-include-dir=/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5664)
I have the same one.
> For LyX, I have used the following configuration:
>
> export CPPFLAGS="-arch i386"
> export LDFLAGS="-arch i386"
Ok.
> ./configure --prefix=${HOME}/LyX-devel.app --with-version-suffix=-2.0
> --with-qt4-dir=${HOME}/qt4 --with-included-gettext --enable-optimization=-O2
> --disable-stdlib-debug --build=x86 && make
Why did you add --build=x86 ???
> This is exactly as in the new INSTALL.MacOSX document, except that my qt
> installation is not system-wide. The result are the following linkage
> problems at the very end:
>
> Making all in .
> CXXLD lyx
> Undefined symbols:
> "_FSPathMakeRef", referenced from:
> lyx::support::os::autoOpenFile(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
> "_getLinkBackData", referenced from:
> lyx::frontend::GuiClipboard::getAsGraphics(lyx::Cursor const&,
> lyx::frontend::Clipboard::GraphicsType) constin liblyxqt4.a(GuiClipboard.o)
> "_LSGetApplicationForInfo", referenced from:
> lyx::support::os::canAutoOpenFile(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
> "_LSGetApplicationForItem", referenced from:
> lyx::support::os::autoOpenFile(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
> "_LSOpenFromRefSpec", referenced from:
> lyx::support::os::autoOpenFile(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
> "_isLinkBackDataInPasteboard", referenced from:
> lyx::frontend::GuiClipboard::hasGraphicsContents(lyx::frontend::Clipboard::GraphicsType)
> constin liblyxqt4.a(GuiClipboard.o)
> "_closeAllLinkBackLinks", referenced from:
> lyx::frontend::GuiApplication::~GuiApplication()in
> liblyxqt4.a(GuiApplication.o)
> lyx::frontend::GuiApplication::~GuiApplication()in
> liblyxqt4.a(GuiApplication.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
>
> ==> Maybe more LDFLAGS are needed?
Maybe.
I cannot understand why you can successfully configure LyX but finally get link
errors for system resources.
Perhaps having a look at your config.log from LyX helps. Please, can you make
that public?
Stephan
> Stephan Witt wrote:
>> Am 07.09.2010 um 03:49 schrieb Cyrille Artho:
>>
>>> Hi Stephan,
>>> thank you for updating the guide. Using the recommended options (-universal
>>> for Qt, "-arch i386" for LyX), I could compile but not link LyX. I have had
>>> the same problems with earlier attempts.
>>
>> Thank you for trying the build instructions.
>>
>>> My last attempt was using rev. 35300 from svn. Linking also fails in a
>>> similar way on LyX 1.6.7.
>>
>> I think it's a general problem within the configure process and the concrete
>> svn version is irrelevant here.
>> So, it would be more helpful to see the complete command line text you're
>> using when
>> * configure Qt and
>> * configure LyX.
>>
>> Additionally please post the output of the three commands
>> % port list installed
>> % env
>> % gcc -v
>>
>> Frankly, currently I have no idea...
>>
>>> The linker output is as follows:
>>>
>>> Undefined symbols:
>>> ".objc_class_name_NSAutoreleasePool", referenced from:
>>> literal-poin...@__objc@__cls_r...@nsautoreleasepool in
>>> liblyxsupport.a(AppleSpeller.o)
>>> literal-poin...@__objc@__cls_r...@nsautoreleasepool in
>>> liblyxsupport.a(LinkBackProxy.o)
>>> "_FSPathMakeRef", referenced from:
>>> lyx::support::os::autoOpenFile(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&,
>>> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
>>> "_LSGetApplicationForInfo", referenced from:
>>> lyx::support::os::canAutoOpenFile(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&,
>>> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
>>> "_LSGetApplicationForItem", referenced from:
>>> lyx::support::os::autoOpenFile(std::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const&,
>>> lyx::support::os::auto_open_mode)in liblyxsupport.a(os.o)
>>> ".objc_class_name_NSSpellChecker", referenced from:
>>> literal-poin...@__objc@__cls_r...@nsspellchecker in
>>> liblyxsupport.a(AppleSpeller.o)
>>> ".objc_class_name_NSBundle", referenced from:
>>> literal-poin...@__objc@__cls_r...@nsbundle in
>>> liblyxsupport.a(LinkBack.o)
>>> literal-poin...@__objc@__cls_r...@nsbundle in
>>> liblyxsupport.a(LinkBackServer.o)
>>> "_FSFindFolder", referenced from:
>>> lyx::support::(anonymous
>>> namespace)::get_default_user_support_dir(lyx::support::FileName const&)in
>>> liblyxsupport.a(Package.o)
>>> "_objc_msgSend_fpret", referenced from:
>>> -[NSDictionary(LinkBackData) linkBackSuggestedRefreshRate] in
>>> liblyxsupport.a(LinkBack.o)
>>> _LinkBackUniqueItemKey in liblyxsupport.a(LinkBack.o)
>>
>> That looks really weird. Your linker does not know how to resolve symbols
>> from the apple foundation kit... but your compiler apparently did it.
>>
>> Stephan
>
> --
> Regards,
> Cyrille Artho - http://artho.com/
> Madness is rare in individuals, but in groups, parties, nations,
> and ages it is the rule.
> -- Friedrich Nietzsche
