Hi,
On Thu, May 20, 2010 at 11:14:00PM +1200, Dio Gratia wrote:
> On 20 May 10 9:05 PM, Michal Hocko wrote:
>
> >
> > OK, then this is a compiler/building env. bug for sure.
> >
>
> Apple warns that when up do a Mac OS X upgrade you need to reinstall Xcode,
> and I have the next version sitting around for an update to Mac OS X 10.6(.3).
>
> Always wondered about the class of errors you can get. Things like include
> files not matching causing code compilation errors is obvious. We also see
> for object oriented and other strong type checking languages you can have
> code that might be dependent on compiler version. We see gcc front ends
> that don't compile unless you have the right version, and you march up or
> down the version ladder from a full archive image with diff files, because
> you have to traverse boundaries with the correct before and after versions
> of gcc. The ghdl front end is like this for instance. (Hey, I'm a hardware
> guy.) gcc phases in strict compliance with new versions of languages.
I usually don't see such problems on my linux systems. gcc updates are
not that invasive. The only problem that pops out from time to time is
that newer versions tend to be more complying to C++ standard and so we
have to update _our_ code to compile properly. This is backward compatible,
though,
>
> > Could you provide me with the config.log created by configure script? I
> > would like to check how we ended up using the version of gcc and boost.
>
> Appears to be PATH dependent. the config.log is enclosed (redone with
> finding the original g++). Watching the build the only tools mentioned
> ambiguously was g++ and make.
Sure it just looks for g++ binary according to your current PATH. But
you can specify a different compiler with CXX variable as I have already
said. I am using this option quite heavily and it works just fine.
Btw. you can also specify where to find boost library by
--with-boost=PATH_TO_BOOST_HEADERS --with-boost-libdir=PATH_TO_BOOST_LIBS
parameters.
>
> >
> > You can do that by setting CXX variable (and CC for the c compiler) during
> > configure ./configure CXX=/opt/local/bin/g++-mp-4.3
> >
>
> I read through configure and looked at the config.log. I introduced the
> proper version as sym links in a bin directory (~/bin) upstream of /usr/bin.
>
> Essentially Apple does gcc version steering the same way in /usr/bin.
>
> I checked and I have 6 versions of gcc for various things (the ghdl for
> instance). When I compile it I have a C Shell alias that modifies my path
> and another one that can set it back right.
>
> Something static can allow you to build things without recourse to reading
> individual configure files and passing arguments to them.
configure, as we have it now, is not ideal but it works on most of the
POSIX platforms without having to play with parameters too much. There
are exceptions though (check out README file and you will see that e.g.
some systems place libraries in /usr/lib64).
Btw. you don't have to look at the configure source at all, it has a
nice help which should help for all parameters.
>
> >> Now you have to wonder if configure should check for naive users and
> >> compiler/library matches?
> >
> > This is a bit tricky. Anyway we can document this issue in the README.
> > Could you help us with that? Which packages have you installed (for
> > mackports) and does the configure with CXX helps?
>
> This was mostly rhetorical. The only way you could tell what version of a
> compiler was used to build a library or was associated with an include tree,
> would be if they were in a path related to which say gcc version, and you
> linked them for general use or otherwise provided environment that pointed
> to them. The problem is not knowing there is a version dependency, which in
> the case of gcc could require a lot of awareness. The way to get it to work
> would be to search these standardized tree structures for library
> dependencies and complaining about cross tree use.
I do agree that compiler dependency is a PITA but I have never seen such
a dependency for an external library. The only dependency, I am aware
of, is on libstdc++ library which is hardcoded in the g++ so you cannot
happen to include headers from a version for a different g++.
Though I can imagine that boost library (which heavily relies on c++
templates) can have problems with such a different (macports vs.
standard Mac) gcc version. I wouldn't be surprised if I installed a BSD
(or Mac) gcc on my linux box and have a problem with compilation wrt.
boost.
>
> The real problem is that a lot of people need more than one compiler and
> there is no standard way to make a distinction. Nor information on build
> dependencies against versions.
I have multiple gcc versions installed on my systems without any issues.
I heavily rely on my packaging system which shields me off the problem
and it work quite nicely, I have to say.
>
> The list of packages is macports_installed.list. The thing I was doing
> before pdfedit was geany (an IDE) generated most of it. This is only two
> days since I completely rebuilt my macports install.
>
> The problem make get big enough that there may need to be industry
> attention. Nothing seems appropriate for the immediate future for pdfedit
> other than possibly warning someone (assuming we read the README, we users
> tend to have short attention spans).
>
> >
> > Please note that we have a bug report for Mac OS X 10.5 leopard
> > (http://pdfedit.petricek.net/bt/view.php?id=346).
> >
>
> I don't know what to make of that one. I don't have a libxpdf that I can
> find.
This is a library created during compilation of PDFedit that is then
linked to GUI. In the bug it ended up empty which sounds like a
mis compilation to me.
> Everything should be dynamic libraries in Mac OS X, too. I had no
> trouble building pdfedit-0.4.4.1 with the gcc-4.0.1. The run time problems
> I thought I was having with it, I wasn't. I was using
> http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf as a test case, selecting
> the graphics objects in the school emblem on the cover sheet, which it turns
> out is comprised of hundreds of objects. Must scale up real well, but took
> a long time for pdfedit to complete the selection.
Yes, PDFedit suffers from many performance issues. Please not that this
is still in kind of alpha state far from being stable and currently it
is usable only for small changes to the document.
> I used it testing
> pdfedit-0.4.5 after I successfully completed building after putting
> gcc-4.3.4's g++ in my PATH where it would be found first. I was doing
> something else and noticed all the sudden it came back to life. It took a
> couple of minutes. (You'd think the objects in the school emblem would have
> locality).
Best regards
--
Michal Hocko
|