Code::Blocks Forums

User forums => Help => Topic started by: gd_on on January 25, 2013, 02:58:36 pm

Title: Problem with a call to ar
Post by: gd_on on January 25, 2013, 02:58:36 pm
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
-------------- 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 ?
Title: Re: Problem with a call to ar. (May be a bug in xml compilers)
Post by: gd_on on January 29, 2013, 12:20:53 pm
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
Title: Re: Problem with a call to ar
Post by: oBFusCATed on January 29, 2013, 07:44:43 pm
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.
Title: Re: Problem with a call to ar
Post by: gd_on on January 30, 2013, 07:15:38 pm
I'll try do provide a test case tomorrow.

gd_on
Title: Re: Problem with a call to ar
Post by: gd_on on January 31, 2013, 09:32:21 am
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
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 01, 2013, 12:27:10 am
Alpha: Can you look at this problem?
Title: Re: Problem with a call to ar
Post by: Alpha on February 01, 2013, 04:05:23 am
Alpha: Can you look at this problem?
Will do, as time permits.
Title: Re: Problem with a call to ar
Post by: Alpha on February 03, 2013, 12:28:48 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.)
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 03, 2013, 01:23:28 am
Probably you can use a rescue-cd
Title: Re: Problem with a call to ar
Post by: Alpha on February 04, 2013, 04:24:45 pm
Sorry, I have not yet been able to test, however, this seems to be the section that is causing the problem.
Code
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"))

Title: Re: Problem with a call to ar
Post by: gd_on on February 05, 2013, 11:18:01 am
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
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 07, 2013, 09:00:48 am
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?
Title: Re: Problem with a call to ar
Post by: Alpha on February 07, 2013, 05:08:34 pm
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 (http://forums.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:
Code
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"/>
Title: Re: Problem with a call to ar
Post by: gd_on on February 16, 2013, 10:57:02 am
The patch that was proposed in http://forums.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
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 16, 2013, 06:01:24 pm
Both patches are now in svn, lets see how it will work out. I've not tested them, because of lack of time unfortunately.
Title: Re: Problem with a call to ar
Post by: gd_on on February 17, 2013, 10:59:47 am
Thanks.
As I told, for the first patch, it's OK for me. I don't know for the second one.

gd_on
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 23, 2013, 12:27:01 am
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?
Title: Re: Problem with a call to ar
Post by: Alpha on February 23, 2013, 12:53:47 am
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.)
Code
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 &amp;&amp; rm -f $static_output\n$lib_linker -r -s $static_output $link_objects"/>
+                 value="test -w $static_output &amp;&amp; rm -f $static_output; echo -n\n$lib_linker -r -s $static_output $link_objects"/>
     </else>
     <Common name="cmds"/>
 
Title: Re: Problem with a call to ar
Post by: oBFusCATed on February 23, 2013, 01:44:15 am
I've fixed it without the test, r8854...