Can you do "file blas.o" and post the output?
Maybe it's ifort than need as -m32 on it?
--
Mats
Can you do "file blas.o" and post the output?
Maybe it's ifort than need as -m32 on it?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
file blas.o gives
blas.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (GNU/Linux), not stripped
Can you answer to my last question concerning how to pass the function as an argument also ??
A function name will expand to the address of the function automagically, so SFUN_ and &SFUN_ is the same thing.
So, blas.o is a 32-bit object file. You need to use -m32 on the g++ compiler, and you do show that, so I'm not sure what is wrong - perhaps you need to have it BEFORE the file itself (e.g. "g++ -m32 x.cpp") - check with "file x.o" when you have run g++ on your source file.
Edit: I think the write_file_seq or whatever it is called is a fortran function, so you probably need to add some library to your linking list as well. Whilst looking for the correct name of that library, I found this: http://www.chiralcomp.com/support/mi...p/linking.html
Edit2: And this: http://softwarecommunity.intel.com/i.../30246677.aspx
Edit3: And: http://softwarecommunity.intel.com/i...ad/223602.aspx
--
Mats
Last edited by matsp; 08-15-2008 at 08:28 AM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
So I have tested what they recommend and here it is. I use two simple test programs called test.f and test.c
1) ifort
ifort -v test.f gives:
Version 9.0
/opt/intel/fc/9.0/bin/fortcom -D__INTEL_COMPILER=900 -D__ELF__ -D__INTEL_COMPILER_BUILD_DATE=20051201 -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -Dunix -Dlinux -D__i386 -D__i386__ -Di386 -mGLOB_pack_sort_init_list -I. -I/opt/intel/fc/9.0/include -I/opt/intel/fc/9.0/substitute_headers -I/usr/include -O2 -mP1OPT_version=900 -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 -mGLOB_tune_for_fort -mGLOB_use_fort_dope_vector -mP2OPT_static_promotion -mP1OPT_print_version=FALSE -mP3OPT_use_mspp_call_convention -mCG_use_gas_got_workaround=F -mP2OPT_align_option_used=TRUE -mGLOB_options_string=-v -mGLOB_cxx_limited_range=FALSE -mGLOB_as_output_backup_file_name=/tmp/ifortZBIJSOas_ -mGLOB_machine_model=GLOB_MACHINE_MODEL_IA32_NONE -mP2OPT_subs_out_of_bound=FALSE -mIPOPT_ninl_user_level=2 -mIPOPT_activate -mIPOPT_lite -mP2OPT_hlo_level=2 -mP2OPT_hlo -mIPOPT_obj_output_file_name=/tmp/ifortSzlKyt.o "-mGLOB_linker_version=2.15.92.0.2 20040927" -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS -mGLOB_obj_output_file=/tmp/ifortSzlKyt.o -mGLOB_source_dialect=GLOB_SOURCE_DIALECT_FORTRAN -mP1OPT_source_file_name=test.f test.f
ld /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o -dynamic-linker /lib/ld-linux.so.2 -m elf_i386 -o a.out /opt/intel/fc/9.0/lib/for_main.o /tmp/ifortSzlKyt.o -L/opt/intel/fc/9.0/lib -L/usr/lib -Bstatic -lifport -lifcore -Bdynamic -limf -lm -Bstatic -lirc -Bdynamic -lc -Bstatic -lirc_s -Bdynamic -ldl -lc /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtend.o /usr/lib/crtn.o
rm /tmp/ifortjmtCd9gas
rm /tmp/ifortZBIJSOas_
rm /tmp/ifortEEwSxuld
rm /tmp/ifortucUkdaarg
rm /tmp/ifortSzlKyt.o
2) g++
g++ test.c gives
Lecture des spécification à partir de /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
ModÚle de thread: posix
version gcc 3.4.6 20060404 (Red Hat 3.4.6-9)
/usr/libexec/gcc/x86_64-redhat-linux/3.4.6/cc1plus -quiet -v -D_GNU_SOURCE test.c -quiet -dumpbase test.c -mtune=k8 -auxbase test -version -o /tmp/ccucfvZc.s
le répertoire « /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../x86_64-redhat-linux/include » est ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/include
/usr/include
Fin de la liste de recherche.
GNU C++ version 3.4.6 20060404 (Red Hat 3.4.6-9) (x86_64-redhat-linux)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9).
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -V -Qy -o /tmp/ccYbsOyj.o /tmp/ccucfvZc.s
Version de l'assembleur GNU 2.15.92.0.2 (x86_64-redhat-linux) utilisant la version BFD 2.15.92.0.2 20040927
/usr/libexec/gcc/x86_64-redhat-linux/3.4.6/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccYbsOyj.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtend.o /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crtn.o
I am still reading if the next seems obvious to you, please let me know.
Thanks a lot.
Mike
I believe you want to add:
to the line:Code:-L/opt/intel/fc/9.0/lib -Bstatic -lifport -lifcore -Bdynamic -limf
I'm by far not convinced that is enough to make it work, but it's unlikely to make anything worse [since adding more libraries doesn't make any difference if the library isn't being used, but not having a library that is used does definitely cause problems].Code:g++ minim.o blas.o sfun.o tn.o -m32
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Thanks, but the problem is that when I do
g++ minim.o tn.o sfun.o blas.o -L/opt/intel/fc/9.0/lib -Bstatic -lifport -lifc
I get
/usr/bin/ld: escamotage incompatible /opt/intel/fc/9.0/lib/libifport.so.5 lors de la recherche de libifport.so.5
/usr/bin/ld: ne peut trouver libifport.so.5
collect2: ld a retourné 1 code d'état d'exécution
And when I do
g++ minim.o tn.o sfun.o blas.o -m32 -L/opt/intel/fc/9.0/lib -Bstatic -lifport -lifc
I get
minim.o(.text+0x169): In function `main':
: undefined reference to `SFUN_'
minim.o(.text+0x1a7): In function `main':
: undefined reference to `LMQN_'
collect2: ld a retourné 1 code d'état d'exécution
By the way If you or anyone else wants to have a go and try to call this library from a c++ program here is the link for the Netlib truncated newton optimization method:
http://iris.gmu.edu/~snash/nash/software/tn.f
Thanks a lot.
Mike
It would help cut down on the bandwidth if you could write a 10-line Fortran program that you want to link with a 10-line C program.
Something simple, like add two numbers together.
At least then we can all see exactly what's going on.
You may figure it out yourself from only having one or two error messages to deal with instead of dozens.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Also, since a lot of members here don't speak/read french, translating the error messages to English would increase the number of people that may know how to fix the problem (it does not have to be translated precisely, but a rough translation is nearly always enough) [I can just about figure out what is fish or meat when I see a french menu, and I couldn't ask for the directions to the toilet - but sometimes I can sort of guess the meaning of an error message because the words are similar enough to words that I know from English or Swedish].
Salem's suggestion is also very good - make a simple test-case first, then try more complex stuff stepwise - then you will know which change made the difference.
I'm fairly convinced you need the -m32 option on your g++ line, even though I don't actually understand what the error message says for your first link attempt.
In your -m32 link attemp, it seems like the name of the functions are wrong - perhaps you can use "nm sfun.o" to see what the actual names are.
--
Mats
Last edited by matsp; 08-17-2008 at 08:39 AM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Just one (offtopic) question. Would (on linux) "LOCALE=en_US gcc ..." make it in english? (I have only one locale (english) installed and can't test).
EDIT: I mean, is english hardcoded into gcc so it doesn't need locale files for english?
Last edited by rasta_freak; 08-17-2008 at 09:12 AM.
Hi everyone.
Salem I followed your advice and tested my problem on very simple programs.
First the c code test2.c that calls a fortran function
And the fortran function pseudoLMQN.fCode:#include <stdio.h> #include <stdlib.h> #include <math.h> void SFUN(int *N, double *X, double *F, double *G) { int i; double T; *F=0.0; for (i = 0 ; i < *N ; i++) { T = 2*X[i] - i; *F = *F +T*T; G[i] = 2.0 * T; } } int main(void) { int N=200; double F=-1000.0; double G[300],X[300]; extern void pseudoLMQN_(int *N, double X[], double *F, double G[], void (*SFUN)(int *N, double X[], double *F, dou ble G[])); printf("F before test is %lf\n",&F); pseudoLMQN_(&N, X, &F, G, SFUN); printf("F after test is %lf\n",&F); }
Code:SUBROUTINE LMQN (N, X, F, G, SFUN) IMPLICIT NONE INTEGER N DOUBLE PRECISION X(N), G(N), F, FNEW EXTERNAL SFUN CALL SFUN(N,X,FNEW,G) F=FNEW+1.0 RETURN END
I included the function that I pass as an argument to the fortran function in the c code. For the rest the problem is similar to the previous threads.
I compile like that :
gcc -c test2.c
ifort -c pseudoLMQN.f
gcc test2.c pseudoLMQN.o
and I get the following errors :
/usr/bin/ld: AVERTISSEMENT: architecture i386 du fichier d'entrée « pseudoLMQN.o » est incompatible avec la sortie i386:x86-64
test2.o(.text+0x100): In function `main':
: undefined reference to `pseudoLMQN_'
collect2: ld a retourné 1 code d'état d'exécution
Concerning the errors in french, it is all greek to me so I cannot really translate it. Sorry about that.
But I think there is still a problem with the way I link the two programs.
Any ideas ??
Thanks a lot.
In pseudoLMQN read
Code:SUBROUTINE pseudoLMQN(N, X, F, G, SFUN) IMPLICIT NONE INTEGER N DOUBLE PRECISION X(N), G(N), F, FNEW EXTERNAL SFUN CALL SFUN(N,X,FNEW,G) F=FNEW+1.0 RETURN END
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Hi again, I added what you suggested
Now I type
gcc -c -m32 test2.c
ifort -c pseudoLMQN.f
gcc -m32 test2.c pseudoLMQN.o
and I get
test2.o(.text+0xd6): In function `main':
: undefined reference to `pseudoLMQN_'
collect2: ld a retourné 1 code d'état d'exécution
A bit better, but still ????
test2.c doesn't seem to be able to use the fortran function pseudoLMQN_ defined in pseudoLMQN.f. Any ideas anyone?
Thanks
do "nm pseudoLMQN.o |grep -i pseudoLMQN > somefile.txt" and post the content of "somefile.txt".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
somefile.txt contains :
0000000000000000 T pseudolmqn_
??