From: Derek G. <fri...@gm...> - 2013-01-22 16:38:01
|
Have you guys tried to do a static build of libMesh on Linux and "make install" it somewhere and then try to build a libMesh based application against that? It is not working for us... because of missing tecplot symbols (like "tecini"). It looks like the executables in libMesh (like meshplot, etc.) have this on their link line (I'm building in a build directory underneath the libMesh directory): ../contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a However, that tecio.a file doesn't get installed into the prefix directory when you do "make install"... so there is no way for a libMesh based application to do something similar. I was kind of thinking that that tecio.a would have been linked into the actual libMesh static library... then there would be no problems... What should we do about this? Derek |
From: John P. <pet...@cf...> - 2013-01-22 19:00:33
|
On Tue, Jan 22, 2013 at 9:37 AM, Derek Gaston <fri...@gm...> wrote: > Have you guys tried to do a static build of libMesh on Linux and "make > install" it somewhere and then try to build a libMesh based application > against that? > > It is not working for us... because of missing tecplot symbols (like > "tecini"). It looks like the executables in libMesh (like meshplot, etc.) > have this on their link line (I'm building in a build directory underneath > the libMesh directory): > > ../contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a > > However, that tecio.a file doesn't get installed into the prefix directory > when you do "make install"... so there is no way for a libMesh based > application to do something similar. > > I was kind of thinking that that tecio.a would have been linked into the > actual libMesh static library... then there would be no problems... > > What should we do about this? Just to add a bit more detail to this: if you configure libmesh with --enable-static --enable-shared, and make install then we get the following when running 'nm' on the static library. nm lib/libmesh_opt.a | grep tecini nm: tecio.a: File format not recognized nm: lt1-tecio.a: File format not recognized U tecini It seems to me that tecplot is unique in that it's a binary blob we download from the Tecplot website? -- John |
From: John P. <pet...@cf...> - 2013-01-22 19:01:04
|
On Tue, Jan 22, 2013 at 12:00 PM, John Peterson <pet...@cf...> wrote: > On Tue, Jan 22, 2013 at 9:37 AM, Derek Gaston <fri...@gm...> wrote: >> Have you guys tried to do a static build of libMesh on Linux and "make >> install" it somewhere and then try to build a libMesh based application >> against that? >> >> It is not working for us... because of missing tecplot symbols (like >> "tecini"). It looks like the executables in libMesh (like meshplot, etc.) >> have this on their link line (I'm building in a build directory underneath >> the libMesh directory): >> >> ../contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a >> >> However, that tecio.a file doesn't get installed into the prefix directory >> when you do "make install"... so there is no way for a libMesh based >> application to do something similar. >> >> I was kind of thinking that that tecio.a would have been linked into the >> actual libMesh static library... then there would be no problems... >> >> What should we do about this? > > Just to add a bit more detail to this: if you configure libmesh with > --enable-static --enable-shared, and make install then we get the > following when running 'nm' on the static library. That should be --enable-static --disable-shared! -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-01-22 19:06:24
|
On Jan 22, 2013, at 1:00 PM, John Peterson <pet...@cf...> wrote: > On Tue, Jan 22, 2013 at 9:37 AM, Derek Gaston <fri...@gm...> wrote: >> Have you guys tried to do a static build of libMesh on Linux and "make >> install" it somewhere and then try to build a libMesh based application >> against that? >> >> It is not working for us... because of missing tecplot symbols (like >> "tecini"). It looks like the executables in libMesh (like meshplot, etc.) >> have this on their link line (I'm building in a build directory underneath >> the libMesh directory): >> >> ../contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a >> >> However, that tecio.a file doesn't get installed into the prefix directory >> when you do "make install"... so there is no way for a libMesh based >> application to do something similar. >> >> I was kind of thinking that that tecio.a would have been linked into the >> actual libMesh static library... then there would be no problems... >> >> What should we do about this? > > Just to add a bit more detail to this: if you configure libmesh with > --enable-static --enable-shared, and make install then we get the > following when running 'nm' on the static library. > > nm lib/libmesh_opt.a | grep tecini > nm: tecio.a: File format not recognized > nm: lt1-tecio.a: File format not recognized > U tecini > > It seems to me that tecplot is unique in that it's a binary blob we > download from the Tecplot website? OK, I'll see what I can do about this. In the mean time, we've started distributing the tecio *source* as well, but that is not default yet because I haven't verified it with all compilers… But can you try instead $ ./configure <whatever else> --disable-tecplot --enable-tecio This will turn off the binary blob nonsense and compile the requisite symbols from source, getting them into the libMesh libraries proper. -Ben |
From: John P. <pet...@cf...> - 2013-01-22 19:10:51
|
On Tue, Jan 22, 2013 at 12:06 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On Jan 22, 2013, at 1:00 PM, John Peterson <pet...@cf...> wrote: > >> On Tue, Jan 22, 2013 at 9:37 AM, Derek Gaston <fri...@gm...> wrote: >>> Have you guys tried to do a static build of libMesh on Linux and "make >>> install" it somewhere and then try to build a libMesh based application >>> against that? >>> >>> It is not working for us... because of missing tecplot symbols (like >>> "tecini"). It looks like the executables in libMesh (like meshplot, etc.) >>> have this on their link line (I'm building in a build directory underneath >>> the libMesh directory): >>> >>> ../contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a >>> >>> However, that tecio.a file doesn't get installed into the prefix directory >>> when you do "make install"... so there is no way for a libMesh based >>> application to do something similar. >>> >>> I was kind of thinking that that tecio.a would have been linked into the >>> actual libMesh static library... then there would be no problems... >>> >>> What should we do about this? >> >> Just to add a bit more detail to this: if you configure libmesh with >> --enable-static --enable-shared, and make install then we get the >> following when running 'nm' on the static library. >> >> nm lib/libmesh_opt.a | grep tecini >> nm: tecio.a: File format not recognized >> nm: lt1-tecio.a: File format not recognized >> U tecini >> >> It seems to me that tecplot is unique in that it's a binary blob we >> download from the Tecplot website? > > OK, I'll see what I can do about this. > > In the mean time, we've started distributing the tecio *source* as well, but that is not default yet because I haven't verified it with all compilers… > > But can you try instead > > $ ./configure <whatever else> --disable-tecplot --enable-tecio > > This will turn off the binary blob nonsense and compile the requisite symbols from source, getting them into the libMesh libraries proper. Ah, we had tried --disable-tecio --enable-tecplot to no avail, but not this particular permutation. -- John |