Bug 116321 - math/LabPlot compile fails if liborigin from ports is installed
Summary: math/LabPlot compile fails if liborigin from ports is installed
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-13 03:40 UTC by soralx
Modified: 2007-09-24 03:50 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description soralx 2007-09-13 03:40:02 UTC
	If liborigin from ports is already installed (which is pulled in by qtiplot), trying to compile ports/math/labplot results in:

if /bin/sh /usr/local/bin/libtool --silent --tag=CXX --mode=compile c++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DLVERSION=\"1.5.1\" -DLVERSION_DATE=1 -DHAVE_STRTOD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_TIFF=1 -DHAVE_GSL=1 -DHAVE_GSL14=1 -DHAVE_GSL16=1 -DHAVE_GSL17=1 -DGSL_DISABLE_DEPRECATED=1 -DHAVE_FFTW3=1 -DHAVE_FFTW3_THREADS=1 -DHAVE_JASPER=1 -DHAVE_MAGICK=1 -DHAVE_AUDIOFILE=1 -DHAVE_GL=1 -DHAVE_UNDO=1 -DKDELIBSUFF=\"\" -DHAVE_DLFCN_H=1 -DHAVE_SGI_STL=1 -DHAVE_STRLCAT=1 -DHAVE_STRLCAT_PROTO=1 -DHAVE_STRLCPY=1 -DHAVE_STRLCPY_PROTO=1 -DHAVE_CRYPT=1 -Dkde_socklen_t=socklen_t -Dksize_t=socklen_t -DHAVE_SYS_TYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_RES_INIT=1 -DHAVE_RES_INIT_PROTO=1 -DSIZEOF_INT=4 -DSIZEOF_SHORT=2 -DSIZEOF_LONG=4 -DSIZEOF_CHAR_P=4 -DSIZEOF!
 _SIZE_T=4 -DSIZEOF_UNSIGNED_LONG=4 -DHAVE_VSNPRINTF=1 -DHAVE_SNPRINTF=1 -DHAVE_LIBZ=1 -DHAVE_LIBPNG=1 -DHAVE_LIBJPEG=1 -DHAVE_LIBPTHREAD=1 -DSTDC_HEADERS=1  -I. -I. `Magick++-config --cppflags`    -I/include -I/include/qwtplot3d  -I/usr/local/include  -I/usr/local/include -I../liborigin/ -I../libundo/  -DQT_THREAD_SUPPORT   -I/usr/local/include -I/usr/local/include  -I/usr/local/include -D_GETOPT_H -D_THREAD_SAFE   -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -msse2 -O2 -march=nocona -pipe -fno-check-new -fno-common  -MT ImportOPJ.lo -MD -MP -MF ".deps/ImportOPJ.Tpo" -c -o ImportOPJ.lo ImportOPJ.cc; \
        then mv -f ".deps/ImportOPJ.Tpo" ".deps/ImportOPJ.Plo"; else rm -f ".deps/ImportOPJ.Tpo"; exit 1; fi
In file included from ImportOPJ.cc:12:
/usr/local/include/OPJFile.h: In constructor `originData::originData(double)':
/usr/local/include/OPJFile.h:52: warning: `originData::d' will be initialized after
/usr/local/include/OPJFile.h:51: warning:   `int originData::type'
/usr/local/include/OPJFile.h:58: warning:   when initialized here
/usr/local/include/OPJFile.h: In constructor `originData::originData(char*)':
/usr/local/include/OPJFile.h:53: warning: `originData::s' will be initialized after
/usr/local/include/OPJFile.h:51: warning:   `int originData::type'
/usr/local/include/OPJFile.h:63: warning:   when initialized here
/usr/local/include/OPJFile.h: In constructor `spreadColumn::spreadColumn(std::string, int)':
/usr/local/include/OPJFile.h:77: warning: `spreadColumn::index' will be initialized after
/usr/local/include/OPJFile.h:74: warning:   `std::string spreadColumn::command'
/usr/local/include/OPJFile.h:92: warning:   when initialized here
/usr/local/include/OPJFile.h:75: warning: `spreadColumn::comment' will be initialized after
/usr/local/include/OPJFile.h:69: warning:   `int spreadColumn::value_type'
/usr/local/include/OPJFile.h:92: warning:   when initialized here
/usr/local/include/OPJFile.h:76: warning: `spreadColumn::width' will be initialized after
/usr/local/include/OPJFile.h:73: warning:   `int spreadColumn::numeric_display_type'
/usr/local/include/OPJFile.h:92: warning:   when initialized here
/usr/local/include/OPJFile.h: In constructor `matrix::matrix(std::string, int)':
/usr/local/include/OPJFile.h:121: warning: `matrix::index' will be initialized after
/usr/local/include/OPJFile.h:119: warning:   `std::string matrix::command'
/usr/local/include/OPJFile.h:132: warning:   when initialized here
/usr/local/include/OPJFile.h:119: warning: `matrix::command' will be initialized after
/usr/local/include/OPJFile.h:115: warning:   `int matrix::value_type_specification'
/usr/local/include/OPJFile.h:132: warning:   when initialized here
/usr/local/include/OPJFile.h:120: warning: `matrix::width' will be initialized after
/usr/local/include/OPJFile.h:118: warning:   `int matrix::numeric_display_type'
/usr/local/include/OPJFile.h:132: warning:   when initialized here
/usr/local/include/OPJFile.h: In constructor `function::function(std::string, int)':
/usr/local/include/OPJFile.h:142: warning: `function::index' will be initialized after
/usr/local/include/OPJFile.h:137: warning:   `int function::type'
/usr/local/include/OPJFile.h:151: warning:   when initialized here
ImportOPJ.cc: In member function `int ImportOPJ::import()':
ImportOPJ.cc:40: error: 'class OPJFile' has no member named 'Data'
ImportOPJ.cc:49: error: 'class OPJFile' has no member named 'SData'
gmake[2]: *** [ImportOPJ.lo] Error 1
gmake[2]: Leaving directory `/usr/ports/math/labplot/work/LabPlot-1.5.1.5/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/math/labplot/work/LabPlot-1.5.1.5/src'
gmake: *** [all-recursive] Error 1
*** Error code 2

Stop in /usr/ports/math/labplot.


	I reckon it should compile in liborogin that is part of the labplot source (which is suboptimal, really -- a fresh steaming liborigin is right there in the ports tree, but I am not to question the developers' decisions).

Fix: 

No fix, but a workaround that works: `pkg_delete -f /var/db/pkg/liborigin-20070529/` before trying to compile LabPlot.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2007-09-13 10:01:41 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback
Comment 2 Max Brazhnikov 2007-09-23 10:44:57 UTC
LabPlot installs its own version of liborigin and opj2dat. I've marked them 
conflicting with each other (ports/116576, ports/116577).
Comment 3 Kay Lehmann 2007-09-23 11:40:08 UTC
There is another pr (ports/116577) with a patch to mark labplot 
conflicting with liborigin, so we can close this one.

Greets,
Kay

Edwin Groothuis schrieb:
> Maintainer of math/labplot,
>
> Please note that PR ports/116321 has just been submitted.
>
> If it contains a patch for an upgrade, an enhancement or a bug fix
> you agree on, reply to this email stating that you approve the patch
> and a committer will take care of it.
>
> The full text of the PR can be found at:
>     http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/116321
>
>
Comment 4 Martin Wilke freebsd_committer freebsd_triage 2007-09-23 12:33:52 UTC
State Changed
From-To: feedback->closed

close by submitter request.
Comment 5 soralx 2007-09-24 03:45:27 UTC
On Sun, 23 Sep 2007 13:44:57 +0400
Max Brazhnikov <makc@issp.ac.ru> wrote:

> LabPlot installs its own version of liborigin and opj2dat. I've
> marked them conflicting with each other (ports/116576, ports/116577).

Wouldn't we then need to fix other ports (e.g., qtiplot) that use
liborigin as well? I mean, the library in ports is much newer, so it
better be installed when other apps link against it, when LabPlot's
library (which is modified?) should go somewhere other
than /usr/local/lib. It's integral part of LabPlot, so why does it go
to the common lib location in place of the real liborigin?


[SorAlx]  ridin' VS1400