Problem with a call to ar

[gd_on]

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 :

Code Select Expand


-------------- 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 ?

[gd_on]

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

[oBFusCATed]

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.

[gd_on]

I'll try do provide a test case tomorrow.

gd_on

[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

[oBFusCATed]

Alpha: Can you look at this problem?

[Alpha]

Alpha: Can you look at this problem?

Will do, as time permits.

[Alpha]

[...] 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.)

[oBFusCATed]

Probably you can use a rescue-cd

[Alpha]

Sorry, I have not yet been able to test, however, this seems to be the section that is causing the problem.

Code Select Expand


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"))



[gd_on]

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

[oBFusCATed]

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?

[Alpha]

But, why priorities are automatically changed ?

This should not be happening... I am looking into it.

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 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:

Code Select Expand


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"/>


[gd_on]

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

[oBFusCATed]

Both patches are now in svn, lets see how it will work out. I've not tested them, because of lack of time unfortunately.