Interesting. I hadn't thought about these issues. I don't really know much about getting things to link to the proper libraries that are installed on the system, so I'll follow your recommendation (whichever of the 2 you choose).
As I said before I am just now reading the GNU Autofconf, Automake, and LibTool book, so I am learning a lot about linking. I've also just started the VNIX project, a library to aid in porting from VMS to *NIX systems, which should give me plenty of experience with linking: http://savannah.gnu.org/projects/vnix/ I'll be importing my local tree into that this weekend, hopefully. Harold > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson > Sent: Friday, May 10, 2002 7:02 PM > To: Harold L Hunt > Cc: [EMAIL PROTECTED] > Subject: Re: lesstif mwm bug > > > Harold L Hunt wrote: > > > > I don't care what the prefix is, just so long as I can blame > someone else :) > > I believe the main problem with using /usr/X11R6 as the prefix is > > that /usr/X11R6/bin is not in most users PATH, nor is > /usr/X11R6/lib in their > > lib search path, nor is /usr/X11R6/include in their includes > search paths... > > etc. It may end up being a lot of trouble to use anything > other than /usr as > > the prefix. > > > But any time you're compiling an app that needs X, you always need to > supply (or have configure figure out) where X is. --x-includes, > --x-libraries, etc (or configure uses the default location for X, and > sticks that into CFLAGS/LDFLAGS for you...). And, if I need to link > against a lib that uses X, then I by necessity must also link against X > itself. So, I'll get /usr/X11R6/lib and /usr/X11R6/include. > > Now, I can see a problem for the search ORDER: if I'm linking an X-app, > then I want to use the (say) gtk+ headers from the X-gtk build, not the > native-windowing-but-cygwin-runtime-gtk (if there ever is such a beast). > So, I want to make sure that /usr/X11R6/include/gtk+1.2/ is searched > BEFORE /usr/include/gtk+1.2/. But, -I and -L directories are always > searched before the "default" /usr/[include|lib] -- so that's okay. > > But what about 'foo-config' scripts? I'd want to run > '/usr/X11R6/bin/gtk-config --cflags', not '/usr/bin/gtk-config --cflags' > during configure. So, I need to make sure that /usr/X11R6/bin/ comes > BEFORE /usr/bin in my PATH, when I begin to build a X- linked app. > > (This harkens back to Earnie's "moode" supposition...) > > Similarly, what of 'pkgconfig(gtk+, ver >= 1.2)' -- pkgconfig will use > the 'gtk+.pc' file in its "home" directory -- /usr/lib/pkgconfig/. But, > that's where the native-windowing-but-cygwin-runtime-gtk will put its > .pc file. So, I also need to either: > 1) I somehow indicate to /usr/bin/pkgconfig.exe that it should look > in /usr/X11R6/lib/pkgconfig/ BEFORE /usr/lib/pkgconfig (but it still > needs to look in both, to make sure that libs which do not depend on > windowing-modality get picked up) > 2) I need a second pkgconfig.exe in /usr/X11R6/bin/ that is > configured to behave as in (1); I insure that THIS one is called when > building X apps, because I set the PATH as described earlier...that > whole "moode" thing. > Both (1) and (2) require some hacks to pkgconfig; I'm willing > to do that. > > --Chuck >
