Hey guys,
I just wanted to let you know that following the readme build directions
resulted in a successful build. For me the key way to build the
dependencies first and it is now documented clearly.
All is well and the benchmark looks great. It's really coming along
nicely. Great work Namik!
blas, vector and copy benchmarks ran great. Sparse fails though...
Here are a few lines from the call stack. I haven't really looked into it
yet in case you guys already knew what was up and were seeing the same
thing.
Lastly, you two have any interest in having me send you a fully compiled
standalone MSVC2013 version? You would just need to install the runtime.
I don't have gcc and I'd be curious which compiler does a better job.
Thanks,
-Matt
First-chance exception at 0x00007FF681BB4D7B in ViennaCL_Benchmark.exe:
0xC0000005: Access violation reading location 0x0000000000000000.
Unhandled exception at 0x00007FF681BB4D7B in ViennaCL_Benchmark.exe:
0xC0000005: Access violation reading location 0x0000000000000000.
ViennaCL_Benchmark.exe!Benchmark_Sparse::run_benchmark<double>() Line
124 C++
ViennaCL_Benchmark.exe!Benchmark_Sparse::execute() Line 345 C++
ViennaCL_Benchmark.exe!Benchmark_Sparse::qt_static_metacall(QObject *
_o, QMetaObject::Call _c, int _id, void * * _a) Line 72 C++
Qt5Cored.dll!QMetaObject::activate(QObject * sender, int signalOffset,
int local_signal_index, void * * argv) Line 3682 C++
Qt5Cored.dll!QMetaObject::activate(QObject * sender, const QMetaObject *
m, int local_signal_index, void * * argv) Line 3547 C++
Qt5Cored.dll!QThread::started(QThread::QPrivateSignal __formal) Line
153 C++
Qt5Cored.dll!QThreadPrivate::start(void * arg) Line 406 C++
On Sun, Aug 3, 2014 at 6:22 AM, Karl Rupp <[email protected]> wrote:
> Hi,
>
>
> > I couldn't help myself from trying to make a more convenient build
>
>> process for zlib and libarchive.
>>
>> I added a new CMakeLists.txt to the external folder. It's purpose is to
>> build both zlib and libarchive in one go. It seems to work alright on my
>> machine. One CMake configure and one mingw32-make command generates the
>> library files for both zlib and libarchive. I don't know how robust the
>> process is, but it would definitely be neat to make it work in this way.
>>
>
> The issue of taking the correct versions of libarchive were mentioned in
> my previous email. The problem with CMake, though, is that CMakeLists.txt
> in libarchive contains a find_package(zlib), which I doubt will work when
> using add_subdirectory(). The reason is that at the point of probing zlib,
> the (static) zlib library has not been built yet, so find_package() will
> *always* fail. You can find some background on this in this write-up:
> https://coderwall.com/p/y3zzbq
> The suggested use of external_project() is probably worth a try, but zlib
> does not export its targets. This implies that we would have to modify
> CMakeLists.txt from zlib, which is something I'd really like to avoid, as
> it will sooner or later result in maintaining our own zlib repository.
> Anyway, feel free to play with that, maybe you can find a more convenient
> solution to this.
>
>
> One thing to note is that zconf.h kept on being renamed to zconf.h.in
>> <http://zconf.h.in> by CMake, which prevented compiling zlib. I had to
>>
>> manually rename it back to zconf.h after each CMake configuring.
>>
>
> I noticed the same, but it is not a problem if you build in-source, i.e.
> source dir and build dir are equal. CMake generates a 'new' zconf.h in the
> build directory. Another reason to follow the build instructions closely ;-)
>
>
>
> And if we were to go back to submodules, we could build all the
>> dependencies with no more than 4 commands:
>> 1. git submodule update ---init (both zlib and libarchive automatically
>> fetched by git)
>>
>
> won't work with libarchive because of build failures if the version of
> archive and the OS version don't match up.
>
>
> 2. configure external CMake build (properly prepare libarchive with zlib)
>> 3. generate external CMake makefiles
>>
>
> 2.) and 3.) don't sound much shorter than what we have now?
>
>
> 4. build the libs (generate zlib, then libarchive libs with one make
>> command)
>>
>
> This boils down to find_package() in libarchive being able to detect zlib
> without zlib being built yet...
>
>
>
> Would this be a good solution to simplify the build process? Is it
>> feasible?
>>
>
> I tried various options yesterday for a couple of hours but could not find
> a fully satisfying solution. This does not mean that there is no better way
> than what we have now, but at least the current build process is verified
> to work on two different OSes with different compilers. More than we had
> before ;-)
>
> Best regards,
> Karli
>
>
--
--------------------
Matthew Musto
[email protected]
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
