Extension Versions

[Pats]

I hope while updating an ext by the ext-maker or others , the older one will be available as it is in the repo, since a ( C/C++/OpenJDK) developer like me - heavily depend on that perticular version of the older extension ( for static / shared liking of the concerned app ) - other-wise ( not always ) , the app developer will too have to alter  his code frequently.
Ideally, ext for 2.x series should be continued for MC/TC 2.x series ( same for 3.x series ) etc. - off-cource , unless and untill some major change in the source code of original issuing creator of that Linux app has not surfaced ! But that is upto the urgency of the ext maker .

~ Pats



#edited to remove the sticky by JW#

[Jason W]

For most extensions, especially libraries, we are only able to have one version at a time.  It is not feasible to keep old versions of an extension once a new one has taken it's place.

[Pats]

( For most extensions, especially libraries, we are only able to have one version at a time.  It is not feasible to keep old versions of an extension once a new one has taken it's place. )

Hmm ! Local stocking of the relevent ext version is then must for me - I think !
Thnks !
In GCC 4.2.2 , I encountered the input/output error while compling an app. I revert back to GCC3.x.x from the ../2/x/tce - which works like a charm for me. Since I am from the w2k C/C++/VC world , I left that problem then and there only.
What is this input/output error ? Some flag exporting saga ?

~ Pats

[Jason W]

I split this topic into it's own since it is about extension versions.  I messed up and split into two, will fix it

[bmarkus]

I hope while updating an ext by the ext-maker or others , the older one will be available as it is in the repo, since a ( C/C++/OpenJDK) developer like me - heavily depend on that perticular version of the older extension

Sorry to say, but if your application strictly depends on a particular version it shows me a poorly designed application. In general in a LINUX environment you can relatively freely change, update a certain library, application, etc. in the system without affecting others.

I'm running different LINUX servers in the last 10 years, including MANDRAKE, MANDRIVA, SuSE and CentOS. In their repo there is only one (the latest) version available. Updates are happening on the fly without disturbing the system normal operation. Even the 'big guys' do not keep older versions avaiilable.

[Jason W]

Pats- 
I made a mistake trying to split this into it's own topic, and a post was lost.  Sorry for the mistake, I did not intentionally delete your post.   

[Jason W]

Oh, and gcc 3.x is less strict than gcc 4.x.   Sometimes compiling old apps on 4.x will give errors.  If it is a popular old app, there likely is a gcc-4.x patch for it to let it build.  Arch, Crux, and Slackware repos will likely have a 4.x patch for older apps that are still around that need them.

[Pats]

@bmarkus:
( Sorry to say, but if your application strictly depends on a particular version it shows me a poorly designed application. )

Very true, sir !
But I still do not know how to code with a depricated and/or removed class / function / feature - if that perticular langusage stopped supporting the feature in its new release .
With the depricated item, we may work-around by using  -depricated flag.
But what abt the removed functions / classes ?

In Java2 , distpatch() member of ActiveEvent class of java.awt.peer package from Java 1.1 was removed.
So is the case of checkAwtEventQueueAccess() , checkMemberAccess() , checkPropertyAccess()  etc many members were removed from class RMISecurityManager of package java.rmi.
So is the case of java.security package of java 1.1

And imagining to alter 22K lines or 40K lines of code in diff 8 modules in the concerned application developed in Java 1.1 and its subsequesnt cross references to other exported classes of C++ wrappers etc  - to port it to Java2 - is not a minor job for a poor programmer like me !

Off-cource, all I am talking abt above is refering to Win platform -as most of my time has gone developing on W2k, XP etc. Another thing , many clients are still reluctant to upgrade to XP - leave aside the Vista/W7 after experiencing the Vista fiasco !

Since C++ and Java classes undergo continuous revisions and modifications - the list of depricated / removed features from most of the languages continuously changes - even in Java2 !


( In general in a LINUX environment you can relatively freely change, update a certain library, application, etc. in the system without affecting others.

I'm running different LINUX servers in the last 10 years, including MANDRAKE, MANDRIVA, SuSE and CentOS. In their repo there is only one (the latest) version available. Updates are happening on the fly without disturbing the system normal operation. Even the 'big guys' do not keep older versions avaiilable. )

Since I am trying my hand in Linux Programming very lately ( which I have already disclosed on this forum else-where ), I hope you can guide me the work-around for the above situations with your good experience - like what to do to get around the removed class / function / a feature.
Should we supply the old library files with the application / will the app work with the new C++ / Java library - even if the feature is completely removed from the new release of that library ?

Kindly guide !


@Jason:
( I made a mistake trying to split this into it's own topic, and a post was lost.  Sorry for the mistake, I did not intentionally delete your post. )

Its OK ! I know nobody will do such thing deliberately - unless some forum rules are violated !


( Oh, and gcc 3.x is less strict than gcc 4.x.   Sometimes compiling old apps on 4.x will give errors.  If it is a popular old app, there likely is a gcc-4.x patch for it to let it build.  Arch, Crux, and Slackware repos will likely have a 4.x patch for older apps that are still around that need them. )

Thnks ! But presently ( in Linux ) - I am not porting / modifying any app developed by others. I just want  some of my simple apps ( from Win ) to be re-structured as per the OS-requirement of Linux. So I was trying to compile some converted apps in GCC4.2.2 - and this input/output error stalled my progess. Acutually - :

cc -o app_name app.c

was refering to cc1 in the bin dire in GCC tree. But cc1 was reluctant to proceed further.
I had installed all the files - mentioned in compiletc.tcz mata ext from /2.x/tcz repo !
The same app runs ok when I use GCC3.x from /2.x/tce repo . I am clueless !

As per the GCC4.4.x info file guide lines - I avoided suing 4.4 - since my app is not that big and feature rich !

~ Pats

[curaga]

If an app truly depends on a certain version of a lib, I would link the lib in statically.

ie. instead of "-lpng" use "/path/to/libpng.a".

[Pats]

Thnks curaga !

I have some in-line ASM functions in my C sources and have some separate .asm files containing 80x86 instructions.
Can you kindly give the compile/link flags for both the above situations saparately (GCC3.x.x) ?

TIA !

~ Pats

[curaga]

Sorry, I don't know much about assembly. My understanding is that inline one should work with a normal gcc call, but no idea about separate files.

[^thehatsrule^]

The rest of the compiling should not be any different if you are manually setting them.

An easy way to get around this is to provide the specific dynamic libs with your package, if it truly depends on those specific set of libs.  If modifying things like LD_LIBRARY_PATH is too dirty for your tastes, there's always the dlopen way too.

For things in the repository that may have ABI changes or the like, different versions of the software are kept there.  You can see this just by browsing the current list.

[Pats]

<quote>
An easy way to get around this is to provide the specific dynamic libs with your package, if it truly depends on those specific set of libs.  If modifying things like LD_LIBRARY_PATH is too dirty for your tastes, there's always the dlopen way too.
</quote>

Thnks, I think I can do it both way: statically linked app or providing dynamic (and/or shared) lib, which can be used by diff apps !
Previously I used to : 'make shared' option while building shared or dynamic lib, but then I had to set  LD_LIBRARY_PATH , which obviously was dirty method, as you said. Also there was some strart-up delay with shared lib ( the lib was having 72 routines ) ! And moreover , it was i386
cpu !

Sometime back I was using static archives , but it was overhead for multiple apps. Though shared libs can be upgraded as per needs, but those were messing up some of our  projects !
If the installations of libs is not in /lib /user/lib, then again:

 -Wl, -rpath

will pose a problem !

But lastly, dlopen ("mylib.so", RTLD_LAZY)  along with –ldl , has somewhat solved the problem, although dlopen() is best suited for dynamic plug-ins, as the experts say !

<quote>
For things in the repository that may have ABI changes or the like, different versions of the software are kept there.  You can see this just by browsing the current list.
</quote>

Thats the whole point, which was in my mind while replying to bmarkus post !

But I think, Jason has shown me the correct way in his * Quick hack to convert Debian packages. * posting, by which I can create/use  any required package in TC from the old archieves of RPMs and debs !

Thnks to all of you !

~ Pats