my $0.02 below: Rick Altherr wrote: > > On Dec 23, 2008, at 7:50 PM, Duane Ellis wrote: > >> (b) Secondly, I have to add the "-Wl,-rpath,<DIRNAME>" if we choose >> to use the .SO file. >> Otherwise - well - openocd will not find the file when you run it. >> It will link - due to the "-L", but not *FIND* due to missing '- >> rpath' >> > > Personally a find the use of rpath a horrible direction for us to go. > Shared libraries encode their install location as part of the binary. > FTDI has built their library with a perfectly acceptable install > location encoded in the binary. A user should download the d2xx binary > and put the files in the proper installed locations. Hacking up our > configure scripts so users can be lazy and FTDI doesn't need to fix > their horribly packaged binary is just wrong. I realize we want to > appeal to the masses, but if a user is going to compile from source, > they should be able to move a few files around. > > If they really do want the d2xx .so in a different location, they need > to use the available tools to change the install path encoded in the > binary. This isn't terribly difficult, but most users probably don't > even know about it. > > Ultimately, I think FTDI has done a terrible job on their packaging and > we should send them an email illustrating the trouble it has wrought. > A single installer from FTDI or distributing as a .a would be > acceptable and resolve many of the issues. > > Please do not use -rpath as part of our configure system. It just > perpetuates bad practices. If we want to keep things simple for users, > recommend installing the FTDI library correctly or using libftdi. > >> Sure, in the end, the two "linux-tardir" and "win32-zipdir" are "do the >> same sort of thing" but the "linux-tardir" has to do quite a bit more. >> > > The question to ask yourself is "Is the distinction merely an > implementation detail?" In this case, it sounds like yes and therefore > is shouldn't be exposed to the user. The user doesn't really care if > they are on linux or win32 or if they are using a tardir or a zipdir. > They are using d2xx for their platform. We already know their > platform. We can determine if it is a normal install path, a tardir, > or a zipdir. So, why are we forcing them to tell us? > >> I am also quite concerned about cryptic messages when users do not >> ./configure correctly. In my view - the name "-win32-" or "-linux-" >> should sort of blink like neon lights in their face that the option only >> applies to a specific platform. (maybe i am overly hopeful somebody >> will actually figure that out it) >> > > The cryptic messages aren't going to go away and the configure options > aren't going to make it any clearer. The end result is either going to > be a link error when trying to find libd2xx.so or a run-time error > trying to find libd2xx.so. In both cases, it will be clear that it is > due to libd2xx.so not being found. To the user, if --with-d2xx was > passed and configure finished successfully, it isn't their fault. > Configure is intended to catch these types of problems early. We could: > - Check the provided path for known layouts (installed, tardir, zipdir) > - Check that the binary is for the correct platform (compile a simple > program) > - Check that the binary can be found at runtime (run the compiled > simple program) > > If any of those 3 fail during configure, we can spew an error then that > clearly indicates the problem. That removes the need for all the > different options to configure but still helps the user. > >> >> All of this is in contrast to "libftdi" - which - if the "--prefix" >> and/or "--exec-prefix" is non-standard... ie: like you and I do things - >> on linux I need to add "-rpath". >> Not sure about Win32. >> > > If libftdi is built with --prefix, its install path in the binary will > be correct and everything is fine. No rpath is necessary.
I'm not sure I still can completely follow all details here ;) But Rick's point of view sounds quite reasonable to me. Short conclusion from my (limited Linux only) point of view. I think for my use cases everything would already be fine * if for (open source) libftdi path given by --prefix is used by -I and -L, too. * if for (binary) ftd2xx path given by (existing) -with-ftd2xx is additonally used by -L Maybe we can start with these two fixes which are improvements already? And then go on with further changes (e.g. introducing --with-ftd2xx-win32-zipdir and --with-ftd2xx-linux-tardir ) later in a second step on top of this? Best regards Dirk _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
