libz.so.1 version for Cufflinks

[shurjo]

Hi,

I am getting this line in the shell error log when running Cufflinks using SGE:

/home/sensh/bin/cufflinks: /usr/lib64/libz.so.1: no version information available (required by /home/sensh/bin/cufflinks)

Can anyone give me a hint about what I need to do to solve this? Also, I should mention that the Cufflinks run itself is not terminating and all three output files are produced: it's just that I would like to understand what is causing this. I tried this:

[sensh@kirk ~]$ file /usr/lib64/libz.so.1
/usr/lib64/libz.so.1: symbolic link to `libz.so.1.2.3'

So it seems that libz.so.1 is available on the system.

Any help would be appreciated,

Thanks,

Shurjo

[jmarshall]

You don't say what operating system, distribution, or release thereof you're running on, or whether you built cufflinks yourself or downloaded a binary.

However, you would see this message if, for example, you were running on Debian Etch an executable that had been built on Debian Lenny against Lenny's zlib.

The executable downloadable from the cufflinks web page was built on Red Hat and includes a shared library version dependency on ZLIB_1.2.2 (similarly to if it had been built on Lenny). Your machine has a zlib that has been built without symbol versioning, which is what is causing the warning you are seeing.

Your machine has libz 1.2.3, which is better than cufflinks's desired version anyway. So in practice everything will be fine. (And if it wasn't, the explosion when some zlib function was unavailable would be rather noticeable!)

-- John

[shurjo]

You don't say what operating system, distribution, or release thereof you're running on, or whether you built cufflinks yourself or downloaded a binary.

However, you would see this message if, for example, you were running on Debian Etch an executable that had been built on Debian Lenny against Lenny's zlib.

The executable downloadable from the cufflinks web page was built on Red Hat and includes a shared library version dependency on ZLIB_1.2.2 (similarly to if it had been built on Lenny). Your machine has a zlib that has been built without symbol versioning, which is what is causing the warning you are seeing.

Your machine has libz 1.2.3, which is better than cufflinks's desired version anyway. So in practice everything will be fine. (And if it wasn't, the explosion when some zlib function was unavailable would be rather noticeable!)

-- John

Hi John,

Thanks for the very lucid explanation. FYI, I am running CentOS release 5.4 (Final) and using the precompiled binary for cufflinks v0.9.2. If I understand you correctly, an error caused by our cluster having libz_1.2.3 rather than libz.so.1 would be more along the lines of Cufflinks failing to complete a run rather than proceeding to completion but containing cryptic errors in the output?

Best regards,

Shurjo

[jdjax]

Dear John or Shurjo,

I am receive the same error message as discussed in this thread. But I do not understand your answers and have no idea how to fix it. Can either one of you please explain in further detail what is the problem and now to fix it.

I am running cufflinks v1.0.3 on a hp server with RHEL 5.4. and I am not sure if cufflinks was built or the binary was downloaded since the post doc in the group installed this program. I would appreciate your help in this matter. Thanks in advance.


[jadf@flseq sorted]$ cufflinks -o trial trinity_n_trial_inflorescence.sorted.bam
cufflinks: /usr/lib64/libz.so.1: no version information available (required by cufflinks)
You are using Cufflinks v1.0.3, which is the most recent release.
Warning: BAM header too large
File trinity_n_trial_inflorescence.sorted.bam doesn't appear to be a valid BAM file, trying SAM...

[DZhang]

Just did a quick google search and check if this helps:

http://www.vr.org/knowledgebase/3182/orusrorlocalorliborlibzso1-no-version-information-available-required-by-python.html

[enelkinsan]

I run cufflinks several times on the linux server (cufflinks v2.0.2, don't know about the server). One of these runs ended with the same error you have, the others were ok. Neither configuration, nor the cufflinks version has changed, the only difference was the sample .bam file it was running.

[nr23]

I have the same problem as above: I've run the exact same script (with different .bams) many times without error. Now it fufuses to run with:

cuffdiff: /lib64/libz.so.1: no version information available (required by cuffdiff)
cuffdiff v2.1.1 (4046M)

/var/spool/torque/mom_priv/jobs/1417075.stokes-svcs.ice.ichec.ie.SC: line 21: /work/cufflinks/Laevis7/six1.mo/merged_asm/merged.gtf: Permission denied
/var/spool/torque/mom_priv/jobs/1417075.stokes-svcs.ice.ichec.ie.SC: line 23: /work/tophat_out/control/rep1/control.1.bam,work/tophat_out/control/rep2/control.2.bam: No such file or directory

[GenoMax]

The error does not seem to be related to libz.

There is a permission denied error on the "merged.gtf" file (most likely for write operation). Have you checked the permissions on that directory tree (/ichec/work/nglif015b/cufflinks/Laevis7/six1.mo/)?

[nr23]

The permissions seem good on 'merged.gtf'

-rw-r--r-- 1 user acc 94M 2013-08-15 10:16 merged.gtf

I've write-enabled both files, but I've never had to do this before, and this doesn't fix the problem...

Weirdly it seems to run fine when run from the command line, but fails when submitted as a job...

[GenoMax]

The permissions seem good on 'merged.gtf'

-rw-r--r-- 1 user acc 94M 2013-08-15 10:16 merged.gtf

I've write-enabled both files, but I've never had to do this before, and this doesn't fix the problem...

I was referring to the directories above that file (which user/group owns those and do they have write permissions).

Weirdly it seems to run fine when run from the command line, but fails when submitted as a job...

This may be a case to diagnose with help of local cluster admins. Perhaps your PBS jobs do not run as "you" but some other user (though that would admittedly be an uncommon setup)?

[dpryan]

Perhaps your PBS jobs do not run as "you" but some other user (though that would admittedly be an uncommon setup)?

Alternatively, the job is running as the correct user, but the mount point on the node isn't setup correctly. I recently had fun with that situation.

[nr23]

Ah - ok. Is there a quick way to check the permission for the directory tree?

[GenoMax]

Ah - ok. Is there a quick way to check the permission for the directory tree?

You can do the following:

$ ls -lR  /work/ (or down the hierarchy as needed)

if you only want to see directories

$ ls -l /work/ | grep "^d"

[cchang]

Weirdly it seems to run fine when run from the command line, but fails when submitted as a job...

Initially I ran into the same problem:
I tried to submit a job but failed. Then I ran in command line and it worked.

Later I realized why:
In my job submission script, I had the following lines

cuffdiff -o diffout -b genome.fa -p 8 -u genes.gtf \
./C1_R1_thout/accepted_hits.bam \
./C2_R1_thout/accepted_hits.bam


Note that there is a space after each backslash symbol, and I was told that "\ " was interpreted as changing to a new line.
After I deleted the space after each backslash, the job could be submitted and completed without a problem. I was told that backslash alone means "line continuation", which is needed in this case.

In short, delete the space after each backslash, which may make a big difference (and in fact solved my problem).