Message: 3
Date: Wed, 30 Jan 2013 10:06:49 +0100
From: "Holtgrewe, Manuel" <manuel.holtgrewe@fu-berlin.de>
To: SeqAn Development <seqan-dev@lists.fu-berlin.de>
Subject: Re: [Seqan-dev] Zlib linking errors under 64bit Windows 7
Message-ID:
	<FCCAB9D80C3DAB47B5601C5B0E62872B2943507F@ex02b.campus.fu-berlin.de>
Content-Type: text/plain; charset="iso-8859-1"

Hi Theo,

Can you send me the linker command?

There are two possible sources of problems that I can see:

(1) The contribs are not picked up correctly and zlib is not linked in correctly.
(2) You are trying to link a 32 bit program (indicated by Win32) against the 64 bit library (indicated by the path C:\...-x64).

My guess is that (2) is the problem but I could be wrong. To generate build files for 64 bit windows in CMake, use the Generator "Visual Studio XX Win64", i.e. the Win64 variant is important.

Linking on Windows was pretty painful in my opinion. I could not get correctly redistributeable DLLs (you still need some library file for the linking apparently) so we redistribute object files for static linking. Note that at least for static libraries, you need to link debug builds against debug-built libraries. The SeqAn build system currently takes care of this.

I wish this was easier but I could not find a better way or anyone who could tell me about a better way.

Cheers,
Manuel

________________________________
From: Theodore Omtzigt [theo@stillwater-sc.com]
Sent: Tuesday, January 29, 2013 7:31 PM
To: SeqAn Dev List
Subject: [Seqan-dev] Zlib linking errors under 64bit Windows 7

I am not having much luck getting unstuck on a zlib linking error to unlock the goodness of SequenceStream on gz compressed files. In short, I cannot get the right zlib symbols between seqan calling and zlib binding:

1>------ Build started: Project: count_kmers, Configuration: Release Win32 ------
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzclose referenced in function "void __cdecl seqan::close(class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &)" (?close@seqan@@YAXAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@@Z)
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzeof referenced in function "bool __cdecl seqan::streamEof(class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &)" (?streamEof@seqan@@YA_NAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@@Z)
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzerror referenced in function "int __cdecl seqan::streamError(class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &)" (?streamError@seqan@@YAHAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@@Z)
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzread referenced in function "unsigned int __cdecl seqan::streamReadBlock(char *,class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &,unsigned int)" (?streamReadBlock@seqan@@YAIPADAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@I@Z)
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzopen referenced in function "bool __cdecl seqan::open(class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &,char const *,char const *)" (?open@seqan@@YA_NAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@PBD1@Z)
1>count_kmers.obj : error LNK2019: unresolved external symbol _gzdopen referenced in function "bool __cdecl seqan::open(class seqan::Stream<struct seqan::Tag<struct seqan::GZFile_> > &,char const *,char const *)" (?open@seqan@@YA_NAAV?$Stream@U?$Tag@UGZFile_@seqan@@@seqan@@@1@PBD1@Z)
1>D:\Build\vs10\bioinformatics\apps\Stillwater-bio\seqan\apps\count_kmers\Release\count_kmers.exe : fatal error LNK1120: 6 unresolved externals

When I DUMPBIN the symbols in zlib.lib in C:\seqan-contrib-D20111031-x64\vs10\lib, the error can be explained as the above mentioned symbols are not in the library file. Instead they are the gzopen/gzeof/gzerror/gzclose variants.

I went back to built zlib on my system so that I could generate very specific zlib versions, and the variety that does produce the _gz### versions is the multi-threaded DLL C++ run-time version. However, the experiment where I link directly with this version of the library STILL produces the same errors, so I now thinking that it has to do with not having the right defines to specialize the zlib API. Has anyone successfully solved this problem on Windows?

Looking forward to a solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fu-berlin.de/pipermail/seqan-dev/attachments/20130130/384d2e0a/attachment.html>

------------------------------

_______________________________________________
seqan-dev mailing list
seqan-dev@lists.fu-berlin.de
https://lists.fu-berlin.de/listinfo/seqan-dev

End of seqan-dev Digest, Vol 40, Issue 3
****************************************