This makes no sense.

[Andrew Berg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
 
Ralf Habacker wrote:
> Andrew Berg schrieb:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
>>
>> Ralf Habacker wrote:
>>
>>> Andrew Berg schrieb:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
>>>>
>>>> Andreas Pakulat wrote:
>>>>
>>>>
>>>>> On 22.06.07 05:14:48, Andrew Berg wrote:
>>>>>
>>>>>
>>>>>> Andrew Berg wrote:
>>>>>>
>>>>>>
>>>>>>> Andreas Pakulat wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 22.06.07 04:10:46, Andrew Berg wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I downloaded the Qt 4.3.0-1 bin and lib archives
>>>>>>>>> and added C:\KDE4 (where I extracted the archives)
>>>>>>>>> and C:\KDE4\bin to my path, but CMake still
>>>>>>>>> complains about not finding a QtGlobal header when
>>>>>>>>> I try to compile soprano.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Is qmake in your PATH? And why didn't you use the
>>>>>>>> installer?
>>>>>>>>
>>>>>>>>
>>>>>>> I used the URL provided by the installer, but
>>>>>>> downloaded them with Firefox because I needed to be
>>>>>>> able to pause the downloads if necessary (I'm on
>>>>>>> dialup). As for qmake, it's in c:\kde4\bin, and
>>>>>>> %QT_QMAKE_EXECUTABLE% is set to c:\kde4\bin\qmake.exe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> It appears that CMake needs to be reconfigured in order
>>>>>> to use the "new" Qt. I ran it in interactive mode, and
>>>>>> noticed that some things were off (it was using the old
>>>>>> Qt directory). However, even after running the CMake GUI
>>>>>> to change the variables, even though it now configures
>>>>>> correctly, mingw32-make tells me it can't find QtGlobal,
>>>>>> and spits out a bunch of errors.
>>>>>>
>>>>>>
>>>>> Try to remove the builddir completely and start fresh. Also
>>>>> make sure your c:\kde4 doesn't contain anything from
>>>>> kdelibs.
>>>>>
>>>>>
>>>> Done, and I moved Qt to c:\Qt\4.3.0 (after uninstalling the
>>>> old version, of course), and that made things better.
>>>> However, I now get this from mingw32-make (after I've
>>>> configured, using the CMake GUI to verify paths):
>>>>
>>>>
>>>>> Linking CXX shared library libsoprano_redlandbackend.dll
>>>>> C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
>>>>>  cannot find -lrdf collect2: ld returned 1 exit status
>>>>> mingw32-make[2]: ***
>>>>> [soprano/redland/libsoprano_redlandbackend.dll] Error 1
>>>>> mingw32-make[1]: ***
>>>>> [soprano/redland/CMakeFiles/soprano_redlandbackend.dir/all]
>>>>> Error 2 mingw32-make: *** [all] Error 2
>>>>>
>>>>>
>>>> The REDLAND_LIBRARIES variable (C:/Program
>>>> Files/win32libs/lib/librdf.lib) in CMake is correct.
>>>>
>>>>
>>>>
>>> May be that cmake has troubles with the spaces in c:\Program
>>> Files. You may change the relating path in the CMakeLists.txt
>>> with the short replacement (on german os c:\Programme is
>>> converted to c:\Progra~1)
>>>
>>> you can get the short form dir with dir /x c:\ ... 18.06.2007
>>> 18:41    <DIR>          PROGRA~1     Programme ...
>>>
>>> If this is really the problem, please report, so that the build
>>> system can be fixed.
>>>
>> Neither C:\Progra~1 or %programfiles% worked. In fact, using
>> %programfiles% caused it to make a bunch of errors saying that
>> Files\win32libs\[whatever] doesn't exist, which means that the
>> space is not the problem. With VERBOSE=1:
>>
>>> Linking CXX shared library libsoprano_redlandbackend.dll cd
>>> c:\dep\bin\soprano\redland && "C:\Program Files\CMake
>>> 2.4\bin\cmake.exe" -P
>>> CMakeFiles\soprano_redlandbackend.dir\cmake_clean_target.cmake
>>> cd c:\dep\bin\soprano\redland && "C:\Program Files\CMake
>>> 2.4\bin\cmake.exe" -E cmake_link_script
>>> CMakeFiles\soprano_redlandbackend.dir\link.txt --verbose=1
>>>
> Then copy the following text into an editor and make a complete
> command line from it
>>> C:\MinGW\bin\g++.exe    -shared -o
>>> libsoprano_redlandbackend.dll
>>> -Wl,--out-implib,libsoprano_redlandbackend.dll.a
>>> -Wl,--major-image-version,0,--minor-image-version,0
>>> "CMakeFiles/soprano_redlandbackend.dir/redlandutil.obj"
>>> "CMakeFiles/soprano_redlandbackend.dir/redlandworld.obj"
>>> "CMakeFiles/soprano_redlandbackend.dir/redlandstatementiterator.obj"
>>>  "CMakeFiles/soprano_redlandbackend.dir/redlandqueryresult.obj"
>>>  "CMakeFiles/soprano_redlandbackend.dir/redlandmodel.obj"
>>> "CMakeFiles/soprano_redlandbackend.dir/redlandparser.obj"
>>> "CMakeFiles/soprano_redlandbackend.dir/redlandbackend.obj"
>>> -Lc:\dep\bin\soprano -Lc:\PROGRA~1\WIN32L~1\lib
>>> -Lc:\Qt\4.3.0\lib -lsoprano -lrdf -Wl,-Bstatic -lQtCore4
>>> -Wl,-Bdynamic
>>>
> add a -Wl,--verbose  and run it.
>
> It should print which library is found or not and where it is
> search. This will give you some more hints.
>
> Ralf attempt to open c:\PROGRA~1\WIN32L~1\lib/librdf.dll.a failed
> attempt to open c:\PROGRA~1\WIN32L~1\lib/rdf.dll.a failed attempt
> to open c:\PROGRA~1\WIN32L~1\lib/librdf.a failed attempt to open
> c:\PROGRA~1\WIN32L~1\lib/librdf.dll failed attempt to open
> c:\PROGRA~1\WIN32L~1\lib/rdf.dll failed attempt to open
> c:\PROGRA~1\WIN32L~1\lib\librdf.a failed
It doesn't try librdf.lib (although it does in some other directories
that it tries). However, if I have two copies of it (one named rdf.lib
and another librdf.lib), it seems to be fine. Very strange.

- --
Windows NT 5.1.2600.2180 | Thunderbird 2.0.0.4 | Enigmail 0.95.1 | GPG
1.4.7
Key ID: 0x60A78FCB - available on major keyservers and upon request
Fingerprint: 4A84 CAE2 A0D3 2AEB 71F6 07FD F88E 0340 60A7 8FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iQEVAwUBRnv7G/iOA0Bgp4/LAQMCtwgAiHh3h0zPQzYPaptuBcMGrnL6BPK9l6iT
fxDxFZTRseRNYrNawpPimrUS62lZfc/cpsD7IL1SsyUEbvjmYG9Dv9c8a1N8yv41
h01M1jqLPFYr89PjLLnaPERYGi1XCx7WrGbFDwV2JE7WdRK5n1/Fu9u2DObDwFGh
b7CBPYk9jEi8UOG2gt0lSrc4KNSBUsT8xAJk7c/xFdI3UE8UrsIN74E5KgaVwG0V
l2QuerqKiuYwn0yFkcVgFFnKijMx6DR1mv2+gyGITwfqh5w63OXpwVzhnrpA9DJf
5XODrKpO9csIQtgpAHwOSvdKYPgxXR83/VnptBNPRC4+ABs98ARU3g==
=AnLe
-----END PGP SIGNATURE-----