« previous next »
Pages: 1 2 [All]   Go Down

Author Topic: Problem with a call to ar  (Read 13173 times)

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Problem with a call to ar
« 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 ?
« Last Edit: January 25, 2013, 05:05:46 pm by gd_on »
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar. (May be a bug in xml compilers)
« Reply #1 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
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #2 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.
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar
« Reply #3 on: January 30, 2013, 07:15:38 pm »
I'll try do provide a test case tomorrow.

gd_on
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar
« Reply #4 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
« Last Edit: January 31, 2013, 11:36:59 am by gd_on »
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #5 on: February 01, 2013, 12:27:10 am »
Alpha: Can you look at this problem?
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Problem with a call to ar
« Reply #6 on: February 01, 2013, 04:05:23 am »
Quote from: oBFusCATed on February 01, 2013, 12:27:10 am
Alpha: Can you look at this problem?
Will do, as time permits.
Logged

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Problem with a call to ar
« Reply #7 on: February 03, 2013, 12:28:48 am »
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.)
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #8 on: February 03, 2013, 01:23:28 am »
Probably you can use a rescue-cd
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Problem with a call to ar
« Reply #9 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"))

Logged

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar
« Reply #10 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
« Last Edit: February 05, 2013, 11:21:56 am by gd_on »
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #11 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?
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Problem with a call to ar
« Reply #12 on: February 07, 2013, 05:08:34 pm »
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 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"/>
Logged

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar
« Reply #13 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
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #14 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.
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Problem with a call to ar
« Reply #15 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
Logged
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #16 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?
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Problem with a call to ar
« Reply #17 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"/>
 
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem with a call to ar
« Reply #18 on: February 23, 2013, 01:44:15 am »
I've fixed it without the test, r8854...
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]
Pages: 1 2 [All]   Go Up
« previous next »