This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
2011/5/25 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>: > Benoit, Bryan, All, > > On Wednesday 25 May 2011 20:53:52 BenoÃt THÃBAUDEAU wrote: >> > *This* is the real issue: the user not knowing something went bad, >> > and >> > discovering only at runtime. The solution to this issue is not to >> > build >> > libexpat, but to fail early, before even gdb gets compiled. >> > >> > I believe the real fix would be to fix that. >> >> I agree. >> >> How could we do that? >> Â- We could create a configure-like function in the scripts that would >> test for the presence of libexpat on the build system, and fail if not >> found. >> Â- We could add '--with-expat=yes' to the configure options of cross-gdb. >> In that way, the configure of cross-gdb would fail if libexpat is not >> present, but that failure could occur very late in the toolchain build. >> >> Should we force an error or leave a warning? > > The cross-gdb is pretty useless without it, so this has to be an error. > >> If --with-expat is not given >> or set to auto, there is already a warning issued by the configure of >> cross-gdb if libexpat is not found, but it is deeply hidden in the build >> log. >> >> Should libexpat be linked statically or dynamically? > > If the user asked for a static build, then do a full static build. > p;s/static/shared/ > >> A dynamic link would >> create a runtime dependency of cross-gdb on libexpat, which may be a >> problem when moving a built toolchain from one machine to another. > [--SNIP--] >> OK. The only issue I'd really like to see fixed here is the invisible >> dependency on libexpat. > > OK, we have a few options here: > > 1) Do the check just when it is needed, in do_debug_gdb_build(). >  This is the easiest, very lightweight, but inconvenient for the user >  as the build would have to be restarted. > > 2) Add a *_prepare function to the API, that gets call at the very beginning >  of the build, and does the necessary checks. Eg.: >   do_debug_gdb_prepare() { >    if [ ! "${libexpat_available}" ]; then >     ÂAaargh >    fi >   } > ÂDo it everywhere. > ÂAlso, have ./configure do the has_or_warn (as per Bryan's suggestion). > ÂThis is pretty nice, and lightweight. Rather easy to implement, I think. > > 3) Provide a way to set defaults to options from ./configure >  - check shared & static libexpat at ./configure time >  - create a .in fragment at ./configure time, eg.: >    config CONFIG_LIBEXPAT_SHARED >      default y >    # CONFIG_LIBEXPAT_STATIC not set: not found >  - add the same option definitons in the top-level config.in, >   and include the .in framgent to set values >  - where applicable, depend on these options to show/hide some options, >   such as static gdb > ÂThis is probably the most complete solution, but it is heavy-weight, maybe > Âun-maintanable long-term, error-prone as it needs sync btw config.in and > Â./configure, not easy to see where the defaults come from. > > I'd rather go for 2). Yann, I have other uses for 'has_or_warn' and setting $some-external-lib_available as well. For instance the problem that ANDY had with fedora packaging only shared with -devel packages, and needing to install a seperate -static package in the distribution would allow being able to toggle the availability of building a static toolchain (i.e. if libncurses5.a is not availble, don't allow static toolchains, but also warn during ./configure time.) So I would opt for this solution. I can provide the 'has_or_warn' code and an example with libncurses5.a if you want, but you or BenoÃt should be able to implement 'has_or_warn' as well ;) IOW... Eventually, I will need this functionality. > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | ÂYann E. MORIN Â| Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software ÂDesigner | \ / CAMPAIGN   | Â___        | > | +33 223 225 172 `------------.-------: ÂX ÂAGAINST   Â| Â\e/ ÂThere is no Â| > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL  Â|  v  conspiracy. Â| > '------------------------------^-------^------------------^--------------------' > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |