Hasso Tepper wrote:-
> Neil Booth wrote:
> > But why do I need this link? What is at fault here? It seems to be
> > coming from libtool, but I'm curious why apparently no-one else sees
> > this, and I have no idea how to fix libtool.
>
> Rebuild the devel/libtool-base package.
Hasso - thanks,
Neil Booth wrote:
> But why do I need this link? What is at fault here? It seems to be
> coming from libtool, but I'm curious why apparently no-one else sees
> this, and I have no idea how to fix libtool.
Rebuild the devel/libtool-base package.
--
Hasso Tepper
Several (but not all) pkgsrc C++ packages aren't linking on my
machine. I've rebuilt and installed the world, as well as libtool.
For example, here's graphics/tiff:
/bin/sh ../libtool --tag=CXX --mode=link c++ -O2 -I/usr/include
-I/usr/pkg/include -L/usr/lib -Wl,-R/usr/lib
On Wed, Nov 12, 2008 at 12:54:28PM +0100, dark0s Optik wrote:
> Where is defined getline C function in DragonFlyBSD ?
There is no getline function in C. There is fgets and the more useful,
but less portable fgetln.
Joerg
Where is defined getline C function in DragonFlyBSD ?
"walt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm trying to debug a problem in /boot/loader but I'm stumped by
> this line in sys/boot/common/module.c:
>
> error = (file_formats[i]->l_load)(filename, loadaddr, &fp);
>
> This seems to refer to a line in common/bootstrap.h:
>
:I'm trying to debug a problem in /boot/loader but I'm stumped by
:this line in sys/boot/common/module.c:
:
:error = (file_formats[i]->l_load)(filename, loadaddr, &fp);
:
:This seems to refer to a line in common/bootstrap.h:
:
:int (* l_load)(char *filename, u_int64_t dest, struct preloaded_file *
I'm trying to debug a problem in /boot/loader but I'm stumped by
this line in sys/boot/common/module.c:
error = (file_formats[i]->l_load)(filename, loadaddr, &fp);
This seems to refer to a line in common/bootstrap.h:
int (* l_load)(char *filename, u_int64_t dest, struct preloaded_file **result);
LOL...
Well The whole team was crawling under the tables for half an hour...
:)
2007/6/23, walt <[EMAIL PROTECTED]>:
The C Programming Language -- A language which combines the
flexibility and power of assembly language with the readability
of assembly language.
--
Dennis Melentyev
The C Programming Language -- A language which combines the
flexibility and power of assembly language with the readability
of assembly language.
Sascha Wildner wrote:
> Justin C. Sherrill wrote:
>> On Fri, June 1, 2007 3:52 pm, Sascha Wildner wrote:
>>
>>> So... I'm kinda unsure here if the perspective of being able to remove
>>> C++ from the build justifies reverting to the old mdoc mac
Justin C. Sherrill wrote:
On Fri, June 1, 2007 3:52 pm, Sascha Wildner wrote:
So... I'm kinda unsure here if the perspective of being able to remove
C++ from the build justifies reverting to the old mdoc macros. What do
the rest of you think?
Would there be any quantifiable benefit gr
On Fri, June 1, 2007 3:52 pm, Sascha Wildner wrote:
> So... I'm kinda unsure here if the perspective of being able to remove
> C++ from the build justifies reverting to the old mdoc macros. What do
> the rest of you think?
Would there be any quantifiable benefit greater than the in
Chris Turner wrote:
Simon corecode Schubert wrote:
However, there won't be any C++ in the list of things to do. The only thing
which uses C++ in DragonFly is groff, and I would be happier without this.
was just thinking about this issue - any thoughts about:
Sascha Wildner wrote:
>
> Hmm, looks interesting. I'll play with it...
>
> Sascha
>
p.s:
just discovered the 'utlities' portions are in pkgsrc-wip,
but the 'documentation tools' don't appear to be.
Chris Turner wrote:
Simon corecode Schubert wrote:
However, there won't be any C++ in the list of things to do. The only thing
which uses C++ in DragonFly is groff, and I would be happier without this.
was just thinking about this issue - any thoughts about:
Simon corecode Schubert wrote:
>
> However, there won't be any C++ in the list of things to do. The only thing
> which uses C++ in DragonFly is groff, and I would be happier without this.
>
was just thinking about this issue - any thoughts about:
http://heirloo
On Thu, 18 Jan 2007, Sepherosa Ziehau wrote:
> On 1/18/07, walt <[EMAIL PROTECTED]> wrote:
> > My problem is with pkgsrc/sysutils/fam:
> >
> > Listener.o(.text+0x80): In function `Listener::Listener(bool, bool, unsigned
> > long, unsigned long)':
> > : undefined reference to `socket(int, int, int
On 1/18/07, walt <[EMAIL PROTECTED]> wrote:
I just updated my -CURRENT machine, so lots of things have changed,
and I normally have trouble debugging linker errors anyway :o(
My problem is with pkgsrc/sysutils/fam:
Listener.o(.text+0x80): In function `Listener::Listener(bool, bool, unsigned
lon
I just updated my -CURRENT machine, so lots of things have changed,
and I normally have trouble debugging linker errors anyway :o(
My problem is with pkgsrc/sysutils/fam:
Listener.o(.text+0x80): In function `Listener::Listener(bool, bool, unsigned
long, unsigned long)':
: undefined reference to `
Am 19.12.2006 um 11:41 schrieb Miguel Sousa Filipe:
Hi,
Hello,
On 12/18/06, walt <[EMAIL PROTECTED]> wrote:
(...)
a header file 'include' a source file before, so I didn't even
look at
(...)
Is this practice specific to c++ ? (If you know of any examples
> ...mtasker.hh which includes mtasker.cc. ...
The source of my confusion becomes clear! I don't recall ever seeing
a header file 'include' a source file before, so I didn't even look at
the code.
Is this practice specific to c++ ? (If you know of any examples of c
code doi
urce of my confusion becomes clear! I don't recall ever seeing
a header file 'include' a source file before, so I didn't even look at
the code.
Is this practice specific to c++ ? (If you know of any examples of c
code doing this, please point them out. Thanks!)
Simon 'corecode' Schubert wrote:
> Joerg Sonnenberger wrote:
>> On Thu, Dec 14, 2006 at 01:34:04AM +0100, Simon 'corecode' Schubert
>> wrote:
>>> the problem here basically is an incomprehensible error message which
>>> translates to:
>>>
>>> "no declaration for swapcontext()!!1"
>> Wrong.
> than
Joerg Sonnenberger wrote:
On Thu, Dec 14, 2006 at 01:34:04AM +0100, Simon 'corecode' Schubert wrote:
the problem here basically is an incomprehensible error message which
translates to:
"no declaration for swapcontext()!!1"
Wrong.
thanks for your explanation, but i think you're missing som
On Thu, Dec 14, 2006 at 01:34:04AM +0100, Simon 'corecode' Schubert wrote:
> the problem here basically is an incomprehensible error message which
> translates to:
>
> "no declaration for swapcontext()!!1"
Wrong.
Joerg
walt wrote:
c++ -O2 -I/usr/pkg/include -I/usr/include -Wall -O3 -I/usr/pkg/include
-I/usr/include -c -o syncres.o syncres.cc
In file included from mtasker.hh:107,
from syncres.hh:20,
from syncres.cc:20:
mtasker.cc: In member function `void MTasker::yield
On Wed, Dec 13, 2006 at 07:48:38AM -0800, walt wrote:
> In response to a post by Petr, I decided to take a stab at fixing
> pkgsrc/wip/powerdns-recursor.
>
> I was able to fix a few obvious #ifdefs, but I'm still getting this
> c++ error (which doesn't happen in NetBSD)
On Wed, Dec 13, 2006 at 07:48:38AM -0800, walt wrote:
> c++ -O2 -I/usr/pkg/include -I/usr/include -Wall -O3 -I/usr/pkg/include
> -I/usr/include -c -o syncres.o syncres.cc
> In file included from mtasker.hh:107,
> from syncres.hh:20,
> fro
In response to a post by Petr, I decided to take a stab at fixing
pkgsrc/wip/powerdns-recursor.
I was able to fix a few obvious #ifdefs, but I'm still getting this
c++ error (which doesn't happen in NetBSD):
c++ -O2 -I/usr/pkg/include -I/usr/include -Wall -O3 -I/usr/pkg/include
-I/u
Am Sonntag, 26. November 2006 13:31 schrieb Saverio Iacovelli:
> Hi all, I would to know a graphical framework wich I
> can find in Pkgsrc to develop in C/C++.
>
Qt from Trolltech, for example, is in pkgsrc. GTK(2) is there, too.
Thomas
Saverio Iacovelli wrote:
Hi all, I would to know a graphical framework wich I
can find in Pkgsrc to develop in C/C++.
Anjuta? It is GNOME-based, though.
Hi all, I would to know a graphical framework wich I
can find in Pkgsrc to develop in C/C++.
Regards,
Saverio
__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto
spazio gratuito per i tuoi file e i
:What I see in linux is that the two values are miles apart,
:but in *BSD they differ by only a few bytes. I *assume* this
:means that in *BSD, t is pointing to a valid memory location
:very close to d, whereas in linux t is pointing to some
:random number. Does this seem a reasonable idea?
:
:T
On 2006-06-01 17:21, walt wrote:
Simon 'corecode' Schubert wrote:
On 31.05.2006, at 20:37, [EMAIL PROTECTED] wrote:
Style 1:
time_t t*;
time(t);
[...]
Also, style 1 is technically "incorrect" since you never allocated the
memory that t is pointing to before passing it into time().
maybe t
Simon 'corecode' Schubert wrote:
> On 31.05.2006, at 20:37, [EMAIL PROTECTED] wrote:
>>> Style 1:
>>> time_t t*;
>>> time(t);
[...]
>> Also, style 1 is technically "incorrect" since you never allocated the
>> memory that t is pointing to before passing it into time().
> maybe the compiler on BSD
On May 31, 2006, at 5:01 PM, Simon 'corecode' Schubert wrote:
I can not agree with this. BSD malloc() (or better: free()) is
much more conservative, and lately our default even changed to
abort on double free()s. A lot of buggy software has double free()
s and I think glibc doesn't even c
On 31.05.2006, at 20:37, [EMAIL PROTECTED] wrote:
Style 1:
time_t t*;
time(t);
My experience is that *BSD's malloc and pointer stuff is designed to
be as
safe as possible by default, and will try to fix and correct any common
mistakes you will make. The short answer is that BSD will figure out
> Hi compiler/OS gurus,
>
> Please consider this trivial fragment of c code which I've
> written in two different styles:
>
> Style 1:
> time_t t*;
> time(t);
>
> Style 2:
> time_t t;
> time(&t);
>
> My puzzle is this: on *BSD these two different
:Hi compiler/OS gurus,
:
:Please consider this trivial fragment of c code which I've
:written in two different styles:
:
:Style 1:
:time_t t*;
:time(t);
:
:Style 2:
:time_t t;
:time(&t);
:
:My puzzle is this: on *BSD these two different styles work
:identically -- but on my linux boxe
On Wed, May 31, 2006 at 12:44:07PM -0700, walt wrote:
> Hi compiler/OS gurus,
>
> Please consider this trivial fragment of c code which I've
> written in two different styles:
>
> Style 1:
> time_t t*;
> time(t);
>
> Style 2:
> time_t t;
> time(&t
Hi compiler/OS gurus,
Please consider this trivial fragment of c code which I've
written in two different styles:
Style 1:
time_t t*;
time(t);
Style 2:
time_t t;
time(&t);
My puzzle is this: on *BSD these two different styles work
identically -- but on my linux boxes Style 1 produ
Antonio Bravo wrote:
> Den Thu, 19 Jan 2006 17:08:58 +0100, skrev Erik Wikström:
>
>
>> Are you using the same version of gcc? I seem to recall that there were
>> some performance issues about C++, but that might have been gcc 4.
>>
>> Erik Wikström
>
&g
3 hours for
> > NetBSD or OpenBSD...
> > Similar thing do happen with the other c++ beasts like KDE, it takes
> > roughly more x2 time to build.Insane. I know zero about c++, but if
> > someone can point to some docs about that issue I will appreciate
> > much.Thanks
Den Thu, 19 Jan 2006 17:08:58 +0100, skrev Erik Wikström:
>
> Are you using the same version of gcc? I seem to recall that there were
> some performance issues about C++, but that might have been gcc 4.
>
> Erik Wikström
NetBSD: gcc-3.3.3, OpenBS: gcc-3.3.5
and well DragonF
On 2006-01-19 16:31, Antonio Bravo wrote:
Curious about getting documentation or tips if possible.
I have build JDK14 yesterday from pkgsrc/wip and it took more than 6
hours on a box where the same JDK is built in about 3 hours for
NetBSD or OpenBSD...
Similar thing do happen with the other c
Den Thu, 19 Jan 2006 10:23:48 -0500, skrev Justin C. Sherrill:
> On Thu, January 19, 2006 10:31 am, Antonio Bravo wrote:
>> Curious about getting documentation or tips if possible.
>>
>> I have build JDK14 yesterday from pkgsrc/wip and it took more than 6
>> hours on
Den Thu, 19 Jan 2006 10:23:48 -0500, skrev Justin C. Sherrill:
> On Thu, January 19, 2006 10:31 am, Antonio Bravo wrote:
>> Curious about getting documentation or tips if possible.
>>
>> I have build JDK14 yesterday from pkgsrc/wip and it took more than 6
>> hours on
; Similar thing do happen with the other c++ beasts like KDE, it takes
> roughly more x2 time to build.Insane.
> I know zero about c++, but if someone can point to some docs about that
> issue I will appreciate much.Thanks!
Are you using the same version of pkgsrc-wip on each mach
Curious about getting documentation or tips if possible.
I have build JDK14 yesterday from pkgsrc/wip and it took more than 6
hours on a box where the same JDK is built in about 3 hours for NetBSD or
OpenBSD...
Similar thing do happen with the other c++ beasts like KDE, it takes
roughly more x2
On Tue, January 3, 2006 11:02 am, Danial Thom said:
> IMO there is only one way to learn to program;
> get yourself a project. You'll need a reference
> book or web site, but until you try to tackle
> something fairly difficult you'll never be any
> good. During your project you'll encounter thing
The only addition: along with project you'll also need a good reviewer.Just a
person to blame you on all wrong formatting, redundancies, etc.Another good
thing is well done sources. The good place to lurk onideas and realisations.
So, rephrasing the post below, the best way is to join serious pro
--- Terry Tree <[EMAIL PROTECTED]> wrote:
> Anyone used these tapes before
> http://www.mixsoftware.com/product/cvidfn.htm ?
> I'm wondering if they are worth $299. What do
> you guys think ?
>
> --
> Terry
>
>
IMO there is only one way to learn to program;
get yourself a project. You'll ne
. For a list of good books check
out http://www.accu.org/bookreviews/public/
or ask in
http://www.accu.org/bookreviews/public/
Erik Wikström
There's an online C book: http://publications.gbdirect.co.uk/c_book
While it's not up to date with respect to C99 it's definitely not too
ba
http://www.accu.org/bookreviews/public/
Should have been alt.comp.lang.learn.c-c++
Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup
On 2006-01-02 15:28, Terry Tree wrote:
Anyone used these tapes before http://www.mixsoftware.com/product/cvidfn.htm ?
I'm wondering if they are worth $299. What do you guys think ?
My highly subjective oppinion: For the same price you'll get a couple of
high quality books and while it might b
Anyone used these tapes before http://www.mixsoftware.com/product/cvidfn.htm ?
I'm wondering if they are worth $299. What do you guys think ?
--
Terry
57 matches
Mail list logo
