Hey,
wait - are we allowed to link Qt statically? I thought I read something in
> the net that the open source version of Qt only allows dynamic links?
As far as I know, Qt offers three licenses:
1. Commercial - both static & dynamic, both closed & open source, may
modify Qt source code as you please without publishing changes, not
required to say "This software uses Qt"
2. GPL - both static & dynamic, open source ONLY (so no issues there), must
publish all Qt source code modifications, required to say "This software
uses Qt"
3. LGPL - dynamic only, both closed & open source, cannot use modified Qt
dll files, required to say "This software uses Qt"
I've done quite a lot of research on the subject of Qt licensing and that's
how I interpret it.
> Well, if the static link works, why should we bother with a dynamic link?
> Note that QMake fails on Linux because there is no precompiled shared
> library in the repository, so the -llibarchive is only a shortcut and does
> not tell the full story.
Isn't dynamic building a lot faster than static? I'd rather spend time
maintaining a dynamic build system than waiting a couple of minutes to
compile the smallest modification.
And now I'm beginning to think that our QMake build is obsolete. If we're
going to depend on CMake to generate Zlib and Libarchive library objects,
then we might as well switch to CMake entirely. Is there a point in having
a QMake build that depends on CMake?
I have to say I like QMake more than CMake, and would like to see it stay
as an optional build system. Perhaps I could do the same thing I did with
OpenCL in QMake: make a CMakeLists.txt in external/ that could be used to
generate zlib and libarchive binaries. Specify in QMake to use these
CMake-generated binaries, and make a fallback to using user-specified
hard-coded locations. Is that complicating things too much?
As far as I can tell, we only need to dynamically link with Qt, don't we?
If we are to generate a single executable then we need to statically link
with Qt.
And let me get this straight: you were planning to dynamically link against
Qt, and statically against all other libraries? How does that even work? I
always thought it was either full dynamic or full static. That or some
heavy compiler configuring to allow both linking types.
Which problems did you run into? I got everything to compile on a fairly
> virgin Windows 7 yesterday, so my setup shouldn't be that different from
> yours.
Dynamic linking: crashes on start without any feedback.
Static linking: didn't compile Qt statically yet.
Regards,
Namik
On Sat, Aug 2, 2014 at 10:47 AM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
> Hi,
>
>
>
> > It seems I've been fighting with static qt the whole night. I still
>
>> haven't managed to compile it statically. The official script for static
>> qt compilation on windows does not work, of course. And manual compiling
>> with mingw32-make fails for no sensible reason... I sometimes feel like
>> they make things complicated on purpose.
>>
>
> wait - are we allowed to link Qt statically? I thought I read something in
> the net that the open source version of Qt only allows dynamic links?
>
>
>
> Namik just pushed a version which allows to also build it
>> dynamically. Will this work sufficiently well?
>>
>>
>> Unfortunately, it didn't work out the way I thought it would. I still
>> don't know what's the proper way to dynamically link libarchive with
>> CMake. In QMake it works just fine by specifying -llibarchive...
>>
>
> Well, if the static link works, why should we bother with a dynamic link?
> Note that QMake fails on Linux because there is no precompiled shared
> library in the repository, so the -llibarchive is only a shortcut and does
> not tell the full story.
>
>
>
> We will have to make sure Windows finds these dlls, which is
>> cumbersome... Any ideas how to ensure this? Copying the .dll files
>> to the .exe?
>>
>>
>> Copying dll files is the simplest solution. And it shouldn't be too
>> complicated, if only dynamic linking worked...
>>
>
> As far as I can tell, we only need to dynamically link with Qt, don't we?
>
>
>
> 1.) Boost: Namik, can you please remove all use of Boost (sources
>> plus build system files)? This is just required at very few
>> locations, mostly sparse stuff, so it shouldn't be a big deal. I'll
>> commit some matrix generation code soon, which will allow us to get
>> rid of all the IO and the testdata files, which is the primary use
>> of Boost.
>>
>>
>> I tried removing Boost usage some time ago, but failed since sparse
>> benchmark heavily depends on Boost. I couldn't manage to make it work by
>> replacing Boost ublas with ViennaCL linalg functions.
>>
>
> Ok, I'll take care of this.
>
>
>
> We still need the IO for benchmarking with MatrixMarket files, right?
>>
>
> No, this can also be achieved with the sparse matrix wrapper in ViennaCL.
>
>
>
> 3.) libarchive+zlib: It seems like in the current build setup the
>> zlib is not enabled in libarchive, as it tries to run 'gzip' as a
>> fallback. Namik, can you please have a look at that?
>>
>>
>> Libarchive will use zlib if ZLIB_INCLUDE_DIR and ZLIB_LIBRARY variables
>> are defined. ZLIB_INCLUDE_DIR would be the source code in
>> projectSourceFolder/external/zlib and ZLIB_LIBRARY would be the
>> generated zlib library in the projectBuildFolder/external/zlib. I
>> couldn't test this as I haven't managed to compile with CMake yet.
>>
>
> Which problems did you run into? I got everything to compile on a fairly
> virgin Windows 7 yesterday, so my setup shouldn't be that different from
> yours. The one thing that I found cumbersome, though, is that a
> reconfiguration in CMake does not work, so you always have to wipe the
> whole build folder whenever you change something in CMakeLists.txt
>
> My guide to a CMake build for the developer-repo will be finished soon,
> I'll drop you a short note when it's ready.
>
> Best regards,
> Karli
>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
