Re: multiple definition of `__i686.get_pc_thunk.bx'
b. f. wrote: On 3/1/11, Stephen Montgomery-Smith wrote: Stephen Montgomery-Smith wrote: b. f. wrote: On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: ... As is clear from bsd.gcc.mk, in almost every case now in use, USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper values. Also, it sets USE_BINUTILS where appropriate, which sets LD, etc. The problem is rather with libtool, particularly in the link mode, where it may not respect the choice of compiler and toolchain. This problem has been remarked, for two years or more, in the mailing lists and forums, when people discuss the use of compilers other than the base system compiler. With the recent updates, it is more obtrusive, and several ports that were building successfully with default settings are now broken. This needs to be fixed, and it would be better to fix libtool than to add a bunch of ad-hoc fixes to individual ports. ... OK, this problem was more subtle than I originally thought. The error I pointed out doesn't occur consistently, but it does occur in the context of building vis5d+. But I have a patch that definitely fixes libtool enough for me. What do you guys think? This perhaps doesn't fix all the problems, but maybe it can act as a model to fix them all. libtool caches more than just the compiler name. It also stores the path to various utilities (ar, as, ld, etc.), various compiler flags, compiler search directories, (pre|post)dep objects, etc. These aren't always used, but they may sometimes be important, and they vary among the different compilers in ports, so I think that any modifications should take these into account. One of the problems is that the upstream developers didn't think that (outside of cross-building, which is handled a bit differently) more than one toolchain would be in use on a given system. On my system I adopted the expedient of modifying bsd.autotools.mk and adding separate per-compiler libtool ports. That's not the prettiest way of handlng this problem either, and it is awkward for the libltdl ports, so I'm not saying that this method should be adopted. b. But maybe one could patch libtool by putting a similar if statement around every tool, to see if there is a similar tool already defined by the environment: if test -z "\$CXX"; then \\ CC=$lt_compiler_CXX else CC=\$CXX fi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
On 3/1/11, Stephen Montgomery-Smith wrote: > Stephen Montgomery-Smith wrote: >> b. f. wrote: > On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: ... >>> >>> As is clear from bsd.gcc.mk, in almost every case now in use, >>> USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper >>> values. Also, it sets USE_BINUTILS where appropriate, which sets LD, >>> etc. The problem is rather with libtool, particularly in the link >>> mode, where it may not respect the choice of compiler and toolchain. >>> This problem has been remarked, for two years or more, in the mailing >>> lists and forums, when people discuss the use of compilers other than >>> the base system compiler. With the recent updates, it is more >>> obtrusive, and several ports that were building successfully with >>> default settings are now broken. This needs to be fixed, and it would >>> be better to fix libtool than to add a bunch of ad-hoc fixes to >>> individual ports. ... > > OK, this problem was more subtle than I originally thought. The error I > pointed out doesn't occur consistently, but it does occur in the context > of building vis5d+. > > But I have a patch that definitely fixes libtool enough for me. What do > you guys think? This perhaps doesn't fix all the problems, but maybe it > can act as a model to fix them all. > > libtool caches more than just the compiler name. It also stores the path to various utilities (ar, as, ld, etc.), various compiler flags, compiler search directories, (pre|post)dep objects, etc. These aren't always used, but they may sometimes be important, and they vary among the different compilers in ports, so I think that any modifications should take these into account. One of the problems is that the upstream developers didn't think that (outside of cross-building, which is handled a bit differently) more than one toolchain would be in use on a given system. On my system I adopted the expedient of modifying bsd.autotools.mk and adding separate per-compiler libtool ports. That's not the prettiest way of handlng this problem either, and it is awkward for the libltdl ports, so I'm not saying that this method should be adopted. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
Stephen Montgomery-Smith wrote: b. f. wrote: On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: I am the maintainer of the port vis5d+. I just got this email (copied below) saying that vis5d+ isn't building right now. The issue seems to be that some reference to __i686.get_pc_thunk.bx is included twice at some point. This variable seems to be part of an object file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very mysterious conditions. I am rather sure that the issue has nothing to do with vis5d+, but rather is something to do with either gcc45, or libtools, neither of which I understand. Does anyone out there have any idea of what the problem is, or how it can be solved? From a relatively cursory examination, this appears to be a flaw in the USE_FORTRAN=yes stanza. This will bring in gcc45 as a dependency but doesn't appear to be setting CXX to g++45 though it does do CC=gcc45. Possibly the same for LD, though I haven't checked that. As is clear from bsd.gcc.mk, in almost every case now in use, USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper values. Also, it sets USE_BINUTILS where appropriate, which sets LD, etc. The problem is rather with libtool, particularly in the link mode, where it may not respect the choice of compiler and toolchain. This problem has been remarked, for two years or more, in the mailing lists and forums, when people discuss the use of compilers other than the base system compiler. With the recent updates, it is more obtrusive, and several ports that were building successfully with default settings are now broken. This needs to be fixed, and it would be better to fix libtool than to add a bunch of ad-hoc fixes to individual ports. b. I agree. libtool is the real culprit. When you run it as libtool -mode=link g++45 stuff and stuff libtool uses c++ instead of g++45. OK, this problem was more subtle than I originally thought. The error I pointed out doesn't occur consistently, but it does occur in the context of building vis5d+. But I have a patch that definitely fixes libtool enough for me. What do you guys think? This perhaps doesn't fix all the problems, but maybe it can act as a model to fix them all. --- configure.bak 2010-09-22 14:44:17.0 + +++ configure 2011-03-01 04:23:35.0 + @@ -27526,7 +27526,9 @@ old_archive_cmds=$lt_old_archive_cmds # A language specific compiler. -CC=$lt_compiler +if test -z "\$CC"; then \\ + CC=$lt_compiler +fi # Is the compiler the GNU compiler? with_gcc=$GCC @@ -27872,7 +27874,11 @@ old_archive_cmds=$lt_old_archive_cmds_CXX # A language specific compiler. -CC=$lt_compiler_CXX +if test -z "\$CXX"; then \\ + CC=$lt_compiler_CXX +else + CC=\$CXX +fi # Is the compiler the GNU compiler? with_gcc=$GCC_CXX ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
b. f. wrote:
On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote:
I am the maintainer of the port vis5d+. I just got this email (copied below)
saying that vis5d+ isn't building right now.
The issue seems to be that some reference to __i686.get_pc_thunk.bx is included
twice at some point. This variable seems to be part of an object file
crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very
mysterious conditions. I am rather sure that the issue has nothing to do with
vis5d+, but rather is something to do with either gcc45, or libtools, neither
of which I understand.
Does anyone out there have any idea of what the problem is, or how it can be
solved?
From a relatively cursory examination, this appears to be a flaw in the
USE_FORTRAN=yes stanza. This will bring in gcc45 as a dependency but doesn't
appear to be setting CXX to g++45 though it does do CC=gcc45. Possibly the
same for LD, though I haven't checked that.
As is clear from bsd.gcc.mk, in almost every case now in use,
USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper
values. Also, it sets USE_BINUTILS where appropriate, which sets LD,
etc. The problem is rather with libtool, particularly in the link
mode, where it may not respect the choice of compiler and toolchain.
This problem has been remarked, for two years or more, in the mailing
lists and forums, when people discuss the use of compilers other than
the base system compiler. With the recent updates, it is more
obtrusive, and several ports that were building successfully with
default settings are now broken. This needs to be fixed, and it would
be better to fix libtool than to add a bunch of ad-hoc fixes to
individual ports.
b.
I agree. libtool is the real culprit. When you run it as
libtool -mode=link g++45 stuff and stuff
libtool uses c++ instead of g++45. I think it would be a relatively
easy fix to make to libtool. I will even have a go at it myself if
no-one else takes the baton, but I think it would be far easier for
someone who knows libtool to do it.
By the way, my proposed bandaid fix is this:
ln -s /usr/local/bin/gcc45 ${WRKDIR}/cc
ln -s /usr/local/bin/g++45 ${WRKDIR}/c++
MAKE_ENV += PATH=${WRKDIR}:$$PATH
which could be put into bsd.gcc.mk. But it really is a very bad hack.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
> > On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: > >> I am the maintainer of the port vis5d+. I just got this email (copied > >> below) saying that vis5d+ isn't building right now. > >> > >> The issue seems to be that some reference to __i686.get_pc_thunk.bx is > >> included twice at some point. This variable seems to be part of an object > >> file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be > >> very mysterious conditions. I am rather sure that the issue has nothing > >> to do with vis5d+, but rather is something to do with either gcc45, or > >> libtools, neither of which I understand. > >> > >> Does anyone out there have any idea of what the problem is, or how it can > >> be solved? > >> > > From a relatively cursory examination, this appears to be a flaw in the > USE_FORTRAN=yes stanza. This will bring in gcc45 as a dependency but doesn't > appear to be setting CXX to g++45 though it does do CC=gcc45. Possibly the > same for LD, though I haven't checked that. As is clear from bsd.gcc.mk, in almost every case now in use, USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper values. Also, it sets USE_BINUTILS where appropriate, which sets LD, etc. The problem is rather with libtool, particularly in the link mode, where it may not respect the choice of compiler and toolchain. This problem has been remarked, for two years or more, in the mailing lists and forums, when people discuss the use of compilers other than the base system compiler. With the recent updates, it is more obtrusive, and several ports that were building successfully with default settings are now broken. This needs to be fixed, and it would be better to fix libtool than to add a bunch of ad-hoc fixes to individual ports. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
on 28/02/2011 00:41 Stephen Montgomery-Smith said the following: > Stephen Montgomery-Smith wrote: >> I am the maintainer of the port vis5d+. I just got this email (copied >> below) saying that vis5d+ isn't building right now. > > The problem seems to be with libtool. If I run a command like: > > libtool -mode=link g++45 stuff stuff > > then libtool does NOT use g++45, but it uses c++ instead. If I hand edit > /usr/local/bin/libtool and replace c++ by g++45, this fixes the problem I > describe below. It looks like libtool (foolishly?) records whatever CC/CXX is set when libtool itself is built. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
> On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: >> I am the maintainer of the port vis5d+. I just got this email (copied >> below) saying that vis5d+ isn't building right now. >> >> The issue seems to be that some reference to __i686.get_pc_thunk.bx is >> included twice at some point. This variable seems to be part of an object >> file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be >> very mysterious conditions. I am rather sure that the issue has nothing to >> do with vis5d+, but rather is something to do with either gcc45, or >> libtools, neither of which I understand. >> >> Does anyone out there have any idea of what the problem is, or how it can be >> solved? >> From a relatively cursory examination, this appears to be a flaw in the USE_FORTRAN=yes stanza. This will bring in gcc45 as a dependency but doesn't appear to be setting CXX to g++45 though it does do CC=gcc45. Possibly the same for LD, though I haven't checked that. With parts of the code being compiled against gcc45, and then an attempted link with the system compiler (CC/LD), then naturally things will go south, irrespective of whether libtool is being used. I would hazard a guess that if ya'll added USE_GCC=45 to vis5d+'s Makefile, things will link properly. If someone could test this, that'd be peachy. If it turns out that this works, then it would be a minor tweak to bsd.gcc.mk to forcibly set USE_GCC if USE_FORTRAN is also set, to allow all of the environmental variables to be punched out for compilation. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: I am the maintainer of the port vis5d+. I just got this email (copied below) saying that vis5d+ isn't building right now. The issue seems to be that some reference to __i686.get_pc_thunk.bx is included twice at some point. This variable seems to be part of an object file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very mysterious conditions. I am rather sure that the issue has nothing to do with vis5d+, but rather is something to do with either gcc45, or libtools, neither of which I understand. Does anyone out there have any idea of what the problem is, or how it can be solved? I've seen a similar problem with py-numpy. It seems to occur when there's a compiler/linker mismatch. In py-numpy's case, I was able to resolve it by defining LDSHARED to an appropriate value: MAKE_ENV+= LDSHARED="gcc45 -shared" Otherwise, the build was trying to use /usr/local/bin/gcc45 to compiler and /usr/bin/cc to link, resulting in the two different thunk definitions. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: multiple definition of `__i686.get_pc_thunk.bx'
Stephen Montgomery-Smith wrote: I am the maintainer of the port vis5d+. I just got this email (copied below) saying that vis5d+ isn't building right now. The problem seems to be with libtool. If I run a command like: libtool -mode=link g++45 stuff stuff then libtool does NOT use g++45, but it uses c++ instead. If I hand edit /usr/local/bin/libtool and replace c++ by g++45, this fixes the problem I describe below. The issue seems to be that some reference to __i686.get_pc_thunk.bx is included twice at some point. This variable seems to be part of an object file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very mysterious conditions. I am rather sure that the issue has nothing to do with vis5d+, but rather is something to do with either gcc45, or libtools, neither of which I understand. Does anyone out there have any idea of what the problem is, or how it can be solved? Erwin Lansing wrote: Subject: Re: [ports-i...@freebsd.org: vis5d+-1.2.1_15 failed on i386 8] FYI; can you please investigate and/or report to the developers? If you are already aware of this problem but do not yet have a fix, please mark the port BROKEN in the appropriate case, so that users do not unexpectedly encounter it. See http://pointyhat.freebsd.org for the full log. Thanks, -erwin - Forwarded message from User Ports-i386 - Date: Thu, 24 Feb 2011 02:48:11 GMT From: User Ports-i386 To: er...@freebsd.org, m...@freebsd.org, ite...@freebsd.org, lini...@freebsd.org Subject: vis5d+-1.2.1_15 failed on i386 8 Excerpt from the build log at http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log . libtool: compile: gcc45 -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/local/include -O2 -pipe -DMIX_ANSI_IOSTREAMS -fPIC -fpermissive -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -std=gnu89 -Wall -D_THREAD_SAFE -c xdump.c -MT xdump.lo -MD -MP -MF .deps/xdump.TPlo -o xdump.o>/dev/null 2>&1 /bin/sh /usr/local/bin/libtool --mode=link g++45 -O2 -pipe -DMIX_ANSI_IOSTREAMS -fPIC -fpermissive -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -L/usr/local/lib -L/usr/local/lib -pthread -Wl,-rpath=/usr/local/lib/gcc45 -o libvis5d.la -rpath /usr/local/lib -version-info 2:0:0 api.lo analysis.lo anim.lo box.lo chrono.lo compute.lo contour.lo groupchrono.lo globals.lo graphics.all.lo grid.lo image.lo imemory.lo map.lo matrix.lo linterp.lo memory.lo misc.lo mwmborder.lo proj.lo queue.lo render.lo rgb.lo record.lo save.lo socketio.lo stream.lo sounding.lo sync.lo tclsave.lo textplot.lo topo.lo traj.lo user_data.lo volume.lo vtmcP.lo work.lo sgidump.lo decimate.lo analyze_i.lo file_i.lo grid_i.lo misc_i.lo output_i.lo proj_i.lo projlist_i.lo read_epa_i.lo read_gr3d_i.lo read_grid_i.lo read_grads_i.lo read_uwvis_i.lo read_v5d_i.lo resample_i.lo select_i.lo tokenize_i.lo iapi.lo file.lo irregular_v5d.lo gl_to_ppm.lo graphics.ogl.lo graphics.scenes.lo graphic s .v rml.lo xdump.lo -lm -lgfx libtool: link: c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o .libs/api.o .libs/analysis.o .libs/anim.o .libs/box.o .libs/chrono.o .libs/compute.o .libs/contour.o .libs/groupchrono.o .libs/globals.o .libs/graphics.all.o .libs/grid.o .libs/image.o .libs/imemory.o .libs/map.o .libs/matrix.o .libs/linterp.o .libs/memory.o .libs/misc.o .libs/mwmborder.o .libs/proj.o .libs/queue.o .libs/render.o .libs/rgb.o .libs/record.o .libs/save.o .libs/socketio.o .libs/stream.o .libs/sounding.o .libs/sync.o .libs/tclsave.o .libs/textplot.o .libs/topo.o .libs/traj.o .libs/user_data.o .libs/volume.o .libs/vtmcP.o .libs/work.o .libs/sgidump.o .libs/decimate.o .libs/analyze_i.o .libs/file_i.o .libs/grid_i.o .libs/misc_i.o .libs/output_i.o .libs/proj_i.o .libs/projlist_i.o .libs/read_epa_i.o .libs/read_gr3d_i.o .libs/read_grid_i.o .libs/read_grads_i.o .libs/read_uwvis_i.o .libs/read_v5d_i.o .libs/resample_i.o .libs/select_i.o .libs/tokenize_i.o .libs/iapi.o .libs/file.o .libs/irreg u la r_v5d.o .libs/gl_to_ppm.o .libs/graphics.ogl.o .libs/graphics.scenes.o .libs/graphics.vrml.o .libs/xdump.o -L/usr/local/lib -pthread -lgfx -L/usr/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-rpath=/usr/local/lib/gcc45 -pthread -Wl,-rpath=/usr/local/lib/gcc45 -pthread -pthread -pthread -Wl,-soname -Wl,libvis5d.so.2 -o .libs/libvis5d.so.2 .libs/api.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1/src. *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1/src. *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1. *** Error code 1 Stop in /work/a/ports/science/vis5d+/wor
Re: multiple definition of `__i686.get_pc_thunk.bx'
On Sun, Feb 27, 2011 at 02:24:06PM -0600, Stephen Montgomery-Smith wrote: > I am the maintainer of the port vis5d+. I just got this email (copied > below) saying that vis5d+ isn't building right now. > > The issue seems to be that some reference to __i686.get_pc_thunk.bx is > included twice at some point. This variable seems to be part of an > object file crtbeginS.o that is created by gcc or gcc45, in what seem to > me to be very mysterious conditions. I am rather sure that the issue > has nothing to do with vis5d+, but rather is something to do with either > gcc45, or libtools, neither of which I understand. > > Does anyone out there have any idea of what the problem is, or how it > can be solved? Most likely, you compile source with gcc45, but link it with system c++, or libtool constructed linkage command as if for system c++. Use consistent toolchain for compilation and linking. > > > Erwin Lansing wrote: > > Subject: Re: [ports-i...@freebsd.org: vis5d+-1.2.1_15 failed on i386 8] > > > > >FYI; can you please investigate and/or report to the developers? If > >you are already aware of this problem but do not yet have a fix, > >please mark the port BROKEN in the appropriate case, so that users do > >not unexpectedly encounter it. > > > >See http://pointyhat.freebsd.org for the full log. > > > >Thanks, > >-erwin > > > >- Forwarded message from User Ports-i386 - > > > >Date: Thu, 24 Feb 2011 02:48:11 GMT > >From: User Ports-i386 > >To: er...@freebsd.org, m...@freebsd.org, ite...@freebsd.org, > >lini...@freebsd.org > >Subject: vis5d+-1.2.1_15 failed on i386 8 > > > >Excerpt from the build log at > > > > > > http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log > > . > > > > >libtool: compile: gcc45 -DHAVE_CONFIG_H -I. -I. -I.. -I. > >-I/usr/local/include -O2 -pipe -DMIX_ANSI_IOSTREAMS -fPIC -fpermissive > >-Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -std=gnu89 -Wall > >-D_THREAD_SAFE -c xdump.c -MT xdump.lo -MD -MP -MF .deps/xdump.TPlo -o > >xdump.o>/dev/null 2>&1 > >/bin/sh /usr/local/bin/libtool --mode=link g++45 -O2 -pipe > >-DMIX_ANSI_IOSTREAMS -fPIC -fpermissive -Wl,-rpath=/usr/local/lib/gcc45 > >-fno-strict-aliasing -L/usr/local/lib -L/usr/local/lib -pthread > >-Wl,-rpath=/usr/local/lib/gcc45 -o libvis5d.la -rpath /usr/local/lib > >-version-info 2:0:0 api.lo analysis.lo anim.lo box.lo chrono.lo > >compute.lo contour.lo groupchrono.lo globals.lo graphics.all.lo grid.lo > >image.lo imemory.lo map.lo matrix.lo linterp.lo memory.lo misc.lo > >mwmborder.lo proj.lo queue.lo render.lo rgb.lo record.lo save.lo > >socketio.lo stream.lo sounding.lo sync.lo tclsave.lo textplot.lo topo.lo > >traj.lo user_data.lo volume.lo vtmcP.lo work.lo sgidump.lo decimate.lo > >analyze_i.lo file_i.lo grid_i.lo misc_i.lo output_i.lo proj_i.lo > >projlist_i.lo read_epa_i.lo read_gr3d_i.lo read_grid_i.lo read_grads_i.lo > >read_uwvis_i.lo read_v5d_i.lo resample_i.lo select_i.lo tokenize_i.lo > >iapi.lo file.lo irregular_v5d.lo gl_to_ppm.lo graphics.ogl.lo > >graphics.scenes.lo graphics > .v > > rml.lo xdump.lo -lm -lgfx > >libtool: link: c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o > >.libs/api.o .libs/analysis.o .libs/anim.o .libs/box.o .libs/chrono.o > >.libs/compute.o .libs/contour.o .libs/groupchrono.o .libs/globals.o > >.libs/graphics.all.o .libs/grid.o .libs/image.o .libs/imemory.o > >.libs/map.o .libs/matrix.o .libs/linterp.o .libs/memory.o .libs/misc.o > >.libs/mwmborder.o .libs/proj.o .libs/queue.o .libs/render.o .libs/rgb.o > >.libs/record.o .libs/save.o .libs/socketio.o .libs/stream.o > >.libs/sounding.o .libs/sync.o .libs/tclsave.o .libs/textplot.o > >.libs/topo.o .libs/traj.o .libs/user_data.o .libs/volume.o .libs/vtmcP.o > >.libs/work.o .libs/sgidump.o .libs/decimate.o .libs/analyze_i.o > >.libs/file_i.o .libs/grid_i.o .libs/misc_i.o .libs/output_i.o > >.libs/proj_i.o .libs/projlist_i.o .libs/read_epa_i.o .libs/read_gr3d_i.o > >.libs/read_grid_i.o .libs/read_grads_i.o .libs/read_uwvis_i.o > >.libs/read_v5d_i.o .libs/resample_i.o .libs/select_i.o .libs/tokenize_i.o > >.libs/iapi.o .libs/file.o .libs/irregu > la > > r_v5d.o .libs/gl_to_ppm.o .libs/graphics.ogl.o .libs/graphics.scenes.o > > .libs/graphics.vrml.o .libs/xdump.o -L/usr/local/lib -pthread -lgfx > > -L/usr/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/crtendS.o /usr/lib/crtn.o > > -Wl,-rpath=/usr/local
multiple definition of `__i686.get_pc_thunk.bx'
I am the maintainer of the port vis5d+. I just got this email (copied below) saying that vis5d+ isn't building right now. The issue seems to be that some reference to __i686.get_pc_thunk.bx is included twice at some point. This variable seems to be part of an object file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very mysterious conditions. I am rather sure that the issue has nothing to do with vis5d+, but rather is something to do with either gcc45, or libtools, neither of which I understand. Does anyone out there have any idea of what the problem is, or how it can be solved? Erwin Lansing wrote: Subject: Re: [ports-i...@freebsd.org: vis5d+-1.2.1_15 failed on i386 8] FYI; can you please investigate and/or report to the developers? If you are already aware of this problem but do not yet have a fix, please mark the port BROKEN in the appropriate case, so that users do not unexpectedly encounter it. See http://pointyhat.freebsd.org for the full log. Thanks, -erwin - Forwarded message from User Ports-i386 - Date: Thu, 24 Feb 2011 02:48:11 GMT From: User Ports-i386 To: er...@freebsd.org, m...@freebsd.org, ite...@freebsd.org, lini...@freebsd.org Subject: vis5d+-1.2.1_15 failed on i386 8 Excerpt from the build log at http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log . libtool: compile: gcc45 -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/local/include -O2 -pipe -DMIX_ANSI_IOSTREAMS -fPIC -fpermissive -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -std=gnu89 -Wall -D_THREAD_SAFE -c xdump.c -MT xdump.lo -MD -MP -MF .deps/xdump.TPlo -o xdump.o>/dev/null 2>&1 /bin/sh /usr/local/bin/libtool --mode=link g++45 -O2 -pipe -DMIX_ANSI_IOSTREAMS -fPIC -fpermissive -Wl,-rpath=/usr/local/lib/gcc45 -fno-strict-aliasing -L/usr/local/lib -L/usr/local/lib -pthread -Wl,-rpath=/usr/local/lib/gcc45 -o libvis5d.la -rpath /usr/local/lib -version-info 2:0:0 api.lo analysis.lo anim.lo box.lo chrono.lo compute.lo contour.lo groupchrono.lo globals.lo graphics.all.lo grid.lo image.lo imemory.lo map.lo matrix.lo linterp.lo memory.lo misc.lo mwmborder.lo proj.lo queue.lo render.lo rgb.lo record.lo save.lo socketio.lo stream.lo sounding.lo sync.lo tclsave.lo textplot.lo topo.lo traj.lo user_data.lo volume.lo vtmcP.lo work.lo sgidump.lo decimate.lo analyze_i.lo file_i.lo grid_i.lo misc_i.lo output_i.lo proj_i.lo projlist_i.lo read_epa_i.lo read_gr3d_i.lo read_grid_i.lo read_grads_i.lo read_uwvis_i.lo read_v5d_i.lo resample_i.lo select_i.lo tokenize_i.lo iapi.lo file.lo irregular_v5d.lo gl_to_ppm.lo graphics.ogl.lo graphics.scenes.lo graphics .v rml.lo xdump.lo -lm -lgfx libtool: link: c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o .libs/api.o .libs/analysis.o .libs/anim.o .libs/box.o .libs/chrono.o .libs/compute.o .libs/contour.o .libs/groupchrono.o .libs/globals.o .libs/graphics.all.o .libs/grid.o .libs/image.o .libs/imemory.o .libs/map.o .libs/matrix.o .libs/linterp.o .libs/memory.o .libs/misc.o .libs/mwmborder.o .libs/proj.o .libs/queue.o .libs/render.o .libs/rgb.o .libs/record.o .libs/save.o .libs/socketio.o .libs/stream.o .libs/sounding.o .libs/sync.o .libs/tclsave.o .libs/textplot.o .libs/topo.o .libs/traj.o .libs/user_data.o .libs/volume.o .libs/vtmcP.o .libs/work.o .libs/sgidump.o .libs/decimate.o .libs/analyze_i.o .libs/file_i.o .libs/grid_i.o .libs/misc_i.o .libs/output_i.o .libs/proj_i.o .libs/projlist_i.o .libs/read_epa_i.o .libs/read_gr3d_i.o .libs/read_grid_i.o .libs/read_grads_i.o .libs/read_uwvis_i.o .libs/read_v5d_i.o .libs/resample_i.o .libs/select_i.o .libs/tokenize_i.o .libs/iapi.o .libs/file.o .libs/irregu la r_v5d.o .libs/gl_to_ppm.o .libs/graphics.ogl.o .libs/graphics.scenes.o .libs/graphics.vrml.o .libs/xdump.o -L/usr/local/lib -pthread -lgfx -L/usr/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-rpath=/usr/local/lib/gcc45 -pthread -Wl,-rpath=/usr/local/lib/gcc45 -pthread -pthread -pthread -Wl,-soname -Wl,libvis5d.so.2 -o .libs/libvis5d.so.2 .libs/api.o(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' /usr/lib/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0): first defined here *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1/src. *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1/src. *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1. *** Error code 1 Stop in /work/a/ports/science/vis5d+/work/vis5d+-1.2.1. *** Error code 1 Stop in /a/ports/science/vis5d+. build of /usr/ports/science/vis5d+ ended at Thu Feb 24 02:47:46 UTC 2011 !DSPAM:4d65c6f0315011692978788! - End forwarded message - __
