Announcement

Collapse
No announcement yet.

libz.so.1 version for Cufflinks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • cchang
    replied
    Originally posted by nr23 View Post
    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).
    Last edited by cchang; 01-17-2018, 01:31 PM.

    Leave a comment:


  • GenoMax
    replied
    Originally posted by nr23 View Post
    Ah - ok. Is there a quick way to check the permission for the directory tree?
    You can do the following:

    Code:
    $ ls -lR  /work/ (or down the hierarchy as needed)
    if you only want to see directories

    Code:
    $ ls -l /work/ | grep "^d"
    Last edited by GenoMax; 08-15-2013, 05:41 AM.

    Leave a comment:


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

    Leave a comment:


  • dpryan
    replied
    Originally posted by GenoMax View Post
    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.

    Leave a comment:


  • GenoMax
    replied
    Originally posted by nr23 View Post
    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).

    Originally posted by nr23 View Post
    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)?

    Leave a comment:


  • nr23
    replied
    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...

    Leave a comment:


  • GenoMax
    replied
    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/)?

    Leave a comment:


  • nr23
    replied
    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
    Last edited by nr23; 08-15-2013, 05:01 AM.

    Leave a comment:


  • enelkinsan
    replied
    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.

    Leave a comment:


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

    http://www.vr.org/knowledgebase/3182...by-python.html

    Leave a comment:


  • jdjax
    replied
    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.


    [[email protected] 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...

    Leave a comment:


  • shurjo
    replied
    Originally posted by jmarshall View Post
    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

    Leave a comment:


  • jmarshall
    replied
    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

    Leave a comment:


  • shurjo
    started a topic libz.so.1 version for Cufflinks

    libz.so.1 version for Cufflinks

    Hi,

    I am getting this line in the shell error log when running Cufflinks using SGE:
    Code:
    /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:
    Code:
    [[email protected] ~]$ 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
Working...
X