Nope, I've just tried and it works perfectly. lynx : 2.8.6rel.4 (r23346) macports : trunk (up-to-date) os : macosx 10.4.9 arch : ppc (32bit) Regards, Elias On Mar 29, 2007, at 6:55 PM, Daniel J. Luke wrote:

Does anyone else have build problems with the lynx port?

(I haven't done any looking into it yet ...):

. -I../src -I../WWW/Library/Implementation -O2 -c ./LYCharSets.c ./LYCharSets.c: In function 'HTMLGetEntityUCValue': ./LYCharSets.c:878: error: 'unicode_entities' undeclared (first use in this function) ./LYCharSets.c:878: error: (Each undeclared identifier is reported only once ./LYCharSets.c:878: error: for each function it appears in.) make[1]: *** [LYCharSets.o] Error 1 make: *** [all] Error 2

-- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

On Mar 29, 2007, at 13:04, Daniel J. Luke wrote:

On Mar 29, 2007, at 1:30 PM, Elias Pipping wrote:

...

On Mar 29, 2007, at 6:55 PM, Daniel J. Luke wrote:

...

Does anyone else have build problems with the lynx port?

(I haven't done any looking into it yet ...):

. -I../src -I../WWW/Library/Implementation -O2 -c ./LYCharSets.c ./LYCharSets.c: In function 'HTMLGetEntityUCValue': ./LYCharSets.c:878: error: 'unicode_entities' undeclared (first use in this function) ./LYCharSets.c:878: error: (Each undeclared identifier is reported only once ./LYCharSets.c:878: error: for each function it appears in.) make[1]: *** [LYCharSets.o] Error 1 make: *** [all] Error 2

Nope, I've just tried and it works perfectly.

Looks like the problem is gd2 (which installes /opt/local/include/ entities.h, as LYCharSets.c needs unicode_entities defined as in src/chartrans/entities.h).

I can confirm that... without gd2, lynx installs fine. With gd2 installed, I see the errors above. So how to we fix this?

On Mar 30, 2007, at 3:50 AM, Boey Maun Suang wrote:

I think the problem is that, at least under MacPorts 1.4, -I/opt/ local/include appears before -I./chrtrans (the location of the entities.h that lynx actually wants) in the gcc command that causes the failure:

I think lynx is adding that -I early because of the --with-ssl option. The macports change to always add -I and -L options isn't in a release version (yet). We should probably think about it some more and do lots of testing to make sure that it won't break many (any?) ports.

If -I/opt/local/include is being inserted there by the MacPorts code (I don't yet understand it well enough to tell), I reckon that this would be something we'd want to fix. In any case, I found that replacing line 873 in src/LYCharSets.c:

#include <entities.h>

with

#include "chrtrans/entities.h"

yep, I was going to suggest that we patch lynx this way to fix it. I can generate a patch and check it in (since it's a nomaintainer port) unless someone else wants to.

works at the moment. As I'm not sure whether or not this is more a problem with the MacPorts code, though, I don't feel comfortable filing it as a bugfix. Any feedback would be appreciated.

-- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

On Mar 30, 2007, at 3:10 PM, Daniel J. Luke wrote:

The macports change to always add -I and -L options isn't in a release version (yet). We should probably think about it some more and do lots of testing to make sure that it won't break many (any?) ports.

that's what i'm currently doing, with good results[1] so far. [1] http://trac.macports.org/projects/macports/ticket/11678 Regards, Elias

On 2007-03-30 09:10:35 -0400, Daniel J. Luke wrote:

The macports change to always add -I and -L options isn't in a release version (yet). We should probably think about it some more and do lots of testing to make sure that it won't break many (any?) ports.

That's a reason why I think that using the CPATH / LIBRARY_PATH environment variables instead of adding -I and -L options would be a better solution. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

CPATH, CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, possibly LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, and any other similar variables I may not yet know about, and give advice about the scenarios in which one might want to use each of them, or point to a document where such explanations are already made?

As I understand it (if anyone else knows better, please correct me), it works like this: 1. Whether preprocessing, compiling or linking, and whether it is C, C ++ or Objective-C code, the relevant GCC program searches paths in the following order: (a) those specified by options on the command line (e.g. via -I and - L arguments), in the order in which they appear; (b) those specified in relevant environment variables when the compiler runs; and finally (c) those coded into GCC when it was compiled. 2. There are _three_ types of environment variables that we have to worry about here. (a) CPPFLAGS, CXXFLAGS, CFLAGS and LDFLAGS are read by make (_not_ GCC), and make takes their contents and adds them _as flags on the command line_ to the relevant GCC program. Thus their contents effectively fall into 1(a) above. If the package uses something _other_ than make to build it, these variables may work differently, or not at all. (If you have both configure.env and configure.args set, they _both_ get inserted; the order depend on the Makefile contents, but it's usually configure.env first.) (b) C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH, CPATH and LIBRARY_PATH are environment variables that the relevant GCC program reads for search paths in 1(b) above. (Respectively, they are searched when preprocessing C, preprocessing C++, preprocessing Objective-C, preprocessing any of these, and when linking.) Both 2(a) and 2(b) only affect things at _compile_ time, i.e. they only make a difference if they are in the environment of the relevant GCC program when it is run to build the program. (c) DYLD_LIBRARY_PATH, DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH specify extra paths to be searched for dynamic libraries when linking _at runtime_, i.e. they only make a difference if they are in your environment when you _run_ the program, and they can override whatever the original compilation intended. (DYLD_LIBRARY_PATH is the Darwin equivalent of LD_LIBRARY_PATH on every other Unix; I don't think other Unices have equivalents for DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH.) These variables can be dangerous because, if they are set and another dynamic library is in one of them that matches the one your program looks for at run time, then incompatible or malicious code can be run if the variables mean another library is found first (the search order is all-important). (As a rule, they should be avoided unless absolutely necessary.) If you'd like references, here is the Apple documentation that I used: 2(a): GNU Make: 10.3 Variables Used By Implicit Rules (http:// developer.apple.com/documentation/DeveloperTools/gnumake/make_10.html) 2(b): GNU C/C++/Objective-C User Guide: 3.19 Environment Variables Affecting GCC (http://developer.apple.com/documentation/ DeveloperTools/gcc-4.0.1/gcc/Environment-Variables.html) 2(c): The dyld(1) man page. (The first two also come in the Reference Library that you can download and install from the Apple Developer Connection.) In light of the above, I agree with Vincent that specifying MacPorts' default search paths only by environment variables that fall into 2 (b) above would be best, we could then be much more confident that: (a) search paths will be overridden only on a port-by-port basis, either via configure.args or via CFLAGS, etc. in configure.env; and (b) the presence of other ports won't muck up compilation like it did for lynx here. Apologies for the length of this post, and do keep in mind that, though the above is long, it's still only my two cents. I hope you're enjoying your weekend. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Mobile: +61 403 855 677 Email: boeyms@fastmail.fm

On 2007-03-31 03:34:50 -0500, Ryan Schmidt wrote:

With CFLAGS, LDFLAGS and friends, we have to be careful not to overwrite but merely to append, in case some things are already defined in those variables. For example, CFLAGS by default includes -O2; if we overwrite CFLAGS we've just dropped optimization back to -O0, which may not have been intended.

Another problem is that flags can be appended in an incorrect order. When using CPATH and LIBRARY_PATH at the MacPorts level, one makes sure that particular port settings have the precedence over the system (here MacPorts) settings.

Do we have the same problem with CPATH and LIBRARY_PATH, or can I assume that they are empty to begin with and just set them to what I want?

The port command *must* override the values of these variables. As they are environment variables, they may contain values set up by the user for his own use when port is executed. And these values can conflict with MacPorts. BTW, there can be problems with software that uses pkg-config when there are conflicting paths. You'll have to check xrender installation in particular (and fix its Portfile if need be), since I had problems in the past: http://trac.macosforge.org/projects/macports/ticket/5165 If I understand correctly, for this particular software, one needs to give -I/opt/local/include explicitly *before* -I/usr/X11R6/include. But anyway pkg-config seems to handle CPATH and C_INCLUDE_PATH differently: $ CPATH="" C_INCLUDE_PATH="" pkg-config --cflags render -I/opt/local/include $ CPATH=/opt/local/include C_INCLUDE_PATH="" pkg-config --cflags render -I/opt/local/include $ CPATH="" C_INCLUDE_PATH=/opt/local/include pkg-config --cflags render $ -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)