topic Re: ../elf/start.S ??? in Intel® Fortran Compiler

../elf/start.S ???

bflynt — Tue, 23 Jun 2009 22:19:14 GMT

Unable to locate source file "/usr/src/packages/BUILD/glibc-2.9/sysdeps/x86_64/elf/start.S"

Do you like to search for it manually?

What is this and how do I fix it???

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

My SetUp:

Intel Fortran & C++ compilers 11.0/083 on openSuse 11.1 64 bit
In my .bashrc file I source:
source /opt/intel/Compiler/11.0/083/bin/intel64/iccvars_intel64.sh
source /opt/intel/Compiler/11.0/083/bin/intel64/ifortvars_intel64.sh
source /opt/intel/Compiler/11.0/083/bin/intel64/idbvars.sh

Interestingly enough this still does not resolve the libraries for iidb so I also have to add the line:
export LD_LIBRARY_PATH=/opt/intel/Compiler/11.0/083/idb/lib/intel64:$LD_LIBRARY_PATH

I have the Java JRE 1.6 and development libraries installed

If I click NO I can go ahead and operate the debugger

Thanks,

Bryan

Re: ../elf/start.S ???

bflynt — Tue, 23 Jun 2009 22:25:13 GMT

Just as an add on:

I do compile my code with the -g flag for example my full compiler line is:
ifort -g -check bounds -check pointers -traceback -c Filename.F90

Thanks,
Bryan

Quoting - bflynt

Can someone direct me to my error? I've been looking over the forums but have found no answer.

When I start iidb by typing idb at the command line the gui starts up fine. When I try to load my program I get a small window saying.

Unable to locate source file "/usr/src/packages/BUILD/glibc-2.9/sysdeps/x86_64/elf/start.S"

Do you like to search for it manually?

What is this and how do I fix it???

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

My SetUp:

Intel Fortran & C++ compilers 11.0/083 on openSuse 11.1 64 bit
In my .bashrc file I source:
source /opt/intel/Compiler/11.0/083/bin/intel64/iccvars_intel64.sh
source /opt/intel/Compiler/11.0/083/bin/intel64/ifortvars_intel64.sh
source /opt/intel/Compiler/11.0/083/bin/intel64/idbvars.sh

Interestingly enough this still does not resolve the libraries for iidb so I also have to add the line:
export LD_LIBRARY_PATH=/opt/intel/Compiler/11.0/083/idb/lib/intel64:$LD_LIBRARY_PATH

I have the Java JRE 1.6 and development libraries installed

If I click NO I can go ahead and operate the debugger

Thanks,

Bryan

Re: ../elf/start.S ???

Steven_L_Intel1 — Wed, 24 Jun 2009 16:08:52 GMT

I accidentally deleted a reply from user eliosh which said "You can safely ignore this message."

Re: ../elf/start.S ???

John4 — Wed, 24 Jun 2009 20:12:02 GMT

OK, good to know that I'm not the only one having problems with idb. In my case the exact message is:

Unable to locate source file "/build/buildd/glibc-2.9/sysdeps/x86_64/elf/start.S"
Do you like to search for it manually?

I thought the message was related to the installer's issuing of warnings about missing dependencies on Ubuntu (9.04), but since it happens on OpenSUSE as well, it's certainly not a debian-related problem.

In my case, Synaptic lists libc6, libc6-dev,libc6-i386, libc6-dev-i386, libc6-pic and libc6-prof as installed, so I guess the glibc dependencies are satisfied ---besides, I have g++, libstdc++5, libstdc++6, lib32stdc++6, ia32-libs, sun-java6 (v. 1.6-13) and ia32-sun-java6 installed as well.

After pressing the No button on the dialog box, I can start debugging my applications, but I keep getting crashes every time, after using any evaluation window. Sometimes there's just a message at the status bar, stating that the evaluation is in progress, but besides iidb and/or java increasing their memory usage, nothing happens and I end up just killing the debugger.

If I use the p (print ) command instead of the evaluation window, there's no crash at all, so my guess is that the problem is not in the debugger itself but in eclipse/java.

I'm using IFC 11.1 now, but the same issues happened with 11.0 as well.

Re: ../elf/start.S ???

tracyx — Fri, 26 Jun 2009 10:48:39 GMT

Quoting - John

I have similar problems when trying to use the graphical idb. for me, it is completely unusable.

Re: ../elf/start.S ???

eliosh — Fri, 26 Jun 2009 11:16:06 GMT

Quoting - John

OK, good to know that I'm not the only one having problems with idb. In my case the exact message is:

Unable to locate source file "/build/buildd/glibc-2.9/sysdeps/x86_64/elf/start.S"
Do you like to search for it manually?

I thought the message was related to the installer's issuing of warnings about missing dependencies on Ubuntu (9.04), but since it happens on OpenSUSE as well, it's certainly not a debian-related problem.

In my case, Synaptic lists libc6, libc6-dev,libc6-i386, libc6-dev-i386, libc6-pic and libc6-prof as installed, so I guess the glibc dependencies are satisfied ---besides, I have g++, libstdc++5, libstdc++6, lib32stdc++6, ia32-libs, sun-java6 (v. 1.6-13) and ia32-sun-java6 installed as well.

After pressing the No button on the dialog box, I can start debugging my applications, but I keep getting crashes every time, after using any evaluation window. Sometimes there's just a message at the status bar, stating that the evaluation is in progress, but besides iidb and/or java increasing their memory usage, nothing happens and I end up just killing the debugger.

If I use the p (print ) command instead of the evaluation window, there's no crash at all, so my guess is that the problem is not in the debugger itself but in eclipse/java.

I'm using IFC 11.1 now, but the same issues happened with 11.0 as well.

As far as I understand start.S is a part of libc sources. I'm doubtful you want to debug it.

Re: ../elf/start.S ???

Rob_Mueller-Albrecht — Mon, 29 Jun 2009 14:56:28 GMT

Hi Bryan,

the warning message ".... start.S not found do you want to search for it manually" indicates that the application loaded into the debugger contains references for symbol info in start.S.

All this really means is that your application uses libc and that for some reason the libc you are using is not fully stripped of symbol info.

This in itself should really be harmless. You can either try to make sure that your libc does not have any symbol info in it at all, or you can create a source rule that maps the symbols for start.S if you are intersted in debugging it or you can do as you did and simply ignore the warning.

Thanks, Rob

Re: ../elf/start.S ???

Rob_Mueller-Albrecht — Mon, 29 Jun 2009 14:59:36 GMT

Hi John and Tracy,

the stability issue when reading or evaluation a variable (I assume it would be like a struct with a complex and large set of arrays and pointers underneath it), is different than Bryan's warning about sybol info being available for libc and the source mapping for lthis not being accurate.

Your issue sounds more as though the debugger runs out of memory when trying to evaluate something.

Can you provide the exact definition of the set of variables you are trying to evauate when this happens?

Thanks, Rob

Re: ../elf/start.S ???

John4 — Fri, 03 Jul 2009 16:41:38 GMT

Quoting - Robert MuellerAlbrecht (Intel)

As I said before, I managed to be able to use the debugger without making it "crash", by using the p (print) command instead of the evaluation window, so it seems that the problem is in the GUI and not in the debugger itself.

My computer has 16 GB of RAM (plus 4 GB of swap), and the memory usage is always below 25% when the debugger becomes unstable. All the arrays in the code have the allocatable attribute. So it seems memory is not the issue here.

Re: ../elf/start.S ???

andres555 — Fri, 23 Oct 2009 04:59:15 GMT

Quoting - John

To me, the debugger crashes (i.e., becomes unstable and I have to kill it) after I add any variable to the evaluation window ---e.g., integer, real, character, derived type or derived type component. In some cases, the derived type might include arrays, but not always.

As I said before, I managed to be able to use the debugger without making it "crash", by using the p (print) command instead of the evaluation window, so it seems that the problem is in the GUI and not in the debugger itself.

My computer has 16 GB of RAM (plus 4 GB of swap), and the memory usage is always below 25% when the debugger becomes unstable. All the arrays in the code have the allocatable attribute. So it seems memory is not the issue here.

Hi guys! is now fixed for me.

I just downloaded glibc-2.9 using my synaptic manager. After that, i extract the file glibc-2.9.tar.lzma(that tar files is here! /usr/src/glibc) in a writable folder .

Later, i make a dir in the system files and i call /build/buildd/ and paste the extract folder there (You have to be "su" for do this!).

at the end you should have this path /build/buildd/glibc-2.9

thats all!