I'm making a library by compiling several fortran sources.
Compilation of each source is OK but when making the library with the call to ar I obtain an error.
Here is the full log obtained :
-------------- Générer : libsphr dans Test (compilateur : Compilateur Fortran GNU)---------------
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\error_mesg.f90 -o obj\Test\error_mesg.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\math_latlon_to_vect.f90 -o obj\Test\math_latlon_to_vect.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\sphr_module_variables.f90 -o obj\Test\sphr_module_variables.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\stripack.f90 -o obj\Test\stripack.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\stripack_module_variables.f90 -o obj\Test\stripack_module_variables.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\sphr_init.f90 -o obj\Test\sphr_init.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\sphr_recup_lum.f90 -o obj\Test\sphr_recup_lum.o
mingw32-gfortran.exe -Jobj -w -Wall -finit-real=nan -O2 -fbounds-check -Wuninitialized -ftrapv -fimplicit-none -fno-automatic -I..\inc -c D:\Users\Gerard\Test\sphr_vis_crira_2_sphr.f90 -o obj\Test\sphr_vis_crira_2_sphr.o
ar.exe -r ..\lib\libsphr.a obj\Test\error_mesg.o obj\Test\math_latlon_to_vect.o obj\Test\sphr_module_variables.o obj\Test\stripack.o obj\Test\stripack_module_variables.o obj\Test\sphr_init.o obj\Test\sphr_recup_lum.o obj\Test\sphr_vis_crira_2_sphr.o\nranlib ..\lib\libsphr.a
ar.exe: creating ..\lib\libsphr.a
ar.exe: obj\Test\sphr_vis_crira_2_sphr.o\nranlib: No such file or directory
Le processus s'est terminé avec le code d'état 1 (2 minute(s), 9 seconde(s))
0 erreur(s), 0 avertissement(s) (2 minute(s), 9 seconde(s))
I think the problem comes from the \nranlib added at the end of enumeration of .o files in the ar command. The last .o is misinterpreted as a full name "obj\Test\sphr_vis_crira_2_sphr.o\nranlib" which does not exists, but obj\Test\sphr_vis_crira_2_sphr.o exists.
I have seen that in options_gfortran.xml there is a line with \nranlib (163). Could my problem comes from here ? What I can do ?
I use CB svn 8800 on windows xp compiled by myself, and tdm 4.7.1 compilers (gcc and gfortran).
gd_on
PS : this \nranlib appears in 3 other xml files.
PS 2 : May be I'm wrong but I suppose that this command at line 163 in options_gfortran.xml is in fact 2 commands separated by a new line character (the \n). On my PC, it's not interpreted correcly. But, may be it's possible to replace this 2 line command, by only a 1 line command, beginning by ar -s -r, so something like $lib_linker -s -r $static_output $link_objects. Adding -s should do the same thing than adding a call to ranlib ? it that right ? on every system ?
I have also this problem on a CentOS machine. But, strangely, on a Redhat one it works : the \n on the ar line (within options-gfortran.xml) is correctly interpreted!
gd_on
Is it possible to provide a sample project which reproduces this problem?
hint: you can copy the files for your project and then you can replace the content with something that just compiles.
I'll try do provide a test case tomorrow.
gd_on
Here is a small test case.
With standard line 163 in options_gfortran.xml, gives the error.
No error if I delete the \nranlib $static_output, it works.
I can also add -s just before -r, but I'm not sure it's usefull : I see no diffrence on the size of the built library.
gd_on
PS : the .cbp file is inside the make subfolder
Alpha: Can you look at this problem?
Quote from: oBFusCATed on February 01, 2013, 12:27:10 AM
Alpha: Can you look at this problem?
Will do, as time permits.
Quote from: Alpha on February 01, 2013, 04:05:23 AM
[...] as time permits.
... Might take a little longer than expected. I seem to have killed my package manager. (If anyone happens to know what to do when
update-initramfs: Generating /boot/initrd.img-3.2.0-37-generic-pae hangs indefinitely, you could save me a reinstall.)
Probably you can use a rescue-cd
Sorry, I have not yet been able to test, however, this seems to be the section that is causing the problem.
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8834)
+++ src/sdk/compiler.cpp (working copy)
@@ -960,7 +960,9 @@
else if (node->GetName() == wxT("Command"))
{
wxString cmd = node->GetAttribute(wxT("name"), wxEmptyString);
- CompilerTool tool(value, node->GetAttribute(wxT("ext"), wxEmptyString),
+ wxString unEscape = value;
+ unEscape.Replace(wxT("\\n"), wxT("\n")); // a single tool can support multiple commands
+ CompilerTool tool(unEscape, node->GetAttribute(wxT("ext"), wxEmptyString),
node->GetAttribute(wxT("gen"), wxEmptyString));
CommandType cmdTp = ctCount;
if (cmd == wxT("CompileObject"))
I have tried this patch on several machines (Windows 7, XP, CentOS 5, Redhat 5), with the test case sent previously. I think it works.
Nevertheless, I have seen two other things, not related to this problem.
1) on only one of the machine (a CentOS one), I had to explicitely add in the compiler search path ../obj. If not, the .mod generated files are not found when sphr_init.f90 is compiled.
2) I have set explicitly compiling priorities to be sure that .mod files are created before their use (I tried this with and without parallel generations) :
error_mesg.f90 to 0
math_latlon_to_vect.f90 to 50
sphr_init.f90 to 25
sphr_module_variables.f90 to 0
But after a full generation, priorities are changed :
math_latlon_to_vect.f90 to 0
sphr_init.f90 to 1
In this case, it's not really a problem, because error_mesg.f90 and sphr_module_variables.f90 really need to be compiled first, because the .mod generated are then used by sphr_init.f90.
math_latlon_to_vect.f90 is totally independant, so it's compilation priority is not a problem.
But, why priorities are automatically changed ?
I use self compiled svn 8812 on linux and self compiled svn 8835 on Windows.
gd_on
Alpha:
Would this feature work for my rm+ar feature request while building static libs?
What should I do to add rm before the ar command in the last step of building static libs?
Quote from: gd_on on February 05, 2013, 11:18:01 AM
But, why priorities are automatically changed ?
This should not be happening... I am looking into it.
Quote from: oBFusCATed on February 07, 2013, 09:00:48 AM
Would this feature work for my rm+ar feature request while building static libs?
What should I do to add rm before the ar command in the last step of building static libs?
The way previously discussed (http://forums.next.codeblocks.org/index.php/topic,16904.0.html) involved hard coding so this worked always for all compilers. However, you could instead patch the option in each compiler you want it in. For example:
Index: src/plugins/compilergcc/resources/compilers/options_gcc.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_gcc.xml (revision 8834)
+++ src/plugins/compilergcc/resources/compilers/options_gcc.xml (working copy)
@@ -122,6 +122,8 @@
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -mwindows"/>
<Command name="LinkDynamic"
value="$linker -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output -Wl,--dll $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
+ <Command name="LinkStatic"
+ value="cmd /c if exist $static_output del $static_output\n$lib_linker -r -s $static_output $link_objects"/>
</if>
<else>
<Command name="LinkNative"
@@ -130,9 +132,9 @@
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
<Command name="LinkDynamic"
value="$linker -shared $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
+ <Command name="LinkStatic"
+ value="test -w $static_output && rm -f $static_output\n$lib_linker -r -s $static_output $link_objects"/>
</else>
- <Command name="LinkStatic"
- value="$lib_linker -r -s $static_output $link_objects"/>
<Common name="cmds"/>
<Common name="re"/>
The patch that was proposed in http://forums.next.codeblocks.org/index.php/topic,17424.msg119880.html#msg119880 has not been officially implemented. May be forgotten ?
Because, I think it's correct.
gd_on
Both patches are now in svn, lets see how it will work out. I've not tested them, because of lack of time unfortunately.
Thanks.
As I told, for the first patch, it's OK for me. I don't know for the second one.
gd_on
It seems that the second patch causes a build failure of the cb-unix.cbp project (for tinyxml target) on linux :(
Alpha: Do you know the reason?
The command test modifies the exit code, and I forgot to reset it. (Sorry for not noticing sooner; I do not often do full rebuilds.)
Index: src/plugins/compilergcc/resources/compilers/options_gcc.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_gcc.xml (revision 8853)
+++ src/plugins/compilergcc/resources/compilers/options_gcc.xml (working copy)
@@ -133,7 +133,7 @@
<Command name="LinkDynamic"
value="$linker -shared $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
<Command name="LinkStatic"
- value="test -w $static_output && rm -f $static_output\n$lib_linker -r -s $static_output $link_objects"/>
+ value="test -w $static_output && rm -f $static_output; echo -n\n$lib_linker -r -s $static_output $link_objects"/>
</else>
<Common name="cmds"/>
I've fixed it without the test, r8854...