Re: CD Access in 9.x and -CURRENT
On Wed, Dec 28, 2011 at 9:56 PM, Joseph S. Atkinson wrote: > I am the maintainer of VLC, I have an outstanding PR (ports/162190) on the > issue of cdda:// access. > > I can confirm this issues, but don't know enough about driver access to fix > this myself. Doug Barton reports that cdcontrol(1) doesn't work for him, and > mplayer and audactiy also display issues running as non-root. > > Under 9.0-RC3 r228843, I get these errors on boot with no disc present in > /dev/cd0 at all. > > (pass1:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 01 > 00 > (pass1:ahcich2:0:0:0): CAM status: ATA Status Error > (pass1:ahcich2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) > (pass1:ahcich2:0:0:0): RES: 51 04 01 14 eb 40 00 00 00 01 00 > > These ports are fairly popular, but the problems may not lie exclusively > with their assumptions about FreeBSD. I am running 10.0 on another machine > specifically to test changes under src/sys/cam. > > I am worried that with the actual 9.0-RELEASE on the horizon, users will > find show stopping problems using their disc drives. Try having users merge r228808 and r228847. If that works, then I would press re@ produce another RC that fixes this. Thanks, -Garrett PS This is coming from a user that was annoyed by this gap with the ATA_CAM code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CD Access in 9.x and -CURRENT
I am the maintainer of VLC, I have an outstanding PR (ports/162190) on the issue of cdda:// access. I can confirm this issues, but don't know enough about driver access to fix this myself. Doug Barton reports that cdcontrol(1) doesn't work for him, and mplayer and audactiy also display issues running as non-root. Under 9.0-RC3 r228843, I get these errors on boot with no disc present in /dev/cd0 at all. (pass1:ahcich2:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 01 00 (pass1:ahcich2:0:0:0): CAM status: ATA Status Error (pass1:ahcich2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass1:ahcich2:0:0:0): RES: 51 04 01 14 eb 40 00 00 00 01 00 These ports are fairly popular, but the problems may not lie exclusively with their assumptions about FreeBSD. I am running 10.0 on another machine specifically to test changes under src/sys/cam. I am worried that with the actual 9.0-RELEASE on the horizon, users will find show stopping problems using their disc drives. -- Joseph S. Atkinson Paellax Technology Group http://www.paellax.com/ -- Sent from my FreeBSD/GNOME laptop 'pazuzu'. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
Rather than changing BKVASIZE, I would try running the cvs2svn conversion on a 16K/2K filesystem and see if that sorts out the problem. If it does, it tells us that doubling the main block size and reducing the number of buffers by half is the problem. If that is the problem, then we will have to increase the KVM allocated to the buffer cache. Kirk McKusick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: grep
On Thu, 29 Dec 2011, Randy Bush wrote: bsdgrep works, grep does not % echo foo | bsdgrep foo foo % echo foo | grep foo % Make sure you do not have an alias or function for grep. I have once or twice in the past inadvertently created aliases or functions for grep that did nothing. That was a fun experience trying to find out why grep was ignoring me. ;) Sean -- s...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: grep
bsdgrep works, grep does not % echo foo | bsdgrep foo foo % echo foo | grep foo % ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: grep
>> % echo foo | grep foo >> % > > I'm using pretty recent -current, and it works for me. Are you by any > chance using bsdgrep? (it's not the default) not to my knowledge > If you haven't enabled the option for bsdgrep in src.conf then do the > same thing in /usr/src/gnu/usr.bin/grep. > > make cleandir && make obj && make depend && make all && make install i guess that have bigger issues :( randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: grep
On 12/28/2011 14:35, Randy Bush wrote: > FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51 > UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64 > > % echo foo | grep foo > % > > so i am csupping hoping to pick up the fix. I'm using pretty recent -current, and it works for me. Are you by any chance using bsdgrep? (it's not the default) > but what do i need to do so > that the sucker can build a new kernel and world? It will probably be necessary to replace the grep binary after you update your source. If you're using bsdgrep try this in /usr/src/usr.bin/grep: make cleandir && make obj && make depend && make all && make install If you haven't enabled the option for bsdgrep in src.conf then do the same thing in /usr/src/gnu/usr.bin/grep. If neither of those produce a working grep, you've got bigger issues. hth, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN -> CVS gateway stalled?
On Wed, 2011-12-28 at 12:49 -0800, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I noticed updates come from SVN today but haven't yet seen them in CVS. > Is it busted again? > Clusteradm@ can take a look at this ... I think. Sean signature.asc Description: This is a digitally signed message part
grep
FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51 UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64 % echo foo | grep foo % so i am csupping hoping to pick up the fix. but what do i need to do so that the sucker can build a new kernel and world? randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J systems do not fsck themselves
Hello, Mdf. You wrote 28 декабря 2011 г., 23:14:19: > Not required by SU as they use an explicit BIO_FLUSH which should be > handled by the driver. No, they don't. It was discussed here about month ago. -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN -> CVS gateway stalled?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed updates come from SVN today but haven't yet seen them in CVS. Is it busted again? imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk77gOsACgkQQv9rrgRC1JJRowCgqnaVL7F6+LrS9QSayq2dQUM/ Ei8AoJqoZDG82ZabnpP6zlMZjTJj1L9x =7g4y -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Removal of sysinstall from HEAD and lack of a post-install configuration tool
On Wed, Dec 28, 2011 at 5:25 AM, Vincent Hoffman wrote: > On 28/12/2011 06:30, Doug Barton wrote: > > On 12/27/2011 22:08, Adrian Chadd wrote: > >> Hi, > >> > >> Why not just list the things that sysinstall did that people like, and > >> extract out / reimplement those bits? > > That's sounds great. As soon as that's done, we can remove sysinstall > > from the base. Until those things exist, removing it is premature. > > > In that case can I suggest a wiki page or other viewable/editable list > of desirable features from sysinstall? > I only used it for the basic disklayout and component install so I'm not > in a position to start it off or I would. > > Vince > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Why not just get the list from sysinstall? Distributions Install additional distribution sets Documentation installation Install FreeBSD Documentation set PackagesInstall pre-packaged software for FreeBSD Root Password Set the system manager's password Fdisk The disk Slice (PC-style partition) Editor Label The disk Label editor User Management Add user and group information Console Customize system console behavior Time Zone Set which time zone you're in Media Change the installation media type Mouse Configure your mouse Networking Configure additional network services SecurityConfigure system security options Startup Configure system startup options TTYsConfigure system ttys. Options View/Set various installation options HTML Docs Go to the HTML documentation menu (post-install) Load KLDLoad a KLD from a floppy Several of these simply call other tools that will remain present, but several are internal to sysinstall. Fdisk and Label should be replaced by the gpart tools already in bsdinstall. A couple might be simply removed, but most are either useful or near essential, especially for new user. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J systems do not fsck themselves
On Wed, Dec 28, 2011 at 11:14:19AM -0800, m...@freebsd.org wrote: > SU doesn't care about write ordering, as long as everything before a > BIO_FLUSH is really flushed by the time the BIO_FLUSH is acknowledged. No. SU and SU+J only require that write completed notification is issued when geom/driver layer guarantees that the block content is written to the stable storage. SU does not depend on non-reordering of writes in any way, as well as it does not issue BIO_FLUSH. pgpkZdtAOt9Lt.pgp Description: PGP signature
Re: SU+J systems do not fsck themselves
On Wed, Dec 28, 2011 at 8:54 AM, Maxim Khitrov wrote: > On Wed, Dec 28, 2011 at 11:42 AM, Matthias Andree > wrote: >> Am 27.12.2011 22:53, schrieb David Thiel: >>> I've had multiple machines now (9.0-RC3, amd64, i386 and earlier >>> 9-CURRENT on ppc) running SU+J that have had unexplained panics and >>> crashes start happening relating to disk I/O. When I end up running a >>> full fsck, it keeps turning out that the disk is dirty and corrupted, >>> but no mechanism is in place with SU+J to detect and fix this. A bgfsck >>> never happens, but a manual fsck in single-user does indeed fix the >>> crashing and weird behavior. Others have tested their SU+J volumes and >>> found them to have errors as well. This makes me super nervous. >> >> The one thing I figured is that in the light of power outages, or >> crashing virtualization hosts, you really really really need to disable >> disk write caches, and this affects softupdates, journalling, asynch >> file systems, just about everything. >> >> The fact that makes matters worse is that journalling or softupdates >> allow you to mount a silently-corrupted file system, whereas the >> traditional UFS/UFS2 sync/asynch mounts will fsck themselves in the >> foreground, so they get fixed before the FS panics. >> >> So can you be sure that: >> >> - your driver, chip set and hard disk execute ordered writes in order, If they don't, it's a bug. Not that there isn't buggy firmware out there, but each layer of software does need to rely on the one below actually doing what it's promised. >> - your driver, chip set and hard disk actually write data to permanent >> storage BEFORE acknowledging a successful write? Not required by SU as they use an explicit BIO_FLUSH which should be handled by the driver. >> Whenever I fixed these issues, I had no more corruptions. >> >> For ata and sata, there are loader tunables you will want to set, >> hw.ata.wc=0 and kern.cam.ada.write_cache=0. This should not be necessary if the driver and firmware are not buggy. >> If your drives are under ada, ad, or ahci related control, try these >> settings. For SCSI, use camcontrol to turn the write cache off. >> softupdates is supposed to rectify most of the performance penalties >> incurred. >> >> Note also that you needed to set ahci_load=YES and atapicam_load=YES in >> 8.X, I've never bothered to check 7.X or 9.X WRT these settings. > > This is a bit off-topic, but I'm curious what the effect of NCQ is on > softupdates? Since that too has the ability to reorder writes to disk, > should it be disabled in addition to cache? SU doesn't care about write ordering, as long as everything before a BIO_FLUSH is really flushed by the time the BIO_FLUSH is acknowledged. Cheers, matthew > Also, I would say that if you are using a hardware raid controller > with a BBU, then allowing the use of controller's cache and write-back > policy should be safe for use with softupdates. Any caching mechanism, > for that matter, that has a separate power supply source should be ok. > For example, the Intel 320 SSDs have a few on-board capacitors that > are used to flush the cache in the event of a power loss. > > - Max > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: > Am 12/28/11 19:10, schrieb Ed Schouten: > > * Rainer Hurling , 20111228 17:31: > >> error: macro "_Static_assert" passed 3 arguments, but takes just 2 > >> In file included from > >> /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: > > > > Hmmm... This seems to apply to my changes. I will look into this > > tomorrow. Thanks for the report! > > > > > Be aware that the error produced by the linker I mentioned in the > initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. > > I already filed a PR about the problem of a non compiling lang/gcc46 > today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test > puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. > > I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Obviously, linker error during the compilation of third-party software has nothing to do with compiler error occuring when building gcc. Do people ever read the texts of the messages ? pgpXZQ7ftuzPn.pgp Description: PGP signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
Am 12/28/11 19:10, schrieb Ed Schouten: > * Rainer Hurling , 20111228 17:31: >> error: macro "_Static_assert" passed 3 arguments, but takes just 2 >> In file included from >> /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: > > Hmmm... This seems to apply to my changes. I will look into this > tomorrow. Thanks for the report! > Be aware that the error produced by the linker I mentioned in the initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. I already filed a PR about the problem of a non compiling lang/gcc46 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Oliver signature.asc Description: OpenPGP digital signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
* Rainer Hurling , 20111228 17:31: > error: macro "_Static_assert" passed 3 arguments, but takes just 2 > In file included from > /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! -- Ed Schouten WWW: http://80386.nl/ pgpgFV4VlXdVC.pgp Description: PGP signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On 28.12.11 17:31, Rainer Hurling wrote: On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote: Am 12/28/11 14:58, schrieb Kostik Belousov: On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: Hello out here. I run into a problem since one of the last portupdates and I do not know whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 AMD64. Background: We use a scientific graphical toolset for planetary research called ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a couple of weeks ago. On all of my boxes, I do frequently a portupgrade, so I saw binutils got bumped up and gcc 4.6 is also getting really frequently changed these days. After a some portupdates within the last weeks, I just decided to compile ISIS3 again to keep it "fresh and on track", but it won't compile anymore. On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and CLANG built) I receive in some subfolders containing sources the follwoing error: [...] Adding API object [UniqueIOCachingAlgorithm] Adding API object [UniversalGroundMap] Adding API object [UserInterface] Adding API object [VariableLineScanCameraDetectorMap] Adding API object [VecFilter] Adding API object [WorldMapper] Adding API object [iException] Adding API object [iString] Adding API object [iTime] Working on Package [mex] (11:30:15) Adding API object [HrscCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libHrscCamera.so: No such file or directory gmake[4]: *** [install] Error 1 The error is completely clear as it is: the build tries to link static library libstdc++.so into shared object. This is not supported. Thanks, Kostik, for the fast response. The error isn't so clear to me, sorry. I thought libstdc++.a is the static library and it is taken to be referenced/compiled into a shared Linked in. object created by the application I try to compile. Right, and this is not supported. Code linked into shared object must be compiled PIC. An .a library usually does not contain objects compiled by PIC, ld just dutifully reported back. I'm much more confused now, since I thought the last time I compiled that piece of software, I never got any error like that. Well, clang fails with some obscure errors on the code itself and I'm unwilling to correct them, I'll try the legacy gcc 4.2.1 and will report what's happening. It might have worked by accident (because libstdc++.a objects referenced during the link did not carried unsupported relocations), or, much more likely, the build system has changed and started doing stupid things. It must not link static libraries into shared objects. You should examine why it does this, and fix it. Changing compilers is just wasting a time. Hmm, I get a similar error when trying to build lang/gcc46 on recent 10-CURRENT: [..snip..] Making all in include gmake[4]: Entering directory `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include' mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch /usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs -B/usr/local/x86_64-portbld-freebsd10.0/bin/ -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd10.0/include -isystem /usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header -nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0 -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include -I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0, from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100: /usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31: error: mac
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
Am 12/28/11 17:31, schrieb Rainer Hurling: > On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote: >> On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote: >>> Am 12/28/11 14:58, schrieb Kostik Belousov: On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: > Hello out here. > > I run into a problem since one of the last portupdates and I do not > know > whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 > AMD64. > > Background: > We use a scientific graphical toolset for planetary research called > ISIS3, which is provided by the USGS. We patched ISIS3 to run on > FreeBSD > 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a > couple of weeks ago. > On all of my boxes, I do frequently a portupgrade, so I saw > binutils got > bumped up and gcc 4.6 is also getting really frequently changed > these days. > After a some portupdates within the last weeks, I just decided to > compile ISIS3 again to keep it "fresh and on track", but it won't > compile anymore. > > On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and > CLANG built) I receive in some subfolders containing sources the > follwoing error: > > [...] > Adding API object [UniqueIOCachingAlgorithm] > Adding API object [UniversalGroundMap] > Adding API object [UserInterface] > Adding API object [VariableLineScanCameraDetectorMap] > Adding API object [VecFilter] > Adding API object [WorldMapper] > Adding API object [iException] > Adding API object [iString] > Adding API object [iTime] >Working on Package [mex] (11:30:15) > Adding API object [HrscCamera] > /usr/local/bin/ld: > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): > > relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' > can not be used when making a shared object; recompile with -fPIC > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: > > could not read symbols: Bad value > collect2: ld returned 1 exit status > gmake[5]: *** [plugin] Error 1 > cp: libHrscCamera.so: No such file or directory > gmake[4]: *** [install] Error 1 The error is completely clear as it is: the build tries to link static library libstdc++.so into shared object. This is not supported. >>> >>> Thanks, Kostik, for the fast response. >>> The error isn't so clear to me, sorry. I thought libstdc++.a is the >>> static library and it is taken to be referenced/compiled into a shared >> Linked in. >> >>> object created by the application I try to compile. >> Right, and this is not supported. Code linked into shared object must >> be compiled PIC. An .a library usually does not contain objects compiled >> by PIC, ld just dutifully reported back. >> >>> >>> I'm much more confused now, since I thought the last time I compiled >>> that piece of software, I never got any error like that. Well, clang >>> fails with some obscure errors on the code itself and I'm unwilling to >>> correct them, I'll try the legacy gcc 4.2.1 and will report what's >>> happening. >> >> It might have worked by accident (because libstdc++.a objects referenced >> during the link did not carried unsupported relocations), or, much more >> likely, the build system has changed and started doing stupid things. >> It must not link static libraries into shared objects. >> >> You should examine why it does this, and fix it. Changing compilers is >> just wasting a time. > > > Hmm, I get a similar error when trying to build lang/gcc46 on recent > 10-CURRENT: > > > [..snip..] > Making all in include > gmake[4]: Entering directory > `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include' > > mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch > /usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc > -B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++ > -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src > -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs > -B/usr/local/x86_64-portbld-freebsd10.0/bin/ > -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem > /usr/local/x86_64-portbld-freebsd10.0/include -isystem > /usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header > -nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing > -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0 > -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include > -I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2 > -g -std=gnu++0x > /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/includ
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote: Am 12/28/11 14:58, schrieb Kostik Belousov: On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: Hello out here. I run into a problem since one of the last portupdates and I do not know whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 AMD64. Background: We use a scientific graphical toolset for planetary research called ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a couple of weeks ago. On all of my boxes, I do frequently a portupgrade, so I saw binutils got bumped up and gcc 4.6 is also getting really frequently changed these days. After a some portupdates within the last weeks, I just decided to compile ISIS3 again to keep it "fresh and on track", but it won't compile anymore. On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and CLANG built) I receive in some subfolders containing sources the follwoing error: [...] Adding API object [UniqueIOCachingAlgorithm] Adding API object [UniversalGroundMap] Adding API object [UserInterface] Adding API object [VariableLineScanCameraDetectorMap] Adding API object [VecFilter] Adding API object [WorldMapper] Adding API object [iException] Adding API object [iString] Adding API object [iTime] Working on Package [mex] (11:30:15) Adding API object [HrscCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libHrscCamera.so: No such file or directory gmake[4]: *** [install] Error 1 The error is completely clear as it is: the build tries to link static library libstdc++.so into shared object. This is not supported. Thanks, Kostik, for the fast response. The error isn't so clear to me, sorry. I thought libstdc++.a is the static library and it is taken to be referenced/compiled into a shared Linked in. object created by the application I try to compile. Right, and this is not supported. Code linked into shared object must be compiled PIC. An .a library usually does not contain objects compiled by PIC, ld just dutifully reported back. I'm much more confused now, since I thought the last time I compiled that piece of software, I never got any error like that. Well, clang fails with some obscure errors on the code itself and I'm unwilling to correct them, I'll try the legacy gcc 4.2.1 and will report what's happening. It might have worked by accident (because libstdc++.a objects referenced during the link did not carried unsupported relocations), or, much more likely, the build system has changed and started doing stupid things. It must not link static libraries into shared objects. You should examine why it does this, and fix it. Changing compilers is just wasting a time. Hmm, I get a similar error when trying to build lang/gcc46 on recent 10-CURRENT: [..snip..] Making all in include gmake[4]: Entering directory `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include' mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch /usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src -L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs -B/usr/local/x86_64-portbld-freebsd10.0/bin/ -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd10.0/include -isystem /usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header -nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0 -I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include -I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0, from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100: /usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31: error: macro "_Static_assert" passed 3 argu
Re: SU+J systems do not fsck themselves
On Wed, Dec 28, 2011 at 11:42 AM, Matthias Andree wrote: > Am 27.12.2011 22:53, schrieb David Thiel: >> I've had multiple machines now (9.0-RC3, amd64, i386 and earlier >> 9-CURRENT on ppc) running SU+J that have had unexplained panics and >> crashes start happening relating to disk I/O. When I end up running a >> full fsck, it keeps turning out that the disk is dirty and corrupted, >> but no mechanism is in place with SU+J to detect and fix this. A bgfsck >> never happens, but a manual fsck in single-user does indeed fix the >> crashing and weird behavior. Others have tested their SU+J volumes and >> found them to have errors as well. This makes me super nervous. > > The one thing I figured is that in the light of power outages, or > crashing virtualization hosts, you really really really need to disable > disk write caches, and this affects softupdates, journalling, asynch > file systems, just about everything. > > The fact that makes matters worse is that journalling or softupdates > allow you to mount a silently-corrupted file system, whereas the > traditional UFS/UFS2 sync/asynch mounts will fsck themselves in the > foreground, so they get fixed before the FS panics. > > So can you be sure that: > > - your driver, chip set and hard disk execute ordered writes in order, > > - your driver, chip set and hard disk actually write data to permanent > storage BEFORE acknowledging a successful write? > > Whenever I fixed these issues, I had no more corruptions. > > For ata and sata, there are loader tunables you will want to set, > hw.ata.wc=0 and kern.cam.ada.write_cache=0. > > If your drives are under ada, ad, or ahci related control, try these > settings. For SCSI, use camcontrol to turn the write cache off. > softupdates is supposed to rectify most of the performance penalties > incurred. > > Note also that you needed to set ahci_load=YES and atapicam_load=YES in > 8.X, I've never bothered to check 7.X or 9.X WRT these settings. This is a bit off-topic, but I'm curious what the effect of NCQ is on softupdates? Since that too has the ability to reorder writes to disk, should it be disabled in addition to cache? Also, I would say that if you are using a hardware raid controller with a BBU, then allowing the use of controller's cache and write-back policy should be safe for use with softupdates. Any caching mechanism, for that matter, that has a separate power supply source should be ok. For example, the Intel 320 SSDs have a few on-board capacitors that are used to flush the cache in the event of a power loss. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang error make buildworld
On Wed, Dec 28, 2011 at 2:39 PM, Dimitry Andric wrote:
> On 2011-12-28 17:32, Renato Botelho wrote:
>>
>> On Wed, Dec 28, 2011 at 2:26 PM, Dimitry Andric wrote:
>
> ...
>
>>> Most likely, it is due to the way you set CC, CXX and/or CPP in
>>> make.conf. Can you please post that file?
>>
>>
>> Sure, follow my src.conf:
>>
>> .if !defined(CC) || ${CC} == "cc"
>> CC=clang
>> .endif
>> .if !defined(CXX) || ${CXX} == "c++"
>> CXX=clang++
>> .endif
>> .if !defined(CPP) || ${CPP} == "cpp"
>> CPP=clang-cpp
>> .endif
>
>
> This part should go into make.conf, *not* src.conf. If you want to use
> clang only for src, not for anything else, put:
>
> .if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*}
> # [... set CC, etc here... ]
>
> .endif
>
>
>> # Don't die on warnings
>> NO_WERROR=
>> WERROR=
>> # Don't forget this when using Jails!
>> NO_FSCHG=
>
>
> This is fine to have in src.conf.
Worked like a charm. Thanks!!
--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J systems do not fsck themselves
Am 27.12.2011 22:53, schrieb David Thiel: > I've had multiple machines now (9.0-RC3, amd64, i386 and earlier > 9-CURRENT on ppc) running SU+J that have had unexplained panics and > crashes start happening relating to disk I/O. When I end up running a > full fsck, it keeps turning out that the disk is dirty and corrupted, > but no mechanism is in place with SU+J to detect and fix this. A bgfsck > never happens, but a manual fsck in single-user does indeed fix the > crashing and weird behavior. Others have tested their SU+J volumes and > found them to have errors as well. This makes me super nervous. The one thing I figured is that in the light of power outages, or crashing virtualization hosts, you really really really need to disable disk write caches, and this affects softupdates, journalling, asynch file systems, just about everything. The fact that makes matters worse is that journalling or softupdates allow you to mount a silently-corrupted file system, whereas the traditional UFS/UFS2 sync/asynch mounts will fsck themselves in the foreground, so they get fixed before the FS panics. So can you be sure that: - your driver, chip set and hard disk execute ordered writes in order, - your driver, chip set and hard disk actually write data to permanent storage BEFORE acknowledging a successful write? Whenever I fixed these issues, I had no more corruptions. For ata and sata, there are loader tunables you will want to set, hw.ata.wc=0 and kern.cam.ada.write_cache=0. If your drives are under ada, ad, or ahci related control, try these settings. For SCSI, use camcontrol to turn the write cache off. softupdates is supposed to rectify most of the performance penalties incurred. Note also that you needed to set ahci_load=YES and atapicam_load=YES in 8.X, I've never bothered to check 7.X or 9.X WRT these settings. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang error make buildworld
On 2011-12-28 17:32, Renato Botelho wrote:
On Wed, Dec 28, 2011 at 2:26 PM, Dimitry Andric wrote:
...
Most likely, it is due to the way you set CC, CXX and/or CPP in
make.conf. Can you please post that file?
Sure, follow my src.conf:
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
This part should go into make.conf, *not* src.conf. If you want to use
clang only for src, not for anything else, put:
.if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*}
# [... set CC, etc here... ]
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
This is fine to have in src.conf.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang error make buildworld
On Wed, Dec 28, 2011 at 2:26 PM, Dimitry Andric wrote:
> On 2011-12-28 16:44, Renato Botelho wrote:
>>
>> On Tue, May 3, 2011 at 10:07 PM, Manfred Antar wrote:
>>>
>>> I get this error when trying to buildworld on current i386.
>>> It's been this way for awhile Any Ideas ?
>>>
>>> ===> boot/i386/boot0 (all)
>>> clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6
>>> -DCOMSPEED="7<< 5 + 3" -ffreestanding -mpreferred-stack-boundary=2
>>> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99
>>> -c /usr/src/sys/boot/i386/boot0/boot0.S
>>> clang: warning: argument unused during compilation:
>>> '-mpreferred-stack-boundary=2'
>>> /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet
>>> .code16 # This runs in real mode
>>> ^
>
>
> This is expected, since the above command line is supposed to have
> '-no-integrated-as' added. For some reason, the test for clang in
> sys/boot/i386/boot0/Makefile is not working as it should.
>
> Most likely, it is due to the way you set CC, CXX and/or CPP in
> make.conf. Can you please post that file?
Sure, follow my src.conf:
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
and my make.conf
KERNCONF=MURPHYS
WITH_OPTIONS=yes
WITH_VIM_OPTIONS=yes
WITHOUT_X11=yes
# added by use.perl 2011-12-12 13:19:26
PERL_VERSION=5.12.4
More information about the system installed on this machine:
garga@murphys:~> uname -a
FreeBSD murphys.ramenzoni.com.br 9.0-RC3 FreeBSD 9.0-RC3 #0: Sun Dec
4 08:01:02 UTC 2011
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
garga@murphys:~> clang -v
FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
Target: i386-unknown-freebsd9.0
Thread model: posix
--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang error make buildworld
On 2011-12-28 16:44, Renato Botelho wrote: On Tue, May 3, 2011 at 10:07 PM, Manfred Antar wrote: I get this error when trying to buildworld on current i386. It's been this way for awhile Any Ideas ? ===> boot/i386/boot0 (all) clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 -DCOMSPEED="7<< 5 + 3" -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99-c /usr/src/sys/boot/i386/boot0/boot0.S clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet .code16 # This runs in real mode ^ This is expected, since the above command line is supposed to have '-no-integrated-as' added. For some reason, the test for clang in sys/boot/i386/boot0/Makefile is not working as it should. Most likely, it is due to the way you set CC, CXX and/or CPP in make.conf. Can you please post that file? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Clang error make buildworld
On Tue, May 3, 2011 at 10:07 PM, Manfred Antar wrote: > I get this error when trying to buildworld on current i386. > It's been this way for awhile Any Ideas ? > > ===> boot/i386/boot0 (all) > clang -O2 -pipe -DVOLUME_SERIAL -DPXE -DFLAGS=0x8f -DTICKS=0xb6 > -DCOMSPEED="7 << 5 + 3" -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c > /usr/src/sys/boot/i386/boot0/boot0.S > clang: warning: argument unused during compilation: > '-mpreferred-stack-boundary=2' > /tmp/cc-4SXZt8.s:42:11: error: .code16 not supported yet > .code16 # This runs in real mode > ^ > /tmp/cc-4SXZt8.s:313:3: error: unknown use of instruction mnemonic without a > size suffix > jmp *%bx # Invoke bootstrap > ^ > /tmp/cc-4SXZt8.s:346:3: error: invalid operand for instruction > retw # To caller > ^ > /tmp/cc-4SXZt8.s:372:3: error: invalid operand for instruction > retw # To caller > ^ > *** Error code 1 > > Stop in /usr/src/sys/boot/i386/boot0. > *** Error code 1 > > Stop in /usr/src/sys/boot/i386. > *** Error code 1 > > Stop in /usr/src/sys/boot. > *** Error code 1 > > Stop in /usr/src/sys. Hello Manfred, I'm having this same issue on a i386 HEAD buildworld with clang. Did you find a fix for this? For now i built boot0 with gcc and it was built fine. Regards -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
Am 12/28/11 16:57, schrieb Dimitry Andric:
> On 2011-12-28 11:48, O. Hartmann wrote:
> ...
>> /usr/local/bin/ld:
>> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
>>
>> relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
>> can not be used when making a shared object; recompile with -fPIC
>> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
>>
>> could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>
> What happens if you compile and link the following simple program with
> g++46:
>
> #include
>
> int main(void)
> {
> std::cout << "Hello World!" << std::endl;
> return 0;
> }
>
> Does it fail with the same type of link error, e.g. linking to the
> libstdc++.a instead libstdc++.so? It would be nice if you can add -v to
> the command line, and paste the output here.
>
> I suspect your g++46 port is busted, for some reason.
It works fine:
ohartmann@telesto: [~] g++46 -v -o muff muff.cpp
Using built-in specs.
COLLECT_GCC=g++46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/lto-wrapper
Target: x86_64-portbld-freebsd9.0
Configured with: ./../gcc-4.6-20111209/configure --disable-nls
--enable-languages=c,c++,objc,fortran --libdir=/usr/local/lib/gcc46
--libexecdir=/usr/local/libexec/gcc46 --program-suffix=46
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc46
--build=x86_64-portbld-freebsd9.0
Thread model: posix
gcc version 4.6.3 20111209 (prerelease) (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/cc1plus
-quiet -v muff.cpp -quiet -dumpbase muff.cpp -mtune=generic
-march=x86-64 -auxbase muff -version -o /var/tmp//ccu1eDPY.s
GNU C++ (FreeBSD Ports Collection) version 4.6.3 20111209 (prerelease)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.6.3 20111209 (prerelease), GMP
version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc46/include/c++/
/usr/local/lib/gcc46/include/c++//x86_64-portbld-freebsd9.0
/usr/local/lib/gcc46/include/c++//backward
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/include
/usr/local/include
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/include-fixed
/usr/include
End of search list.
GNU C++ (FreeBSD Ports Collection) version 4.6.3 20111209 (prerelease)
(x86_64-portbld-freebsd9.0)
compiled by GNU C version 4.6.3 20111209 (prerelease), GMP
version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1f5bea4d4b089362b811317a91015e20
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/bin/as -v -o /var/tmp//ccblbg7V.o /var/tmp//ccu1eDPY.s
GNU assembler version 2.22 (x86_64-portbld-freebsd9.0) using BFD version
(GNU Binutils) 2.22
COMPILER_PATH=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/bin/
LIBRARY_PATH=/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/lib/:/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'muff' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/collect2
--eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o muff
/usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtbegin.o
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../../../x86_64-portbld-freebsd9.0/lib
-L/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../..
/var/tmp//ccblbg7V.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtend.o
/usr/lib/crtn.o
GNU ld (GNU Binutils) 2.22
Supported emulations:
elf_x8
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On 2011-12-28 11:48, O. Hartmann wrote:
...
/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
What happens if you compile and link the following simple program with
g++46:
#include
int main(void)
{
std::cout << "Hello World!" << std::endl;
return 0;
}
Does it fail with the same type of link error, e.g. linking to the
libstdc++.a instead libstdc++.so? It would be nice if you can add -v to
the command line, and paste the output here.
I suspect your g++46 port is busted, for some reason.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linuxulator (was: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server)
Am 12/28/11 15:24, schrieb Alexander Leidinger: > > Hi, > > you assume in your comment that development time "wasted" in the > linuxulator is time lost for other development. This assumption could be > valid for a commercially developed OS, but is wrong for FreeBSD. I tell > this as a person who spend a lot of time with the linux ports, mentored > a GSoC student who worked on the linuxulator and also put some time into > the kernel parts. That wasn't ment to be any offense! And shortly after I wrote this, i remembered myself that many stuff from JAVA is still completely not open due to Linux-shielded/protected stuff. Even commercial companies like DeLL seem to be incabale of offering JAVA apllets which are compatible to all platforms. I tried hard on geting their iDRAC6 stuff running on FreeBSD and recent firefox or even with diablo-jdk as a standalone JAVA application, but it lacks obviously some functionality only available in Linux firefox and/or JAVA. > > The use case for it is: run linux programs which are not available with > source or where "we" are not able to get it compiled on FreeBSD with a > reasonable effort. As a data point, "we" managed in the past to take the > closed source linux version of the Intel C/C++ compiler and manipulate > it in a way to run in the linuxulator but produce FreeBSD binaries. I > got reports that it was used in some HPC scenarios. Yes, you're right. We also used the Intel C and Fortran compiler to run a lot of scientifc programs on some boxes, but noadays, most software, especially scientific one, is 64bit since we deal with huge datasets which need a lot of memory and/or are happy having no memory limitations doing n-body simulations. But this is times ago. I'm sure there are still applications running 32bit, but the benefit of having 64bit and so a native 64bit compiler is quite huge. > > Wasn't it you who asked if there's a way to run CUDA on FreeBSD? > Pessimistic but interested souls would not wait until there is maybe > some result from open sourcing the nvidia compiler and instead either > try to get something similar up and running, or to get a 64 bit version > of the linuxulator. The later one may be more beneficial for more > people, and may even more easy as the parts are open source and there's > even some code somewhere in a VCS (maybe in perforce). Yes, it was me who asked for a 32Bit CUDA solution, because I desperately needed OpenCL/CUDA. And I asked because I wouldn't like to leave my FreeBSD platform for achiving this, but I do not have any chance. I tried to get the CUDA stuff working on FreeBSD, but it would take me ages to fullfill and at the end I need a development environment. The BLOG mentioned and referred to achive this is quite old and outdated and also stated that one need either a full Linux installation (Gentoo) or an development box. Well, having a development box menas also having a full working Linux that could be 64bit and running my applications. It is now that way. We use Suse 11 and Ubuntu 10 boxes with TESLA boards from nVidia and I have to compile my stuff and run it on those boxes. I also administer one of such boxes and I must confress, that I'm not happy with that. For once, it might be a personal thing, on the other hand I feel lost on such cryptographic and shell-polluted administrative environments, which could only be administered by special scripted tools - and each Linux distribution seems to have its own, holy and mystical way to encrypt former clean administrative ways to do. Days ago nVidia and AMD claimed to have opened their OpenCL intermediate language/representation and and nVidia claims to have opensourced their compiler. But althought requested being "member" of the elite group of people having access to that piece of software, I did not get access to it. So, it seems not to be real opensourced. But I think this might be a topic of another thread, which would be very interesting to me to discuss, since I'm not that familiar with what is possible in FreeBSD and what not. I see that, from the theoretical perspective of how LLVM works, their could be a chance to get FreeBSD on par with Linux in GPGPU concerned applications, which becomes very, very important now. > > Bye, > Alexander. Regards, Oliver > > -- > Send via an Android device, please forgive brevity and typographic and > spelling errors. > > > "O. Hartmann" hat geschrieben: > On 12/23/11 12:44, Alexander Best wrote: > [...] >>> Many suggested that the Linux binaries be run via the FreeBSD Linux >>> emulation. Unchanged. >>> There is one problem here though, the emulation is still 32 bit. >> >> plus the current emulation layer is far from complete. a lot of stuff > hasn't >> been implemented yet (meaning it's missing or implemented as dummy code). >> >> try running recent firefox linux binaries on freebsd. they will all crash >> almost instantly. >> >> cheers. >> alex >> > > [...] > > Sometimes I'm glad to have the Linuxulator, for
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote: > Am 12/28/11 14:58, schrieb Kostik Belousov: > > On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: > >> Hello out here. > >> > >> I run into a problem since one of the last portupdates and I do not know > >> whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 > >> AMD64. > >> > >> Background: > >> We use a scientific graphical toolset for planetary research called > >> ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD > >> 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a > >> couple of weeks ago. > >> On all of my boxes, I do frequently a portupgrade, so I saw binutils got > >> bumped up and gcc 4.6 is also getting really frequently changed these days. > >> After a some portupdates within the last weeks, I just decided to > >> compile ISIS3 again to keep it "fresh and on track", but it won't > >> compile anymore. > >> > >> On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and > >> CLANG built) I receive in some subfolders containing sources the > >> follwoing error: > >> > >> [...] > >> Adding API object [UniqueIOCachingAlgorithm] > >> Adding API object [UniversalGroundMap] > >> Adding API object [UserInterface] > >> Adding API object [VariableLineScanCameraDetectorMap] > >> Adding API object [VecFilter] > >> Adding API object [WorldMapper] > >> Adding API object [iException] > >> Adding API object [iString] > >> Adding API object [iTime] > >> Working on Package [mex] (11:30:15) > >> Adding API object [HrscCamera] > >> /usr/local/bin/ld: > >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): > >> relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' > >> can not be used when making a shared object; recompile with -fPIC > >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: > >> could not read symbols: Bad value > >> collect2: ld returned 1 exit status > >> gmake[5]: *** [plugin] Error 1 > >> cp: libHrscCamera.so: No such file or directory > >> gmake[4]: *** [install] Error 1 > > The error is completely clear as it is: the build tries to link static > > library libstdc++.so into shared object. This is not supported. > > Thanks, Kostik, for the fast response. > The error isn't so clear to me, sorry. I thought libstdc++.a is the > static library and it is taken to be referenced/compiled into a shared Linked in. > object created by the application I try to compile. Right, and this is not supported. Code linked into shared object must be compiled PIC. An .a library usually does not contain objects compiled by PIC, ld just dutifully reported back. > > I'm much more confused now, since I thought the last time I compiled > that piece of software, I never got any error like that. Well, clang > fails with some obscure errors on the code itself and I'm unwilling to > correct them, I'll try the legacy gcc 4.2.1 and will report what's > happening. It might have worked by accident (because libstdc++.a objects referenced during the link did not carried unsupported relocations), or, much more likely, the build system has changed and started doing stupid things. It must not link static libraries into shared objects. You should examine why it does this, and fix it. Changing compilers is just wasting a time. pgpkHA6aHIGk1.pgp Description: PGP signature
Linuxulator (was: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server)
Hi, you assume in your comment that development time "wasted" in the linuxulator is time lost for other development. This assumption could be valid for a commercially developed OS, but is wrong for FreeBSD. I tell this as a person who spend a lot of time with the linux ports, mentored a GSoC student who worked on the linuxulator and also put some time into the kernel parts. The use case for it is: run linux programs which are not available with source or where "we" are not able to get it compiled on FreeBSD with a reasonable effort. As a data point, "we" managed in the past to take the closed source linux version of the Intel C/C++ compiler and manipulate it in a way to run in the linuxulator but produce FreeBSD binaries. I got reports that it was used in some HPC scenarios. Wasn't it you who asked if there's a way to run CUDA on FreeBSD? Pessimistic but interested souls would not wait until there is maybe some result from open sourcing the nvidia compiler and instead either try to get something similar up and running, or to get a 64 bit version of the linuxulator. The later one may be more beneficial for more people, and may even more easy as the parts are open source and there's even some code somewhere in a VCS (maybe in perforce). Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. "O. Hartmann" hat geschrieben:On 12/23/11 12:44, Alexander Best wrote: [...] >> Many suggested that the Linux binaries be run via the FreeBSD Linux >> emulation. Unchanged. >> There is one problem here though, the emulation is still 32 bit. > > plus the current emulation layer is far from complete. a lot of stuff hasn't > been implemented yet (meaning it's missing or implemented as dummy code). > > try running recent firefox linux binaries on freebsd. they will all crash > almost instantly. > > cheers. > alex > [...] Sometimes I'm glad to have the Linuxulator, for instance using Mathematica or an older 32bit IDL or even MATLAB. But lately, I run into problems on more recent platforms like FreeBSD 9 and 10. There maybe serious reasons having the Linuxulator, i do not know. But if not, why spending rare developer resources on that? As far as I'm concerned, the only real reason having the Linuxulator is some stuff from Adobe for desktop systems, Flash. That's it. For the scientific stuff, I try to move my people towards OpenSource, since we do "standard" stuff and I expect students and scientists solving problems without fancy coloured clicky funny things. In "production", this might be another point of view. SciLab from INRIA is great, MuPAD, MAXIMA also. But is there a real need running the Linux binary of Forefox on FreeBSD? Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
Am 12/28/11 14:58, schrieb Kostik Belousov: > On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: >> Hello out here. >> >> I run into a problem since one of the last portupdates and I do not know >> whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 >> AMD64. >> >> Background: >> We use a scientific graphical toolset for planetary research called >> ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD >> 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a >> couple of weeks ago. >> On all of my boxes, I do frequently a portupgrade, so I saw binutils got >> bumped up and gcc 4.6 is also getting really frequently changed these days. >> After a some portupdates within the last weeks, I just decided to >> compile ISIS3 again to keep it "fresh and on track", but it won't >> compile anymore. >> >> On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and >> CLANG built) I receive in some subfolders containing sources the >> follwoing error: >> >> [...] >> Adding API object [UniqueIOCachingAlgorithm] >> Adding API object [UniversalGroundMap] >> Adding API object [UserInterface] >> Adding API object [VariableLineScanCameraDetectorMap] >> Adding API object [VecFilter] >> Adding API object [WorldMapper] >> Adding API object [iException] >> Adding API object [iString] >> Adding API object [iTime] >> Working on Package [mex] (11:30:15) >> Adding API object [HrscCamera] >> /usr/local/bin/ld: >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): >> relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' >> can not be used when making a shared object; recompile with -fPIC >> /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: >> could not read symbols: Bad value >> collect2: ld returned 1 exit status >> gmake[5]: *** [plugin] Error 1 >> cp: libHrscCamera.so: No such file or directory >> gmake[4]: *** [install] Error 1 > The error is completely clear as it is: the build tries to link static > library libstdc++.so into shared object. This is not supported. Thanks, Kostik, for the fast response. The error isn't so clear to me, sorry. I thought libstdc++.a is the static library and it is taken to be referenced/compiled into a shared object created by the application I try to compile. I'm much more confused now, since I thought the last time I compiled that piece of software, I never got any error like that. Well, clang fails with some obscure errors on the code itself and I'm unwilling to correct them, I'll try the legacy gcc 4.2.1 and will report what's happening. Thank you very much, Oliver signature.asc Description: OpenPGP digital signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote: > Hello out here. > > I run into a problem since one of the last portupdates and I do not know > whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 > AMD64. > > Background: > We use a scientific graphical toolset for planetary research called > ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD > 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a > couple of weeks ago. > On all of my boxes, I do frequently a portupgrade, so I saw binutils got > bumped up and gcc 4.6 is also getting really frequently changed these days. > After a some portupdates within the last weeks, I just decided to > compile ISIS3 again to keep it "fresh and on track", but it won't > compile anymore. > > On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and > CLANG built) I receive in some subfolders containing sources the > follwoing error: > > [...] > Adding API object [UniqueIOCachingAlgorithm] > Adding API object [UniversalGroundMap] > Adding API object [UserInterface] > Adding API object [VariableLineScanCameraDetectorMap] > Adding API object [VecFilter] > Adding API object [WorldMapper] > Adding API object [iException] > Adding API object [iString] > Adding API object [iTime] > Working on Package [mex] (11:30:15) > Adding API object [HrscCamera] > /usr/local/bin/ld: > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): > relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' > can not be used when making a shared object; recompile with -fPIC > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: > could not read symbols: Bad value > collect2: ld returned 1 exit status > gmake[5]: *** [plugin] Error 1 > cp: libHrscCamera.so: No such file or directory > gmake[4]: *** [install] Error 1 The error is completely clear as it is: the build tries to link static library libstdc++.so into shared object. This is not supported. pgpqYjyBtTIwA.pgp Description: PGP signature
Re: Removal of sysinstall from HEAD and lack of a post-install configuration tool
On 28/12/2011 06:30, Doug Barton wrote: > On 12/27/2011 22:08, Adrian Chadd wrote: >> Hi, >> >> Why not just list the things that sysinstall did that people like, and >> extract out / reimplement those bits? > That's sounds great. As soon as that's done, we can remove sysinstall > from the base. Until those things exist, removing it is premature. > In that case can I suggest a wiki page or other viewable/editable list of desirable features from sysinstall? I only used it for the basic disklayout and component install so I'm not in a position to start it off or I would. Vince ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
Hello out here. I run into a problem since one of the last portupdates and I do not know whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0 AMD64. Background: We use a scientific graphical toolset for planetary research called ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD 8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a couple of weeks ago. On all of my boxes, I do frequently a portupgrade, so I saw binutils got bumped up and gcc 4.6 is also getting really frequently changed these days. After a some portupdates within the last weeks, I just decided to compile ISIS3 again to keep it "fresh and on track", but it won't compile anymore. On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and CLANG built) I receive in some subfolders containing sources the follwoing error: [...] Adding API object [UniqueIOCachingAlgorithm] Adding API object [UniversalGroundMap] Adding API object [UserInterface] Adding API object [VariableLineScanCameraDetectorMap] Adding API object [VecFilter] Adding API object [WorldMapper] Adding API object [iException] Adding API object [iString] Adding API object [iTime] Working on Package [mex] (11:30:15) Adding API object [HrscCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libHrscCamera.so: No such file or directory gmake[4]: *** [install] Error 1 Working on Package [control] (11:30:15) Adding API object [BundleAdjust] Adding API object [ControlCubeGraphNode] Adding API object [ControlGraph] Adding API object [ControlMeasure] Adding API object [ControlMeasureLogData] Adding API object [ControlNet] Adding API object [ControlNetFilter] Adding API object [ControlNetStatistics] Adding API object [ControlNetValidMeasure] Adding API object [ControlNetVersioner] Adding API object [ControlPoint] Adding API object [ControlPointList] Adding API object [InterestOperator] Adding API object [InterestOperatorFactory] Working on Package [lro] (11:30:22) Adding API object [LroNarrowAngleCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libLroNarrowAngleCamera.so: No such file or directory gmake[4]: *** [install] Error 1 Adding API object [LroWideAngleCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libLroWideAngleCamera.so: No such file or directory gmake[4]: *** [install] Error 1 Adding API object [MiniRF] [...] Working on Package [system] (11:30:32) Adding API object [KernelDb] Working on Package [viking] (11:30:33) Adding API object [VikingCamera] /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(ios_init.o): relocation R_X86_64_32 against `std::cout' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[5]: *** [plugin] Error 1 cp: libVikingCamera.so: No such file or directory gmake[4]: *** [install] Error 1 Working on Package [rolo] (11:30:33) Finished adding API objects Creating Shared Libraries ... /usr/local/bin/ld: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(ctype.o): relocation R_X86_64_32S against `vtable for std::ctype' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status gmake[1]: *** [libisis3.3.0.so] Error 1 gmake: *** [api] Error 2 *** Error code 1 Stop in /usr/ports/science/isis3. #>: I try to figure out what changed in the Mk-framework causing this problem recently, since the code compiled weeks ago on 9.0-PRE and 10.0
Re: license question w.r.t. NFSv4.1 Layout drivers - calling all amateur lawyers
On Mon, 26 Dec 2011 22:42:36 -0500 (EST)
Rick Macklem wrote:
> First off, I had no idea which mailing list would be appropriate
> for this, so apologies in advance if I chose the wrong one.
>
> For NFSv4.1 pNFS, there are layout drivers in Linux that I would
> like to reuse for the FreeBSD client. (Re-writing these drivers
> from scratch would be a lot of work and difficult to maintain. The
> Linux drivers are being actively developed with the assistance of
> server vendors.)
>
> Two of these drivers carry a University of Michigan copyright notice
> which looks pretty liberal to me. (Rather similar to MIT's copyright.)
> I realize it would have to be approved by core@, but I think it could
> be. (The 3rd is GPLv2'd, but that one doesn't concern me at this time.
> I believe that Panasas might be able to release the code for this one
> under a different license, but haven't explored this as of yet.)
>
> However, there is a catch...
> After the copyright notice on the .c files, but not the .h files,
> there is also this:
>
> MODULE_LICENSE("GPL");
>
> and in linux/module.h, there is the following for the above:
> /*
> * The following license idents are currently accepted as indicating free
> * software modules
> *
> *"GPL" [GNU Public License v2 or later]
> *"GPL v2"[GNU Public License v2]
> *"GPL and additional rights" [GNU Public License v2 rights and more]
> *"Dual BSD/GPL" [GNU Public License v2
> * or BSD license choice]
> *"Dual MIT/GPL" [GNU Public License v2
> * or MIT license choice]
> *"Dual MPL/GPL" [GNU Public License v2
> * or Mozilla license choice]
> *
> * The following other idents are available
> *
> *"Proprietary" [Non free products]
> *
> * There are dual licensed components, but when running with Linux it is the
> * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> * is a GPL combined work.
> *
> * This exists for several reasons
> * 1. So modinfo can show license info for users wanting to vet their setup
> *is free
> * 2. So the community can ignore bug reports including proprietary modules
> * 3. So vendors can do likewise based on their own policies
> */
> #define MODULE_LICENSE(_license) MODULE_INFO(license, _license)
>
> Now, from what little I know, this does not imply that the .c file is GPL'd,
> since it doesn't have any GPL copyright notice in the file, nor does it
> #include
> one via MODULE_LICENSE().
>
> Does anyone happen to know if I am correct or how to confirm this?
>
> Thanks in advance for any help with this, rick
> ps: Here's what's on the .c file, in case you're interested. The .h
> files just have what is in the comment.
> /*
> * Module for the pnfs nfs4 file layout driver.
> * Defines all I/O and Policy interface operations, plus code
> * to register itself with the pNFS client.
> *
> * Copyright (c) 2002
> * The Regents of the University of Michigan
> * All Rights Reserved
> *
> * Dean Hildebrand
> *
> * Permission is granted to use, copy, create derivative works, and
> * redistribute this software and such derivative works for any purpose,
> * so long as the name of the University of Michigan is not used in
> * any advertising or publicity pertaining to the use or distribution
> * of this software without specific, written prior authorization. If
> * the above copyright notice or any other identification of the
> * University of Michigan is included in any copy of any portion of
> * this software, then the disclaimer below must also be included.
> *
> * This software is provided as is, without representation or warranty
> * of any kind either express or implied, including without limitation
> * the implied warranties of merchantability, fitness for a particular
> * purpose, or noninfringement. The Regents of the University of
> * Michigan shall not be liable for any damages, including special,
> * indirect, incidental, or consequential damages, with respect to any
> * claim arising out of or in connection with the use of the software,
> * even if it has been or is hereafter advised of the possibility of
> * such damages.
> */
>
> #include
> #include
> #include
>
> #include "internal.h"
> #include "nfs4filelayout.h"
>
> #define NFSDBG_FACILITY NFSDBG_PNFS_LD
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Dean Hildebrand ");
> MODULE_DESCRIPTION("The NFSv4 file layout driver");
>
IANAL but IMO the university copyriught notice takes precedence over
the MODULE_LICENSE(), which is basically there so that the in-kernel
linker won't brand the result of loading this module as "tainted."
This is based on 10 years of doing embedded Linux work and encountering
this "problem" mysel
