Compiling aims (problem with share directory)

Olivier_Colliot · Post by **Olivier_Colliot** » Tue Mar 15, 2005 3:26 am

Hi,

I have the following problem when compiling aims from source.
(I use the development version, the machine is a Mac running Darwin but I don't think the problem is related to this particular platform).

The compilation in itself works fine.
However, after this, AimsFileConvert complains about SHFJ_SHARED_PATH not being set (which, I guess, prevents it from using the plugins).
When I checked a previous successful compilation on another machine, I found that SHFJ_SHARED_PATH was defined as AIMSSOURCE/share (where AIMSSOURCE is the directory in which the source code has been put).
However, no such 'share' directory has been created during compilation this time (BTW, the directories AIMSSOURCE/bin, include or lib don't exist either).

Are these directories (including share) usually created by the 'build-config' process ? (and then maybe I used the wrong options)
Or should they be created manually after compilation ?

Many thanks,
Olivier

Post by **riviere** » Tue Mar 15, 2005 11:58 am

Hi Olivier,

The shared data are not organized the same way when you compile from sources or when you install a binary package:

On sources:
SHFJ_SHARED_PATH points to the root of the shared data project (shared-main)
AIMS_PATH points to <AIMSSOURCE>
ANATOMIST_PATH points to <ANATOMISTTOURCE>

On binary distribs:
SHFJ_SHARED_PATH points to the global share directory (let's call it <SHARE>), the 'shared' project data are under <SHARE>/shfj in the current packages
AIMS_PATH, and ANATOMIST_PATH (and SIGRAPH_PATH) are not mandatory, they are deduced from SHFJ_SHARED_PATH: anatomist and aims shared data are under <SHARE>/anatomist and <SHARE>/aims

If you want to conform to the binary distribution model, you can make a "share" directory containing symlinks to the shared parts of each project. If you have several versions of each project source, you can append the version number to the shared directories symlinks under <SHARE> to make all versions coexist without conflicts:
<SHARE>/aims-2.14
<SHARE>/aims-2.13
<SHARE>/anatomist-1.31
<SHARE>/anatomist-1.30
etc.
<SHARE>/shfj must point to the "shared-main" project

Then only the SHFJ_SHARED_PATH variable is needed (and points to <SHARE>).

As there is still no 'make install' procedure, all this has to be setup manually (unless you actually make a binary package using 'build-config --pack': see the help)

After all this is done, you can chech the paths by running a command with the '--info' option (which was '--aimsinfo' on the stable versions), for instance:

Code: Select all

AimsFileInfo --info

or:

Code: Select all

anatomist --info

(anatomist will provide more information because it uses more libraries)

Does it help ?
Denis

Olivier_Colliot · Post by **Olivier_Colliot** » Tue Mar 15, 2005 5:06 pm

Thanks a lot Denis. It helps.

I decided to conform to the binary distrib and it seems to work, except that it still does not find the minc plugin (even though it finds the jpeg plugin).

I have the impression that it is related to a .so vs .dylib issue.

It seems that I have a .dylib library for each plugin, except for the jpeg plugin for which I have also a .so. As the jpeg plugin is the only one that is found by AimsFileInfo, I am wondering if I should also have a .so version of the other libs.

Here is the content of the lib directory
[-/Applications/brainvisaSourceMinc]ll aimsdata-main-darwin-debug/lib/
l28 14 Mar 17:36 libaimsdata-debug.dylib@ -> libaimsdata-debug.dylib.2.14
44922860 14 Mar 17:36 libaimsdata-debug.dylib.2.14*
28 14 Mar 17:37 libaimsjpeg-debug.dylib@ -> libaimsjpeg-debug.dylib.2.14
1679332 14 Mar 17:37 libaimsjpeg-debug.dylib.2.14*
25 14 Mar 17:45 libaimsjpeg-debug.so@ -> libaimsjpeg-debug.so.2.14
54648 14 Mar 17:45 libaimsjpeg-debug.so.2.14*
28 14 Mar 17:45 libaimsminc-debug.dylib@ -> libaimsminc-debug.dylib.2.14
4044612 14 Mar 17:45 libaimsminc-debug.dylib.2.14*
28 14 Mar 17:37 libaimstiff-debug.dylib@ -> libaimstiff-debug.dylib.2.14
1604656 14 Mar 17:37 libaimstiff-debug.dylib.2.14*

Or maybe I should change the content of share/aims-2.14/plugins/aimsdata.plugins (replace .so with .dylib ??)

BTW, I am a bit surprised by the size of some .dylib files (45MB for libaimsdata is a lot, even for a debug version)

Post by **riviere** » Tue Mar 15, 2005 9:06 pm

Hi Olivier,

The build seems to be incomplete: you should have both the .so and the .dylib libraries.
On Mac there are 2 distinct types of dynamic libraries that are incompatible whereas on all other systems they are the same: the .dylib are "regular" dynamic libraries that programs link against at compile-time, and the .so are "bundles" that can be loaded on demand at run-time, typically optional plugins must be bundles.
So the Minc plugin has to be a bundle. To reduce the differences with other systems, I decided to make both dylibs and bundles for Aims plugins on Mac: the .dylib is a regular library which can be used directly by programs, and the .so plugin is linked against this library (and almost empty otherwise) and can be dynamically loaded by the plugins loader. A .dylib cannot be used directly as a plugin. Am I clear...?

Are you sure you didn't have any error when you compiled aims ? It's strange it hasn't compiled the bundle...

The latest development sources I put on he ftp server today have a link problem on Mac, I'll look at it and try to fix it quickly so you can try a recent version soon. I'll tell you when it's fixed.

The size of the library in debug mode is just normal: debug versions are really huge (and are so long to link that I barely use them nowadays).

Denis

Post by **riviere** » Tue Mar 15, 2005 9:29 pm

OK the new sources are fixed. You can download again cartobase-main.tar.gz and try it.
There may be problems later to compile other libraries, I haven't checked everything yet (I'm compiling on a venerable Mac laptop and it generally needs the whole night to finish).

Denis

Olivier_Colliot · Post by **Olivier_Colliot** » Wed Mar 16, 2005 12:29 am

Concerning the cartobase package:
Thanks a lot uploading the new version.
The link that previously failed now succeeds.

However, there is another problem further in the compilation, in cartodata:

Code: Select all

c++ -c -g -Wall -W -D_REENTRANT -dynamic -DCARTO_DEBUGMODE=\"debug\" -DCARTO_DEBUG=1 -I/Applications/SHFJ-source-minc/cartodata-main-darwin-debug/include -I/Applications/SHFJ-source-minc/cartobase-main-darwin-debug/include -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/include/libxml2 -o io/gisreader.o /Applications/SHFJ-source-minc/cartodata-main/src/library/io/gisreader.cc
/Applications/SHFJ-source-minc/cartodata-main/src/library/io/gisreader.cc: In
   function `bool <unnamed>::initMe()':
/Applications/SHFJ-source-minc/cartodata-main/src/library/io/gisreader.cc:27: error: cannot
   allocate an object of type `carto::GisReader<int16_t>'
/Applications/SHFJ-source-minc/cartodata-main/src/library/io/gisreader.cc:27: error:
    because the following virtual functions are abstract:
/Applications/SHFJ-source-minc/cartobase-main-darwin-debug/include/cartobase/wip/io/formatreader.h:120: error:
   void carto::FormatReader<T>::read(T&, carto::Object, const
   carto::AllocatorContext&, carto::Object) [with T = carto::Volume<int16_t>]
make[3]: *** [io/gisreader.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [sub_library] Error 2
make: *** [all] Error 2
Traceback (most recent call last):
  File "/Applications/SHFJ-source-minc/build-config", line 3993, in ?
    instance.buildWithDependencies( instances )
  File "/Applications/SHFJ-source-minc/build-config", line 897, in buildWithDependencies
    self.build( instances )
  File "/Applications/SHFJ-source-minc/build-config", line 1648, in build
    raise OSError( 'Building of ' + self.name() + ' failed' )
OSError: Building of cartodata-3.0 failed

As you told me that you are currently testing, maybe you had the same problem. So I will wait for the new upload.

Olivier

Olivier_Colliot · Post by **Olivier_Colliot** » Wed Mar 16, 2005 12:50 am

Concerning the missing libaimsminc.so (with the previous development version, not the one you uploaded yesterday)
I think I found the problem.
In this previous version, there was no directory bundle_aimsminc under aimsdata/src

So I just copied this directory from the new version of the package and it works.

Post by **riviere** » Wed Mar 16, 2005 10:12 am

Oops, sorry, by the meantime there had been other changes in the libraries that implied modifs in cartodata too and I didn't upload it.
I have uploaded the sources again. Download cartobase, cartodata (and aimsdata to be sure), this time I hope it will work...

The older version you tried yesterday had perhaps not been setup for Mac at all, the bundles have been made later (it was nearly one year old)...

Sorry
Denis

Olivier_Colliot · Post by **Olivier_Colliot** » Thu Mar 17, 2005 8:45 pm

I downloaded the new source of cartodata.

Everything now seems to work fine.

Thanks a lot !
Olivier