doyle@b11.ingr.com (Doyle Davidson) (10/02/90)
YAGNBD: "Yet Another Good News/Bad News" story:
I just installed fixes 15-17 onto our system (Intergraph CLIX - System V
with BSD extensions) and lo and behold, the new shread libraries that
I just built core dump when run against older (MIT fix level 14)
clients. A little examination reveals some changes in various data
structures reveals that things like "XtAppStruct" have changed.
What I am wondering is do other vendor's shared libraries have
version compatibility problems when public data structures change
or is it just us poor System V (Intergraph's implementation??) souls?
The reason this is really important is that we must now support (at least)
two versions of the shared target (runtime: patches 1-14 and 1-17)
and wean all of our internal and third party application groups off of the
older shared library which seems to defeat one of the major advantages of
shared libraries (code updates with re-linking).
Any comments/"nyah-nyah, my way is better :-P"/why aren't you doing so-and-so?
Doyle (Is this is old me or the new me?) Davidson
------------------------------------------------------------------
Doyle C. Davidson |
Intergraph Corp. | These comments are...
Workstation Graphics Standards |
1 Madison Industrial Park |
Huntsville, AL 35806 |
(205) 730-2000 | X-clusively my own.
|
..!uunet!ingr!doyle |
------------------------------------------------------------------jordan@morgan.COM (Jordan Hayes) (10/02/90)
A little examination reveals some changes in various data structures reveals that things like "XtAppStruct" have changed. If this is true, the Sun shared libraries would fail too. I just applied fixes 15-17 and rebuilt libXt, and tried to run my older applications pointed at the new shared libraries and didn't get a core dump, so perhaps the changes are only internal. You need to (in the Sun model) bump the major revision number when you change the interface to the shared libraries. This also requires a re-link step. Enhancement request: I'd like to see the Sun shared library support go into sun.cf, and i'd like to see the minor revision number get bumped when a library changes so that when I "make install" I don't clobber the (presently in-use) library that's already there, and I can remove the old version, say, a week later after everyone has begun using the new version. Further, I hope that if you change the interfaces to these libraries that you would bump the major revision number ... Thanks. /jordan
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/02/90)
I'd like to see the Sun shared library support go into sun.cf,
I don't know what this means.
and i'd
like to see the minor revision number get bumped when a library changes
The Sun shared library mechanism seems magic enough and fragile enough,
especially in the area of numbers, that we hesitate to make any changes
here. Perhaps you'd like to make such changes locally and try them for
a few months (gratuitously installing new versions from time to time)
to see if it really works?
Further, I hope that if you change the interfaces to these libraries
that you would bump the major revision number ...
I would hope we don't make incompatible changes like that.gdmr@cs.edinburgh.ac.uk (George Ross) (10/03/90)
In article <9010021331.AA22861@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > The Sun shared library mechanism seems magic enough and fragile enough, > especially in the area of numbers, that we hesitate to make any changes > here. Perhaps you'd like to make such changes locally and try them for > a few months (gratuitously installing new versions from time to time) > to see if it really works? When we switched to X11R4 we found we couldn't use the distribution's idea of revision level. We already had shared libraries for R3, with a major number of 11 and a minor number of 3. We wanted to run in parallel for a while so we invented a new major number of 1104 for the R4 libraries, with the minor number being the patchlevel of the library. We started out using LD_LIBRARY_PATH to switch between versions, and when we went over completely to R4 we just moved all the libraries into the right place. We still have the R3 libraries for those applications that still need them, and we usually keep around one or two previous versions of the R4 libraries for those clients and applications that haven't been restarted since the new versions were put up. Here's what we currently have: [cs1mgr]gdmr: ls /usr/local/lib/libX* /usr/local/lib/libX.a /usr/local/lib/libXinput.a /usr/local/lib/libX10.a /usr/local/lib/libXmu.a /usr/local/lib/libX11.a /usr/local/lib/libXmu.sa.1104.7 /usr/local/lib/libX11.so.11.3 /usr/local/lib/libXmu.so.11.3 /usr/local/lib/libX11.so.1104.7 /usr/local/lib/libXmu.so.1104.7 /usr/local/lib/libXau.a /usr/local/lib/libXport.so.1.1 /usr/local/lib/libXaw.a /usr/local/lib/libXt.a /usr/local/lib/libXaw.so.11.3 /usr/local/lib/libXt.sa.1104.14 /usr/local/lib/libXaw.so.1104.11 /usr/local/lib/libXt.sa.1104.17 /usr/local/lib/libXcu.a /usr/local/lib/libXt.so.11.3 /usr/local/lib/libXdmcp.a /usr/local/lib/libXt.so.1104.14 /usr/local/lib/libXext.a /usr/local/lib/libXt.so.1104.17 /usr/local/lib/libXim.a /usr/local/lib/libXw.a Note two versions of libXt. We've had no problems with this scheme at all. ------------------------------------------------------------------------ George D M Ross, Department of Computer Science, University of Edinburgh 031-667 1081 x2730 gdmr@uk.ac.ed.cs (or cs.ed.ac.uk if you prefer)
doyle@b11.ingr.com (Doyle Davidson) (10/03/90)
In article <9010021304.AA01874@Morgan.COM>, jordan@morgan.COM (Jordan Hayes) writes: > > A little examination reveals some changes in various data > structures reveals that things like "XtAppStruct" have > changed. > > If this is true, the Sun shared libraries would fail too. It did change but that really had nothing to do with my problem. I should not have used this example. Sorry. I would like to know if anyone running under AT&T V.3 shared library mechanism has applied patches 15-17, rebuilt their Xt shared library and have everything still work. If so, I would like to know what you have done different from me. Thanks, Doyle ------------------------------------------------------------------ Doyle C. Davidson | Intergraph Corp. | These comments are... Workstation Graphics Standards | 1 Madison Industrial Park | Huntsville, AL 35806 | (205) 730-2000 | X-clusively my own. | ..!uunet!ingr!doyle | ------------------------------------------------------------------
jordan@morgan.COM (Jordan Hayes) (10/04/90)
> I'd like to see the Sun shared library support go into sun.cf,
I don't know what this means.
I'd like SharedLibraryObjectRule() to be defined in sun.cf, and for
Imake.rules to say something like
#ifndef SharedLibraryObjectRule
#define SharedLibraryObjectRule()
#endif
Then for the different types of shared libraries out there, you'd need
to define a rule for SharedLibraryObjectRule in your .cf file ... Like,
how have people hacked in shared library support for SYS V.2 machines,
like the Intergraph that was mentioned recently or (more to my neck of
the woods), A/UX 2.0?
Seems kind of weird for HasSunOSSharedLibraries to appear in a bunch of
random files. I thought the achitecture-independent portion of the
rules should be in the <vendor>.cf file?
Perhaps you'd like to make such changes locally and try them
for a few months (gratuitously installing new versions from
time to time) to see if it really works?
I have been, actually, for Motif 1.0 (and more recently 1.1), and i've
found that the biggest change is to the *LibraryObjectRule() stuff.
Are there any other machines (other than AIX -- grrr) where "cc -o"
doesn't work? Near as I can tell, that's a v7-ism (where's Henry when
you need him?), and it seems like a reasonable thing to expect.
Without this support, you need to do that
$(CC) ...
$(MV) $@ shared/$@
hack. What this really means is that if you have libraries built and
you decide to add one of {shared,debugged,profiled} to your
Project.tmpl, you have to rebuild everything -- actually, you have to
do a "make clean" before you re-make, because there's no target for
shared/%.o:
anywhere.
For instance, here's my ProfiledLibraryObject and ProfiledLibraryTarget
----- cut here
#ifndef NewProfiledLibraryObjectRule
#define NewProfiledLibraryObjectRule() @@\
all:: @@\
-@if [ ! -d profiled ]; then mkdir profiled; else exit 0; fi @@\
@@\
profiled/%.o: %.c @@\
$(RM) $@ @@\
$(CC) -pg -o $@ -c $(CFLAGS) $< @@\
@@\
clean:: @@\
-@if [ -d profiled ]; then echo " $(RM) profiled/?*.o"; \ @@\
$(RM) profiled/?*.o; else exit 0; fi @@\
#endif /* NewProfiledLibraryObjectRule */
/*
* NewProfiledLibraryTarget - generate rules to create a profiled library.
*/
#ifndef NewProfiledLibraryTarget
#define NewProfiledLibraryTarget(libname,objlist) @@\
AllTarget(lib/**/libname/**/_p.a) @@\
@@\
Profiled/**/libname/**/Objs = $(objlist:%=profiled/%) @@\
@@\
lib/**/libname/**/_p.a: $(Profiled/**/libname/**/Objs) @@\
$(RM) $@ @@\
cd profiled; $(AR) ../$@ $(objlist) @@\
$(RANLIB) $@ @@\
@@\
clean:: @@\
$(RM) lib/**/libname/**/_p.a
#endif /* NewProfiledLibraryTarget */
----- cut here
Given the following Imakefile,
----- cut here
SRCS = foo.c bar.c mumble.c
OBJS = $(SRCS:%.c=%.o)
NewProfiledLibraryObjectRule()
NewProfiledLibraryTarget(libXm,OBJS)
----- cut here
gives you (approximately)
----- cut here
all::
-@if [ ! -d profiled ]; then mkdir profiled; else exit 0; fi
profiled/%.o: %.c
$(RM) $@
$(CC) -pg -o $@ -c $(CFLAGS) $<
clean::
-@if [ -d profiled ]; then echo " $(RM) profiled/?*.o"; \
$(RM) profiled/?*.o; else exit 0; fi
all:: libXm_p.a
ProfiledXmObjs = $(OBJS:%=profiled/%)
libXm_p.a: $(ProfiledXmObjs)
$(RM) $@
cd profiled; $(AR) ../$@ $(OBJS)
$(RANLIB) $@
clean::
$(RM) libXm_p.a
----- cut here
As for minor version numbers, we have the Motif shared libraries using
the following system:
libXm.so.${OSFMajor}.${OSFMinor}${OSFMinor2}${LocalLevel}
e.g., the first shot from OSF Motif 1.1 becomes
libXm.so.1.100
so I have 10 shots at bug-fixes locally before 1.1.1 comes out (which
would become libXm.so.110). Since we have production code here running
with these shared libraries, you can't just "make install" over the old
libraries, so we bump ${LocalLevel} and 3-5 days later remove the
${LocalLevel} - 1 version ... this way new instances of programs get
the new library, and old ones just die off eventually.
There's more, of course, but I'd better take it off line ...
/jordancoolidge@cs.uiuc.edu (John Coolidge) (10/05/90)
jordan@morgan.COM (Jordan Hayes) writes: >Then for the different types of shared libraries out there, you'd need >to define a rule for SharedLibraryObjectRule in your .cf file ... Like, >how have people hacked in shared library support for SYS V.2 machines, >like the Intergraph that was mentioned recently or (more to my neck of >the woods), A/UX 2.0? This is pretty much what I did for my shared library implementation for A/UX 2.0 (and, yes, the source patches should be out soon). The A/UX shared library stuff is specified in macII.cf (reusing as many of the names, and hence the Imakefile code, as possible from the Sun code). There are some necessary changes to the Imakefiles, a few of which are _very_ ugly :-(. >Seems kind of weird for HasSunOSSharedLibraries to appear in a bunch of >random files. I thought the achitecture-independent portion of the >rules should be in the <vendor>.cf file? It should be. Things get confusing, though, when you add new target files for a particular shared library architecture. For instance, in the A/UX 2.0 stuff I've spilt out a bunch of static data in Xt and Xaw and put it in _S<file>.o files. This adds a bunch of targets with wierd rules, and it doesn't affect all the files in either library so I can't just add the extra compile to the standard directives... Of course, some of my stuff is almost certainly unnecessarily ugly... but it works (that is, I can type 'make Makefile;make' and the right stuff appears). --John