~vcs-imports/libtool/master

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Peter O'Gorman
  • Author(s): Cristophe Jarry
  • Date: 2011-09-25 22:49:43 UTC
  • Revision ID: git-v1:920da81be698974faa50bd36a60248e2c18c4fd5
Avoid mentioning "Linux", use "GNU/Linux", if appropriate.

        * TODO: Don't use bare "Linux".
        * doc/libtool.texi: ditto.
        * doc/notes.texi: ditto.
        * libltdl/README: ditto.
        * libltdl/m4/libtool.m4: ditto.

Show diffs side-by-side

added added

removed removed

Lines of Context:
58
58
 
59
59
* Audit file listing in libtool.m4.
60
60
 
61
 
* Fix deplibs_check_method=pass_all (which is wrong!) on linux.
 
61
* Fix deplibs_check_method=pass_all (which is wrong!) on GNU/Linux.
62
62
 
63
63
* Fix -dlopen "self" on AIX.  Reported by Gary Kumfert <kumfert@llnl.gov>.
64
64
 
290
290
    and central_unixish_to_mingw would still do all the work (with its guts
291
291
    customized based on $build).
292
292
 
293
 
    For more reasonable cross environments (e.g. linux->some_embedded) I think
294
 
    you could probably work out a general M+N scheme, since most embedded $hosts
295
 
    aren't as strange as the win32 variants -- even VxWorks and INTEGRITY have
296
 
    basic, unix-like file systems (although INTEGRITY does have multiple roots).
297
 
    Aggressive use of the m4 function_replace machinery WOULD be appropriate for
298
 
    /these/ conversion functions.  OTOH...(a) you can't run the $host apps on
299
 
    $build anyway, in these embedded situations. At best you'd use $TARGETSHELL
300
 
    and "run" them via a remote connection, and (b) they don't use the C
301
 
    wrapper!
 
293
    For more reasonable cross environments (e.g. linux-gnu->some_embedded) I
 
294
    think you could probably work out a general M+N scheme, since most embedded
 
295
    $hosts aren't as strange as the win32 variants -- even VxWorks and INTEGRITY
 
296
    have basic, unix-like file systems (although INTEGRITY does have multiple
 
297
    roots). Aggressive use of the m4 function_replace machinery WOULD be
 
298
    appropriate for /these/ conversion functions.  OTOH...(a) you can't run the
 
299
    $host apps on $build anyway, in these embedded situations. At best you'd use
 
300
    $TARGETSHELL and "run" them via a remote connection, and (b) they don't use
 
301
    the C wrapper!
302
302
 
303
303
    So...I don't think it makes much difference *right now* in the amount of
304
304
    code required, or the number of functions implemented. At some point in the