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 thesame 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 onlyapplies 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.
-Duane. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
