SGE failed to compile: undefined reference to sge_gdi2_send_any_request

[jdm64]

Hi,

I'm trying to compile the CVS source for SGE6.2u5 (mainly because the
provided binaries fail to install with ArchLinux x64). But I get the
following compiler error.

_________C_O_R_E__S_Y_S_T_E_M_____________
gcc -o test_performance
-L/off_home/gridengine/db-4.4.20/lx26-amd64/lib/ -L. -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx26-amd64
-L/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/lib
test_performance.o sig_handlers.o -lspoolloader -lspoolb -lspool -ldb
libspool.so libsgeobj.so libsgeobjd.so libsched.so liblck.so
libcull.so libcomm.so libcommlists.so libuti.so librmon.so -ldl
-ljemalloc /home/user/gridengine/source/3rdparty/plpa/plpa-1.3.1/LINUXAMD64_26/src/libplpa/.libs/libplpa.a
-lm -lpthread
/usr/bin/ld: warning: libgdi.so, needed by libsched.so, not found (try
using -rpath or -rpath-link)
libsgeobj.so: undefined reference to `sge_gdi2_send_any_request'
libsched.so: undefined reference to `sge_gdi_extract_answer'
collect2: ld returned 1 exit status
make: *** [test_performance] Error 1
not done

Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290029

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[jdm64]

Hi,

I'm trying to compile the CVS source for SGE6.2u5 (mainly because the
provided binaries fail to install with ArchLinux x64). But I get the
following compiler error.

_________C_O_R_E__S_Y_S_T_E_M_____________
gcc -o test_performance
-L/off_home/gridengine/db-4.4.20/lx26-amd64/lib/ -L. -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx26-amd64
-L/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/lib
test_performance.o sig_handlers.o -lspoolloader -lspoolb -lspool -ldb
libspool.so libsgeobj.so libsgeobjd.so libsched.so liblck.so
libcull.so libcomm.so libcommlists.so libuti.so librmon.so -ldl
-ljemalloc /home/user/gridengine/source/3rdparty/plpa/plpa-1.3.1/LINUXAMD64_26/src/libplpa/.libs/libplpa.a
-lm -lpthread
/usr/bin/ld: warning: libgdi.so, needed by libsched.so, not found (try
using -rpath or -rpath-link)
libsgeobj.so: undefined reference to `sge_gdi2_send_any_request'
libsched.so: undefined reference to `sge_gdi_extract_answer'
collect2: ld returned 1 exit status
make: *** [test_performance] Error 1
not done

Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=288691

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

Hi,

Post by jdm64
I'm trying to compile the CVS source for SGE6.2u5 (mainly because the
provided binaries fail to install with ArchLinux x64).

what kind of error did you get during installation? Maybe this can
easily be fixed and avoid the recompilation.

-- Reuti

Post by jdm64
But I get the
following compiler error.
_________C_O_R_E__S_Y_S_T_E_M_____________
gcc -o test_performance
-L/off_home/gridengine/db-4.4.20/lx26-amd64/lib/ -L. -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx26-amd64
-L/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/lib
test_performance.o sig_handlers.o -lspoolloader -lspoolb -lspool -ldb
libspool.so libsgeobj.so libsgeobjd.so libsched.so liblck.so
libcull.so libcomm.so libcommlists.so libuti.so librmon.so -ldl
-ljemalloc /home/user/gridengine/source/3rdparty/plpa/plpa-1.3.1/
LINUXAMD64_26/src/libplpa/.libs/libplpa.a
-lm -lpthread
/usr/bin/ld: warning: libgdi.so, needed by libsched.so, not found (try
using -rpath or -rpath-link)
libsgeobj.so: undefined reference to `sge_gdi2_send_any_request'
libsched.so: undefined reference to `sge_gdi_extract_answer'
collect2: ld returned 1 exit status
make: *** [test_performance] Error 1
not done
Justin Madru
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290029
To unsubscribe from this discussion, e-mail: [users-

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290416

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

I don't have the exact error message with me right now but the
general error was that the gethostname binary in the utils folder
could not be run.
running 'file' on it showed that it was a 64bit elf binary. Then I
tried to see if it was linking using 'ldd'. But ldd crashed saying
it couldn't find the file! I tried all path methods (and checked I
got the path right with ls) I could think of, but ldd kept crashing.
I got the same error trying to run the binary directly.
I also ran 'chmod +x' on the file.

I saw such output when there is a wrong version of a library in your
LD_LIBRARY_PATH Is it empty or set?

You can also try:

$ readelf -a gethostname

'ldd' is working for the usual applications like 'ls'?

-- Reuti

Justin Madru

Post by reuti
Hi,

Post by jdm64
I'm trying to compile the CVS source for SGE6.2u5 (mainly because the
provided binaries fail to install with ArchLinux x64).

what kind of error did you get during installation? Maybe this can
easily be fixed and avoid the recompilation.
-- Reuti

Post by jdm64
But I get the
following compiler error.
_________C_O_R_E__S_Y_S_T_E_M_____________
gcc -o test_performance
-L/off_home/gridengine/db-4.4.20/lx26-amd64/lib/ -L. -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx26-amd64
-L/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/lib
test_performance.o sig_handlers.o -lspoolloader -lspoolb -lspool -
ldb
libspool.so libsgeobj.so libsgeobjd.so libsched.so liblck.so
libcull.so libcomm.so libcommlists.so libuti.so librmon.so -ldl
-ljemalloc /home/user/gridengine/source/3rdparty/plpa/plpa-1.3.1/
LINUXAMD64_26/src/libplpa/.libs/libplpa.a
-lm -lpthread
/usr/bin/ld: warning: libgdi.so, needed by libsched.so, not found (try
using -rpath or -rpath-link)
libsgeobj.so: undefined reference to `sge_gdi2_send_any_request'
libsched.so: undefined reference to `sge_gdi_extract_answer'
collect2: ld returned 1 exit status
make: *** [test_performance] Error 1
not done
Justin Madru
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290029
To unsubscribe from this discussion, e-mail: [users-

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290555

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[jdm64]

Post by reuti
I saw such output when there is a wrong version of a library in your
LD_LIBRARY_PATH Is it empty or set?

The variable it not set. So, I guess it's using the system default for library path searching.

Post by reuti
$ readelf -a gethostname

Ok, readelf worked. The output is huge so you can read it at http://pastebin.com/jSryMxkY

Post by reuti
'ldd' is working for the usual applications like 'ls'?

Yes, ldd works for everything else. I've also done compiles and installs of Torque and Globus. So, I'm fairly confident it's not a corrupt system.


I think it might be easier to just figure out why it's not compiling. It should be an easy fix, just change some makefile.


Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290645

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

Post by jdm64

Post by reuti
I saw such output when there is a wrong version of a library in your
LD_LIBRARY_PATH Is it empty or set?

The variable it not set. So, I guess it's using the system default for library path searching.

Post by reuti
$ readelf -a gethostname

Ok, readelf worked. The output is huge so you can read it at http://pastebin.com/jSryMxkY

Post by reuti
'ldd' is working for the usual applications like 'ls'?

Yes, ldd works for everything else. I've also done compiles and installs of Torque and Globus. So, I'm fairly confident it's not a corrupt system.
I think it might be easier to just figure out why it's not compiling. It should be an easy fix, just change some makefile.

I just tried it with Archlinux and the problem is in SGE's install script that it looks for /lib64 to determine the glibc version. This needs to be changed to /lib in util/arch to succeed (at least in the plain 64 bit version of ArchLinux). Then you can install it, but the sgemaster won't start AFAICS - nothing in SGE's or system's messages file, nor in /tmp though.

NB: I don't have any problem with `ldd` for the binaries per se.

So, back to the original question: what were your steps when running ./aimk and so on? There weren't any errors or warnings for incompleteness before this one?

-- Reuti

Post by jdm64
Justin Madru
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290645

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290788

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

Post by reuti
I just tried it with Archlinux and the problem is in SGE's install script that it looks for /lib64 to determine the glibc version. This needs to be changed to /lib in util/arch to succeed (at least in the plain 64 bit version of ArchLinux). Then you can install it, but the sgemaster won't start AFAICS - nothing in SGE's or system's messages file, nor in /tmp though.

Ok, I guess I had the wrong fix. I made a system symlink to libc to where it was looking. Instead of changing util/arch in the installer.
You speak of sgemaster not being able to start? Is there any reason that you can think of why it wouldn't? Might compiling from source fix it?

Exactly, at the end of ./install_qmaster it only complains that it can't start the qmaster (I also tried by hand afterwards). But as said, absolutely no traces what's causing this (at least: I can't spot them).

Post by reuti
So, back to the original question: what were your steps when running ./aimk and so on? There weren't any errors or warnings for incompleteness before this one?

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

This was never necessary for me in the past. What did happen when you don't change it?

I'm unsure, whether it's worth to port SGE to a new distribution, as for now the follow up versions are closed source. For now I wonder anyway, what's so special with ArchLinux to create these hassle. As the "install" is also not working in the installation procedure (to install the startup scripts by ./install_qmaster), it looks like it's not following Linux Standard Base (LSB) for these scripts.

-- Reuti

2) Several references to files located outside the compile dir. "/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/" and "scratch4/dg222156/source_check/gridengine/source/3rdparty/plpa/plpa-1.3.1/config/". Fixed my making symlinks to the required target.
3) Similar to the current error, It couldn't find GE_LONGNAME or something similar. I don't remember exactly. Fixed by copying the string "Sun Grid Engine" into the locations that needed it -- or something similar.
./aimk -only-depend -no-dump
./scripts/zerodepend
./aimk -no-dump depend
./aimk -no-dump -shared-libs -spool-berkeleydb
I'm stuck there with the current compiler errors.
Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291035

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

Hi,

Post by reuti
Exactly, at the end of ./install_qmaster it only complains that it can't start the qmaster (I also tried by hand afterwards). But as said, absolutely no traces what's causing this (at least: I can't spot them).

I was finally able to install it by making the change in util/arch, removing the dir /lib64 and also removing all lib32* packages.
The installation completed without errors, and was able to load qmaster, but I couldn't load the scheduler (forgot the name). The problem was that binary was nowhere to be found!

Post by reuti

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

This was never necessary for me in the past. What did happen when you don't change it?

If I don't change it, I get a compiler error stating a re-declaration of getline with different arguments, I think.

is there any default library linked in unconditionally? I don't face this on openSUSE and never heard of it before.

Post by reuti
I'm unsure, whether it's worth to port SGE to a new distribution, as for now the follow up versions are closed source. For now I wonder anyway, what's so special with ArchLinux to create these hassle. As the "install" is also not working in the installation procedure (to install the startup scripts by ./install_qmaster), it looks like it's not following Linux Standard Base (LSB) for these scripts.

Yeah the ArchLinux startup scripts are not using sysvinit. But selecting manual startup should work.

"upstart" like Ubuntu? There exists at least some kind of compatibility layer and I had no problems installing it on that platform.

So, you don't know what I could change in the makefiles to fix the undefined reference errors?

I'm afraid: yes, I don't know. I would like to help you get it running on a new distribution though, but as SGE is no more open source and the changes will never make it to the Oracle version (once Rayson and I looked into the Linux/ppc64 port), maybe we should continue at Open Grid Scheduler fork:

http://sourceforge.net/projects/gridscheduler/files/

-- Reuti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291747

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[jdm64]

Post by reuti
Exactly, at the end of ./install_qmaster it only complains that it can't start the qmaster (I also tried by hand afterwards). But as said, absolutely no traces what's causing this (at least: I can't spot them).

I was finally able to install it by making the change in util/arch, removing the dir /lib64 and also removing all lib32* packages.

The installation completed without errors, and was able to load qmaster, but I couldn't load the scheduler (forgot the name). The problem was that binary was nowhere to be found!

Post by reuti

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

This was never necessary for me in the past. What did happen when you don't change it?

If I don't change it, I get a compiler error stating a re-declaration of getline with different arguments, I think.

Post by reuti
I'm unsure, whether it's worth to port SGE to a new distribution, as for now the follow up versions are closed source. For now I wonder anyway, what's so special with ArchLinux to create these hassle. As the "install" is also not working in the installation procedure (to install the startup scripts by ./install_qmaster), it looks like it's not following Linux Standard Base (LSB) for these scripts.

Yeah the ArchLinux startup scripts are not using sysvinit. But selecting manual startup should work.


So, you don't know what I could change in the makefiles to fix the undefined reference errors?


Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291127

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[fx]

I was finally able to install it by making the change in util/arch, removing the dir /lib64 and also removing all lib32* packages.

That can't be the right solution.

The installation completed without errors, and was able to load
qmaster, but I couldn't load the scheduler (forgot the name). The
problem was that binary was nowhere to be found!

Please look at <https://arc.liv.ac.uk/trac/SGE> and try the current
snapshot referred to, with the given build recipe, after undoing
whatever you did to the system library directories and packages. Try to
figure out what causes any problems during the build, and make a bug
report. Run it under script and, if necessary, send me (a compressed
version of) the typescript, as it would probably be too big to post to
the tracker above.

I don't know anything about Arch, but the current source builds OK on
the RedHat and Ubuntu systems I have.

Upstart, or whatever, is a different matter, but I'm surprised if you
can't use a normal init script on any GNU/Linux system currently, since
the replacements for sysvinit are rather new.

[fx]

Post by reuti

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

This was never necessary for me in the past. What did happen when you don't change it?

See getline(3) on a GNU system. If you don't need the change,
presumably your system doesn't default to defining _GNU_SOURCE, which
surprises me.

[reuti]

Post by fx

Post by reuti

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

This was never necessary for me in the past. What did happen when you don't change it?

See getline(3) on a GNU system. If you don't need the change,
presumably your system doesn't default to defining _GNU_SOURCE, which
surprises me.

I'm on openSUSE, and there it's not defined by default. As SGE is no GNU software anyway, maybe it would be good to reset this default flag before compiling SGE.

-- Reuti

Post by fx
--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=294599

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=295642

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[fx]

[Apologies if this turns up twice.]

Post by reuti

Post by fx
See getline(3) on a GNU system. If you don't need the change,
presumably your system doesn't default to defining _GNU_SOURCE, which
surprises me.

Sorry, that's wrong. I don't know what I was thinking, as I've dealt
with it often enough. _GNU_SOURCE is actually defined by aimk, so I
still don't know why it doesn't affect you.

Post by reuti
I'm on openSUSE, and there it's not defined by default. As SGE is no
GNU software anyway, maybe it would be good to reset this default flag
before compiling SGE.

The `GNU' bit is only relevant because it's the GNU library, I think.
It really means `kitchen sink' (he says, wondering what the equivalent
is in German etc.), i.e. everything. I'd guess if you turn it off
you'll need other definitions, but it seems cleanest to rename getline.
(It's one of the Fedora patches that has been languishing in IZ.)

[reuti]

Post by fx
[Apologies if this turns up twice.]

Post by reuti

Post by fx
See getline(3) on a GNU system. If you don't need the change,
presumably your system doesn't default to defining _GNU_SOURCE, which
surprises me.

Sorry, that's wrong. I don't know what I was thinking, as I've dealt
with it often enough. _GNU_SOURCE is actually defined by aimk, so I
still don't know why it doesn't affect you.

Post by reuti
I'm on openSUSE, and there it's not defined by default. As SGE is no
GNU software anyway, maybe it would be good to reset this default flag
before compiling SGE.

The `GNU' bit is only relevant because it's the GNU library, I think.
It really means `kitchen sink' (he says, wondering what the equivalent

Kitchen sink's word by word translation is "Küchenspüle", but the translation of the idom I would suggest "alles nötige" or "alles was nötig ist".

Maybe it depends on the version of used compiler, whether it can deal with mutiple declarations for the some function. The issue you refer to is from 2009, so I assume it was working before in general.

-- Reuti

Post by fx
is in German etc.), i.e. everything. I'd guess if you turn it off
you'll need other definitions, but it seems cleanest to rename getline.
(It's one of the Fedora patches that has been languishing in IZ.)
--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=295864

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=298858

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[jdm64]

Post by reuti
I just tried it with Archlinux and the problem is in SGE's install script that it looks for /lib64 to determine the glibc version. This needs to be changed to /lib in util/arch to succeed (at least in the plain 64 bit version of ArchLinux). Then you can install it, but the sgemaster won't start AFAICS - nothing in SGE's or system's messages file, nor in /tmp though.

Ok, I guess I had the wrong fix. I made a system symlink to libc to where it was looking. Instead of changing util/arch in the installer.

You speak of sgemaster not being able to start? Is there any reason that you can think of why it wouldn't? Might compiling from source fix it?

Post by reuti
So, back to the original question: what were your steps when running ./aimk and so on? There weren't any errors or warnings for incompleteness before this one?

Actually there were several errors, but I could fix all of them except this one because I'm not familiar with the makefiles. The other errors I ran into were:

1) 3rdparty/sge_depend/{parse.c,def.h,main.c} all had a getline function that was conflicting with the systems getline. Fixed by renaming to getline2

2) Several references to files located outside the compile dir. "/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/" and "scratch4/dg222156/source_check/gridengine/source/3rdparty/plpa/plpa-1.3.1/config/". Fixed my making symlinks to the required target.

3) Similar to the current error, It couldn't find GE_LONGNAME or something similar. I don't remember exactly. Fixed by copying the string "Sun Grid Engine" into the locations that needed it -- or something similar.

As for the steps I used to compile. I read the README and did the following steps:

./aimk -only-depend -no-dump
./scripts/zerodepend
./aimk -no-dump depend
./aimk -no-dump -shared-libs -spool-berkeleydb

I'm stuck there with the current compiler errors.

Justin Madru

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290879

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[jdm64]

I don't have the exact error message with me right now but the general error was that the gethostname binary in the utils folder could not be run.

running 'file' on it showed that it was a 64bit elf binary. Then I tried to see if it was linking using 'ldd'. But ldd crashed saying it couldn't find the file! I tried all path methods (and checked I got the path right with ls) I could think of, but ldd kept crashing. I got the same error trying to run the binary directly.

I also ran 'chmod +x' on the file.



Justin Madru

Post by reuti
Hi,

Post by jdm64
I'm trying to compile the CVS source for SGE6.2u5 (mainly because the
provided binaries fail to install with ArchLinux x64).

what kind of error did you get during installation? Maybe this can
easily be fixed and avoid the recompilation.
-- Reuti

Post by jdm64
But I get the
following compiler error.
_________C_O_R_E__S_Y_S_T_E_M_____________
gcc -o test_performance
-L/off_home/gridengine/db-4.4.20/lx26-amd64/lib/ -L. -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx26-amd64
-L/off_home/gridengine/openssl-0.9.8h-origin/lx26-amd64/lib
test_performance.o sig_handlers.o -lspoolloader -lspoolb -lspool -ldb
libspool.so libsgeobj.so libsgeobjd.so libsched.so liblck.so
libcull.so libcomm.so libcommlists.so libuti.so librmon.so -ldl
-ljemalloc /home/user/gridengine/source/3rdparty/plpa/plpa-1.3.1/
LINUXAMD64_26/src/libplpa/.libs/libplpa.a
-lm -lpthread
/usr/bin/ld: warning: libgdi.so, needed by libsched.so, not found (try
using -rpath or -rpath-link)
libsgeobj.so: undefined reference to `sge_gdi2_send_any_request'
libsched.so: undefined reference to `sge_gdi_extract_answer'
collect2: ld returned 1 exit status
make: *** [test_performance] Error 1
not done
Justin Madru
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290029
To unsubscribe from this discussion, e-mail: [users-

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=290549

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[lobosky]

Hi,
we have a problem,
some multi-threaded binaries (namely bfast and bwa) can't be used in qlogin sessions. Apparently threads can't be spawned and applications have to be used in single-thread way.
Is there anything that i have to modify with qconf to allow that ?

Thanks !
6.2e3 - Centos5.3

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291019

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[laotsao]

may be U need to submit jobs to PE env
e.g orte
qlogin -pe orte 4 <script>
for 4 threads
regards

Post by lobosky
Hi,
we have a problem,
some multi-threaded binaries (namely bfast and bwa) can't be used in qlogin sessions. Apparently threads can't be spawned and applications have to be used in single-thread way.
Is there anything that i have to modify with qconf to allow that ?
Thanks !
6.2e3 - Centos5.3
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291019

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291024

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[lobosky]

Thanks Laotsao ,
we already used "pe" with no effects.

Post by laotsao
may be U need to submit jobs to PE env
e.g orte
qlogin -pe orte 4 <script>
for 4 threads
regards

Post by lobosky
Hi,
we have a problem,
some multi-threaded binaries (namely bfast and bwa) can't be used in qlogin sessions. Apparently threads can't be spawned and applications have to be used in single-thread way.
Is there anything that i have to modify with qconf to allow that ?
Thanks !
6.2e3 - Centos5.3
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291019

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291024

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291029

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[reuti]

Hi,

Post by lobosky
we have a problem,
some multi-threaded binaries (namely bfast and bwa) can't be used in qlogin sessions. Apparently threads can't be spawned and applications have to be used in single-thread way.
Is there anything that i have to modify with qconf to allow that ?

there is nothing in SGE which would prohibit the usage of threads per se.

What did you submit and observe in detail?

-- Reuti

Post by lobosky
Thanks !
6.2e3 - Centos5.3
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291019

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291030

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[seandavi]

Post by lobosky
Hi,
we have a problem,
some multi-threaded binaries (namely bfast and bwa) can't be used in qlogin
sessions. Apparently threads can't be spawned and applications have to be
used in single-thread way.
Is there anything that i have to modify with qconf to allow that ?
Hi, Mauro.

SGE will, in general, not have anything to do with whether or not you can
run multiple threads on a node. SGE simply assumes that if the user asked
for 4 slots, 4 will be used. A user could use either more or fewer slots
which might lead to inefficiencies, etc., but SGE will not restrict that
from happening. Therefore, it is important to know what command line is
being used in the qlogin shell to run bwa and bfast. We run bwa through
SGE, in particular, on multiple threads daily.

Sean

Post by lobosky
Thanks !
6.2e3 - Centos5.3
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291019
To unsubscribe from this discussion, e-mail: [

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291032

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].