texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Linking against one of multiple installed libraries


From: Gubinelli Massimiliano
Subject: Re: [Texmacs-dev] Linking against one of multiple installed libraries
Date: Wed, 16 Oct 2013 13:40:18 +0200

Miguel,

On 16 Oct 2013, at 13:00, Miguel de Benito Delgado <address@hidden> wrote:

> Hi Massimiliano,
> 
> On 13 Oct, 2013, at 22:29, Massimiliano Gubinelli <address@hidden> wrote:
> 
>> By similar reasons in my opinion this should be the way things have to be 
>> done on Windows too.
> 
> Isn't this more or less the case? Albeit less elegantly, because the whole 
> development environment is a zip instead of scripts to download and compile 
> oneself...
> 

I do not follow the Windows development. I've taken the building scripts from 
the windows cross-compiler and I know that it is possible to bring up in this 
way an efficient cross-compiling environment. So there is no need for us to 
develop directly under windows. But of course the same strategy can be used to 
automate the creation of the zip file with all the updated libraries ready to 
use to develop directly under windows.


>> For Unix machines one should rely on system libraries so have two versions 
>> of the same library installed should be considered not the common thing. 
> 
> Well, now that we are lagging almost 3 years behind the release of Guile 2, 
> most users will have to install an older guile than the default one in the 
> distro… but this is off the point.
> 

Guile 2 is another problem but since scripts are not backward compatible with 
guile 1 I think most of the distros will retain the possibility of installing 
both. But I haven't checked. 

>> An option of course can also be to change all the configure to allow for 
>> exact paths of libraries but this will not solve the problem since you 
>> cannot ensure that a library which you call uses another copy of a library 
>> which you have linked in manually (for example think about guile and TeXmacs 
>> using different copies of gmp or libz, etc…).
> 
> Good point. I was actually thinking about changing the configure to do 
> precisely that so I'm happy you told me this before. d'oh!
> 

You can do it if you want, but I just mentioned that this will not avoid you to 
really take care of your developement environment (that is having fink, 
macports, user compiled libs all around is a bad bad idea....).


>> So I think the easiest way to have a complete control of libraries (on Mac 
>> and Windows) is to recompile them locally with strict control of the 
>> building environment.
> 
> Seems so, yes (but it'd still be nice to have a functioning configure script, 
> meaning one which actually uses the libraries it's told to. And any library 
> may be bundled within the .app package…).
> 

I agree, if you look at the configure-tm script I actually override all the 
configure variables to drive configure to link my libraries and not others. But 
to enforce this you must to be sure to have a clear library path. And keep in 
mind that shared libraries are searched at runtime so the problem persist. If 
you run the bundle there is no problem since the scripts hardcode the path to 
the shared libraries so other libraries will not interfere.

> Anyway, I'll try the tm-devel thing when I have time. You are quite right in 
> everything you say and I appreciate the effort put into the tm-devel stuff.
> 

I have several machines so this was the less painful way to set up a developing 
environment on a clean machine in less than one hour. Moreover it support the 
creation of 32 and 64 bit libraries separately so that in principle we can use 
this to build universal app bundle, but to arrive at this there are few more 
obstacles to be solved.

Best
Max



> Cheers,
> --
> Miguel.
> 
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/texmacs-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]