On 15-09-2014 09:38, David Brodie wrote: > On 15/09/14 00:45, Christopher Gregory wrote: Thanks for your post, Christopher.
>> It may well be that if we do a similar thing with the other packages that >> they bundle along with the seds you have modified from arch that the >> warnings and hard coded links are removed. This seems difficult, because it is the Makefile that runs the builds, calling the configure scripts. >> My only real question is, should the changes you have made to the sqlite >> instrctions be optional? Yes. Reason is that I have not until now found any package or use for sqlite-tcl. Will discuss further below, replying to David. >> Prior to this the bundled pakages for tcl were not. I do not know if >> sqlite integration is considered mandatory for the functionality of >> tcl or >> not. Maybe Bruce could also have some input on this as I am only trying >> to come to grasps with it in my own mind. I think sqlite-tcl is not necessary at present state. I took it from Arch Linux, and they do not have any package depending on it. That is the reason I included it as optional, for someone who would know to need it for something. >> It is just a shame that this issue cropped up during the release >> cycle, as >> if it is decided to go ahead and split out the other bundled packages, it >> will require quite a bit more work on the tcl page. As I wrote above, think it is not easy. Better, I think it is not necessary. > > Fernando and Christopher: Thanks for your reply, David. > > From configure.in in ./pkgs/sqlite3.8.6/configure.in : > > #-------------------------------------------------------------------- > # The --with-system-sqlite causes the TCL bindings to SQLite to use > # the system shared library for SQLite rather than statically linking > # against its own private copy. This is dangerous and leads to > # undersirable dependences and is not recommended. > # Patchs from rmax. > #-------------------------------------------------------------------- > I don't understand the reason it is dangerous. Dependencies, I understand, that is why I've moved to sqlite. > I note that it also sets a slightly different set of flags for sqlite: > > Our flags: > > -DSQLITE_ENABLE_FTS3=1 \ > -DSQLITE_ENABLE_COLUMN_METADATA=1 \ > -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 \ > -DSQLITE_SECURE_DELETE=1\"" > > Tcl's flags: > > TEA_ADD_CFLAGS([-DSQLITE_ENABLE_FTS3=1]) > TEA_ADD_CFLAGS([-DSQLITE_3_SUFFIX_ONLY=1]) > TEA_ADD_CFLAGS([-DSQLITE_ENABLE_RTREE=1]) > TEA_ADD_CFLAGS([-DSQLITE_OMIT_DEPRECATED=1]) > > So for both these reasons, it would seem sensible to go with the > standard TCL build method, and compile and link sqlite statically. I don't understand why these are dangerous. I am facing three options: 1. Do your suggestion. 2. Test if we can change the flags when builf sqlite-tcl. 3. Remove it from sqlite, but also from tcl. Then include a comment that if desired for some reason, do not remove it, in order to build it during tcl build. Perhaps the third option would be the more secure one? Despite the points I don't understand, I will modify according what you write, but would like first to have your reply to this, please. Never thought I was introducing security problems. -- []s, Fernando -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
