This makes no sense.

[Ralf Habacker]

Andrew Berg schrieb:
> -----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.
>   
Which is used then ? This a packaging issue of the redland package, 
which should be fixed.

BTW: The linkers library search algorithmus is linker specific (mingw 
versus msvc) mingw linker uses import libraries extensions named .dll.a, 
msvc uses .lib, for c libraries they have the same format

The linker output you have send could be interpreted like shown below

attempt to open c:\PROGRA~1\WIN32L~1\lib/librdf.dll.a failed -> regular mingw import library 
attempt to open c:\PROGRA~1\WIN32L~1\lib/rdf.dll.a failed    -> try an alternative import library name 
attempt to open c:\PROGRA~1\WIN32L~1\lib/librdf.a failed     -> try static library  
attempt to open c:\PROGRA~1\WIN32L~1\lib/librdf.dll failed   -> try dll directly
attempt to open c:\PROGRA~1\WIN32L~1\lib/rdf.dll failed      -> try dll directly with an alternative name

as far as i remember (and you committed it) there may be .lib files also be searched, but I don't remember if with or without lib prefix. 

An optional workaround of your problem is to set REDLAND_LIBRARIES to c:\PROGRA~1\WIN32L~1\lib/librdf.dll or the related available dll name. 


Ralf