Hi John,

Thank you so much for solving the problem for me.  I definitely learned 
something.  I’m trying to figure out where did you see the /usr/lib64/ 
specified.  I was trying to look for a second copy of libz.so that might cause 
a conflict but couldn’t find it and didn’t realize that it is in /usr/lib64.

Cheers,

Will  


William Hsiao
[email protected]



> On Feb 22, 2016, at 3:24 AM, John Marshall <[email protected]> wrote:
> 
> On 22 Feb 2016, at 08:34, William Hsiao <[email protected]> wrote:
>> Thanks for your help.  Below is the output you requested.  Btw, I was able 
>> to get Samtools to compile by issuing "sudo make LDFLAGS="-L/usr/local/lib”, 
>> where a newer version of zlib (libz.so.1.2.8) is available.  Could it be 
>> that the version that came with RHEL 6.2 just doesn't have the gzopen64 
>> defined?
> [...]
>> I still have trouble getting pysam to recognize the new version of libz and 
>> as a result, I still get a gzopen64 error when pysam is invoked.  If you 
>> have any suggestion for this problem 
>> (https://github.com/pysam-developers/pysam/issues/235), I would greatly 
>> appreciate it as well.
> [...]
>> sudo gcc -H -g -Wall -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. 
>> -Ihtslib-1.3 -c -o bedidx.o bedidx.c
> [...]
>> . /usr/local/include/zlib.h
> 
> The problem is that you were mixing the headers (/usr/local/include/zlib.h) 
> from the newer zlib with the library (/usr/lib64/libz.so) from the older 
> RHEL-package zlib.  And so you were pulling in functions that the old library 
> (of course) didn't supply.
> 
> As you have found, you can work around this by adding 
> LDFLAGS=-L/usr/local/lib to bump the newer library up the path so that you 
> are linking with the /usr/local/lib/libz.so corresponding to the headers you 
> are using.  To work around your pysam runtime problem, it may help to also 
> add -Wl,-rpath,/usr/local/lib so the right zlib library is found at runtime.
> 
> The real underlying problem here is that your machine has two copies of 
> development zlib files on it.  Due to vagaries of compiler paths, the headers 
> from /usr/local are found first by the compiler but the libraries from /usr 
> are found first by the linker.  This matters when you have incompatible 
> copies of headers/libraries for the same library in the two locations.  This 
> is something that your local system administrators are in a position to fix: 
> ideally there should only be one copy of the zlib development files in the 
> system paths, and the current situation is a bug on your local machine that 
> they should fix.
> 
>    John
> 
> --
> The Wellcome Trust Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a
> company registered in England with number 2742969, whose registered
> office is 215 Euston Road, London, NW1 2BE.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Samtools-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/samtools-help

Reply via email to