Re: [solved] Re: [freebsd] pecl-imagick -> Segmentation fault: 11 (core dumped) on php -i under freebsd 7.3
Hi Alex, thanks for this even better feedback. On Tue, 2010-11-16 at 15:22 +0100, Alex Dupre wrote: > This is not the correct fix, the correct "fix" is to enable threads in > php, using the appropriate OPTION. Ok, so probably this one: LINKTHR=off (default) "Link thread lib (for threaded extensions)" -> on Is there any chance this will have other consequences (problems, incompatibilities with other php/pecl extensions) ? Or why is this off by default ? This should at least be checked when installing pecl-imagick, and I presume it will happen sometime as there is already PR about this case: http://www.freebsd.org/cgi/query-pr.cgi?pr=150996 Thanks again for your input & regards, Olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Now OK (Re: cvs commit: ports/databases/adstudio Makefile distinfo pkg-plist)
databases/adstudio, which was previously failing is OK after this commit. Thanks for fixing it! A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better, -- QAT - your friendly neighborhood Daemon, preparing a heck of an error trapping system: - "HMC and EOI?" - "Halt, Melt and Catch fire or Execute Operator Immediately." ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On 19 November 2010 20:47, Anonymous wrote:
> Eir Nym writes:
>
>> On 19 November 2010 18:32, Christian Weisgerber wrote:
>>> Eir Nym wrote:
>>>
>>> Since when? If you are missing /bin/csh, your system is defective
>>> Yes, I know there is a WITHOUT_TCSH knob. You can use this when
>>> you build a FreeBSD-based embedded system where you know you won't
>>> need csh. In no way does the existence of this knob imply that csh
>>> is optional on a standard FreeBSD system where you build ports.
>
> What are those requirements that constitute standard FreeBSD system
> capable of building ports?
>
>>>
>>
>> Ok, another example is NIS. You can turn off NIS support in your
>> system, and ports will check NIS biraries if they need them.
>
> There are more examples
>
> - openssl: WITH_OPENSSL_PORT
> - pkg_install: .if exists(...)
> - fetch: .if exists(...)
> - texinfo: by relying on PATH
>
> And rather than resurrecting shells/tcsh one can also also try
>
> BUILD_DEPENDS += ${CSH}:${PORTSDIR}/shells/44bsd-csh
>
> .if exists(/bin/csh)
> CSH ?= /bin/csh
> .else
> CSH ?= ${LOCALBASE}/bin/44bsd-csh
> .endif
>
> But some ports may assume csh is tcsh like sh is bash on linux.
>
Oh, sorry, I haven't knew if csh is in ports tree. thanks
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[Bug 2] USE_PYTHON not used in /etc/make.conf to properly alias installed Python executable
http://saya.gthc.org/bugzilla/show_bug.cgi?id=2 e...@gthcfoundation.org changed: What|Removed |Added QAContact||freebsd-ports@freebsd.org --- Comment #2 from e...@gthcfoundation.org --- test: Added freebsd-ports@freebsd.org for QA contact of this bug! -- Configure bugmail: http://saya.gthc.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
Eir Nym writes:
> On 19 November 2010 18:32, Christian Weisgerber wrote:
>> Eir Nym wrote:
>>
>>> >>> Since when? If you are missing /bin/csh, your system is defective
>>> >>> or at least nonstandard.
>>> >>
>>> >> It is good joke, thanks
>>> >
>>> > I guess he's talking about the ports tree being too fragile for some
>>> > non-default configurations and not many people are willing to fix it.
>>>
>>> I understand this. Port can check this (because it is optional system
>>> component) and use another or generate error.
>>
>> This is very confusing. One of us is out of sync with reality.
>> (If it's me, I'd like to know.) Your confident claim that csh is
>> optional is like stating that the sky is green and the sun is purple.
>>
>> Did I miss something?
>>
>> Yes, I know there is a WITHOUT_TCSH knob. You can use this when
>> you build a FreeBSD-based embedded system where you know you won't
>> need csh. In no way does the existence of this knob imply that csh
>> is optional on a standard FreeBSD system where you build ports.
What are those requirements that constitute standard FreeBSD system
capable of building ports?
>>
>
> Ok, another example is NIS. You can turn off NIS support in your
> system, and ports will check NIS biraries if they need them.
There are more examples
- openssl: WITH_OPENSSL_PORT
- pkg_install: .if exists(...)
- fetch: .if exists(...)
- texinfo: by relying on PATH
And rather than resurrecting shells/tcsh one can also also try
BUILD_DEPENDS += ${CSH}:${PORTSDIR}/shells/44bsd-csh
.if exists(/bin/csh)
CSH ?= /bin/csh
.else
CSH ?= ${LOCALBASE}/bin/44bsd-csh
.endif
But some ports may assume csh is tcsh like sh is bash on linux.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
2010/11/19 O. Hartmann : > On 11/19/10 13:46, Koop Mast wrote: >> >> On Fri, 19 Nov 2010 12:32:33 +0100 >> "O. Hartmann" wrote: >> >>> Hello. >>> Trying to do my first port and run into trouble. >>> The software package (Xerces-c 3.1.1) comes with a full autotoll >>> environment and so far building and installing works. >>> >>> But the libarary name is "libxerces-c-3.1.so" and I need to change this >>> to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm >>> looking for a way avoiding some "post-install:" stuff. >> >> There isn't any problem with the libxerces-c-3.1.so name. >> From http://www.freebsd.org/doc/en/books/porters-handbook/special.html >> Try to keep shared library version numbers in the libfoo.so.0 format. >> Our runtime linker only cares for the major (first) number. > > Well, this is the problem. The automated installation process installes > libxerces-c-3.1.so. This not a problem. Inability to catch the libxerces-c-3.1.so by specifying -lxerces-c linker flag (and enforce you to specify -lxerces-c-3.1) is intended and desired effect. Please, don't touch the library name. Usually, authors change library name if want to ensure and express complete API and ABI break without any forward and backward compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x (libglib-2.0.so.x). In both your (libxerces) and my (libglib) examples the authors desired to use "interface generation" numbers, but it just for aesthetics reasons, indeed the libraries could be renamed to any other arbitrary way (for example, libNewGlib.so and libEvenBetterXerces.so -- ideologically and technically there no differences). If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all application that want and expect the old "zero-generation" API and link against '-llibxerces-c' will fail because will catch absolutely unexpected (by them) and incompatible libxerces-c-3.1 API. Applications that indeed want and expect libxerces-c-3.1 API, and therefore that links with '-llibxerces-c-3.1' will fail also. Just because there no more libxerces-c-3.1.so library -- it was renamed to unexpected name w/o good reasons. Conclusion: Please, don't touch library names! -- Andrew W. Nosenko ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmann: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 "O. Hartmann"wrote: Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is "libxerces-c-3.1.so" and I need to change this to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm looking for a way avoiding some "post-install:" stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. Well, this is the problem. The automated installation process installes libxerces-c-3.1.so. This not a problem. Inability to catch the libxerces-c-3.1.so by specifying -lxerces-c linker flag (and enforce you to specify -lxerces-c-3.1) is intended and desired effect. Please, don't touch the library name. Usually, authors change library name if want to ensure and express complete API and ABI break without any forward and backward compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x (libglib-2.0.so.x). In both your (libxerces) and my (libglib) examples the authors desired to use "interface generation" numbers, but it just for aesthetics reasons, indeed the libraries could be renamed to any other arbitrary way (for example, libNewGlib.so and libEvenBetterXerces.so -- ideologically and technically there no differences). If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all application that want and expect the old "zero-generation" API and link against '-llibxerces-c' will fail because will catch absolutely unexpected (by them) and incompatible libxerces-c-3.1 API. Applications that indeed want and expect libxerces-c-3.1 API, and therefore that links with '-llibxerces-c-3.1' will fail also. Just because there no more libxerces-c-3.1.so library -- it was renamed to unexpected name w/o good reasons. Conclusion: Please, don't touch library names! Well, maybe here is a misunderstanding. I'd like to come along with FreeBSD's library naming scheme when installing the library into /usr/local/lib. I thought manipulating the source-environment when compiling would be the least-efford way, but I see, maybe it would be easier to come along with a post-install: target by simply moving and making a symbolic link. If so, I need to detect by the framework what the lib vendor has choosen as thi lib name, to automate the proceed perfectly. Is this possible? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On Fri, Nov 19, 2010 at 03:32:16PM + I heard the voice of Christian Weisgerber, and lo! it spake thus: > > Yes, I know there is a WITHOUT_TCSH knob. You can use this when you > build a FreeBSD-based embedded system where you know you won't need > csh. In no way does the existence of this knob imply that csh is > optional on a standard FreeBSD system where you build ports. There's also a WITHOUT_MAKE knob. I haven't tested how well ports handles that yet... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On 19 November 2010 18:32, Christian Weisgerber wrote: > Eir Nym wrote: > >> >>> Since when? If you are missing /bin/csh, your system is defective >> >>> or at least nonstandard. >> >> >> >> It is good joke, thanks >> > >> > I guess he's talking about the ports tree being too fragile for some >> > non-default configurations and not many people are willing to fix it. >> >> I understand this. Port can check this (because it is optional system >> component) and use another or generate error. > > This is very confusing. One of us is out of sync with reality. > (If it's me, I'd like to know.) Your confident claim that csh is > optional is like stating that the sky is green and the sun is purple. > > Did I miss something? If you think that any part of base system is mandatory, you should write request to remove knob WITHOUT_TCSH and any other, which you think is not optional. > > Yes, I know there is a WITHOUT_TCSH knob. You can use this when > you build a FreeBSD-based embedded system where you know you won't > need csh. In no way does the existence of this knob imply that csh > is optional on a standard FreeBSD system where you build ports. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On 19 November 2010 18:32, Christian Weisgerber wrote: > Eir Nym wrote: > >> >>> Since when? If you are missing /bin/csh, your system is defective >> >>> or at least nonstandard. >> >> >> >> It is good joke, thanks >> > >> > I guess he's talking about the ports tree being too fragile for some >> > non-default configurations and not many people are willing to fix it. >> >> I understand this. Port can check this (because it is optional system >> component) and use another or generate error. > > This is very confusing. One of us is out of sync with reality. > (If it's me, I'd like to know.) Your confident claim that csh is > optional is like stating that the sky is green and the sun is purple. > > Did I miss something? > > Yes, I know there is a WITHOUT_TCSH knob. You can use this when > you build a FreeBSD-based embedded system where you know you won't > need csh. In no way does the existence of this knob imply that csh > is optional on a standard FreeBSD system where you build ports. > Ok, another example is NIS. You can turn off NIS support in your system, and ports will check NIS biraries if they need them. > -- > Christian "naddy" Weisgerber na...@mips.inka.de > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem (again) with portsnap5.FreeBSD.org?
On Fri, Nov 19, 2010 at 12:00 AM, Guido Falsi wrote:
> portsnap5 has less weight now and is in fact being used less. My systems
> are more frequently using other servers now.
>
> A few days ago portsnap5 did not respond, anyway in that case portsnap
> simply timed out and tried another server shortly after.
Not sure if it's related, but portsnap5 is also IPv6 at this writing:
ro...@mycroft:~$ for suffix in `seq 1 7`; do host
portsnap${suffix}.freebsd.org; done
portsnap1.freebsd.org has address 204.109.56.116
portsnap2.freebsd.org has address 208.83.221.214
portsnap3.freebsd.org has address 212.101.4.241
portsnap4.freebsd.org has address 93.158.155.199
portsnap5.freebsd.org has address 204.9.55.80
portsnap5.freebsd.org has IPv6 address 2001:4978:1:420::cc09:3750
portsnap6.freebsd.org has address 149.20.53.40
portsnap6.freebsd.org has IPv6 address 2001:4f8:3:ffe0::40
Host portsnap7.freebsd.org not found: 3(NXDOMAIN)
Note also that the update and portsnap servers appear to be relatively
independent of one another, with only the "5" server sharing the same
IP:
ro...@mycroft:~$ for suffix in `seq 1 7`; do host
portsnap${suffix}.freebsd.org; done
portsnap1.freebsd.org has address 204.109.56.116
portsnap2.freebsd.org has address 208.83.221.214
portsnap3.freebsd.org has address 212.101.4.241
portsnap4.freebsd.org has address 93.158.155.199
portsnap5.freebsd.org has address 204.9.55.80
portsnap5.freebsd.org has IPv6 address 2001:4978:1:420::cc09:3750
portsnap6.freebsd.org has address 149.20.53.40
portsnap6.freebsd.org has IPv6 address 2001:4f8:3:ffe0::40
Host portsnap7.freebsd.org not found: 3(NXDOMAIN)
Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem (again) with portsnap5.FreeBSD.org?
On Fri, Nov 19, 2010 at 6:18 AM, Royce Williams
wrote:
> On Fri, Nov 19, 2010 at 12:00 AM, Guido Falsi wrote:
>> portsnap5 has less weight now and is in fact being used less. My systems
>> are more frequently using other servers now.
>>
>> A few days ago portsnap5 did not respond, anyway in that case portsnap
>> simply timed out and tried another server shortly after.
>
> Not sure if it's related, but portsnap5 is also IPv6 at this writing:
>
> ro...@mycroft:~$ for suffix in `seq 1 7`; do host
> portsnap${suffix}.freebsd.org; done
> portsnap1.freebsd.org has address 204.109.56.116
> portsnap2.freebsd.org has address 208.83.221.214
> portsnap3.freebsd.org has address 212.101.4.241
> portsnap4.freebsd.org has address 93.158.155.199
> portsnap5.freebsd.org has address 204.9.55.80
> portsnap5.freebsd.org has IPv6 address 2001:4978:1:420::cc09:3750
> portsnap6.freebsd.org has address 149.20.53.40
> portsnap6.freebsd.org has IPv6 address 2001:4f8:3:ffe0::40
> Host portsnap7.freebsd.org not found: 3(NXDOMAIN)
>
>
> Note also that the update and portsnap servers appear to be relatively
> independent of one another, with only the "5" server sharing the same
> IP:
Er, cut-and-paste error ... sorry; it's early in Alaska ...
ro...@mycroft:~$ for suffix in `seq 1 7`; do host
update${suffix}.freebsd.org; done
Host update1.freebsd.org not found: 3(NXDOMAIN)
update2.freebsd.org has address 149.20.53.40
update2.freebsd.org has IPv6 address 2001:4f8:3:ffe0::40
update3.freebsd.org has address 147.229.9.40
update4.freebsd.org has address 209.193.13.98
update5.freebsd.org has address 204.9.55.80
update5.freebsd.org has IPv6 address 2001:4978:1:420::cc09:3750
Host update6.freebsd.org not found: 3(NXDOMAIN)
Host update7.freebsd.org not found: 3(NXDOMAIN)
Royce
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
Eir Nym wrote: > >>> Since when? If you are missing /bin/csh, your system is defective > >>> or at least nonstandard. > >> > >> It is good joke, thanks > > > > I guess he's talking about the ports tree being too fragile for some > > non-default configurations and not many people are willing to fix it. > > I understand this. Port can check this (because it is optional system > component) and use another or generate error. This is very confusing. One of us is out of sync with reality. (If it's me, I'd like to know.) Your confident claim that csh is optional is like stating that the sky is green and the sun is purple. Did I miss something? Yes, I know there is a WITHOUT_TCSH knob. You can use this when you build a FreeBSD-based embedded system where you know you won't need csh. In no way does the existence of this knob imply that csh is optional on a standard FreeBSD system where you build ports. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: xorg-server 1.7.7
Hi, Slowly i get my time back to work on FreeBSD, i'll start working next week on a xorg update. if someone want to help, please ping me via privat mail or irc. - Miwi On Tue, Nov 16, 2010 at 3:00 AM, Doug Barton wrote: > On 11/15/2010 02:51, Tijl Coosemans wrote: > > It would be better if there was a repo for ports development on the >> FreeBSD servers. There are several projects now that could use this >> that I think this is warranted. It would increase their visibility and >> lower the barrier to entry to attract contributors and testers. >> > > This would be quite easily accomplished by branching the ports tree we have > no in CVS. Doing this would accomplish a lot of goals: > > 1. Make it easier for users to pick up and test new ports > 2. Make it easier for the "experimental" trees to keep up to date with the > canonical ports tree > 3. Allow us to have a "stable" ports tree that users can check out and be > reasonably well assured that everything in it will work together safely. > > > Doug > > -- > >Nothin' ever doesn't change, but nothin' changes much. >-- OK Go > >Breadth of IT experience, and depth of knowledge in the DNS. >Yours for the right price. :) http://SupersetSolutions.com/ > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On 19 November 2010 17:26, Anonymous wrote: > Eir Nym writes: > >> On 19 November 2010 16:44, Christian Weisgerber wrote: >>> Eir Nym wrote: >>> Your patch should check if tcsh is in system. it is optional component. >>> >>> Since when? If you are missing /bin/csh, your system is defective >>> or at least nonstandard. >> >> It is good joke, thanks > > I guess he's talking about the ports tree being too fragile for some > non-default configurations and not many people are willing to fix it. > I understand this. Port can check this (because it is optional system component) and use another or generate error. > IOW, you can emphasize tcsh(1) being optional by stepping up to maintain > shells/tcsh. ;) > I prefer to create Makefile for make(1) or gmake(1) for this port or rewrite script to use sh(1) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pixman update
On Wed, 17 Nov 2010, Ruslan Mahmatkhanov wrote: Xorg could not start after pixman update. It exists with: """ Fatal server error: xf86OpenPccons: CONSOLE_X_MODE_OFF failed (Inappropriate ioctl for device) Was expecting pccons driver with X support Check your kernel's console driver configuration and /dev entries """ All is now fine after x11-servers/xorg-server rebuilding. Shuldn't we bump PORTREVISION for xorg-server? I used portupgrade -r pixman, but it didn't feel the need to rebuild xorg-server, and X still works. No idea why the difference. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
Eir Nym writes: > On 19 November 2010 16:44, Christian Weisgerber wrote: >> Eir Nym wrote: >> >>> Your patch should check if tcsh is in system. it is optional component. >> >> Since when? If you are missing /bin/csh, your system is defective >> or at least nonstandard. > > It is good joke, thanks I guess he's talking about the ports tree being too fragile for some non-default configurations and not many people are willing to fix it. IOW, you can emphasize tcsh(1) being optional by stepping up to maintain shells/tcsh. ;) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 "O. Hartmann" wrote: Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is "libxerces-c-3.1.so" and I need to change this to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm looking for a way avoiding some "post-install:" stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. Well, this is the problem. The automated installation process installes libxerces-c-3.1.so. Is it possible to manipulate the library name via some variables passed through the port-framework to the build-enviroment? There isn't. We leave the library name just like upstream/author wants it to be. We only hack the library version if needed. This implies having a post-install: target in the Makefile where I'm supposed to move libxerces-c-3.1.so libbxerces-c.so.31? -Koop Well, I'm very new to porting and this may seem to be a very easy task for experienced porters, so please excuse possible bothering ... Thanks in advance, Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
On 19 November 2010 16:44, Christian Weisgerber wrote: > Eir Nym wrote: > >> Your patch should check if tcsh is in system. it is optional component. > > Since when? If you are missing /bin/csh, your system is defective > or at least nonstandard. > It is good joke, thanks > -- > Christian "naddy" Weisgerber na...@mips.inka.de > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [solved] Re: [freebsd] pecl-imagick -> Segmentation fault: 11 (core dumped) on php -i under freebsd 7.3
Olivier Mueller ha scritto: Brillant! It fixed the issue, many thanks. This is not the correct fix, the correct "fix" is to enable threads in php, using the appropriate OPTION. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mk/bsd.command.mk: missing CSH tag
Eir Nym wrote: > Your patch should check if tcsh is in system. it is optional component. Since when? If you are missing /bin/csh, your system is defective or at least nonstandard. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Fri, 19 Nov 2010 12:32:33 +0100 "O. Hartmann" wrote: > Hello. > Trying to do my first port and run into trouble. > The software package (Xerces-c 3.1.1) comes with a full autotoll > environment and so far building and installing works. > > But the libarary name is "libxerces-c-3.1.so" and I need to change this > to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm > looking for a way avoiding some "post-install:" stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. > Is it possible to manipulate the library name via some variables passed > through the port-framework to the build-enviroment? There isn't. We leave the library name just like upstream/author wants it to be. We only hack the library version if needed. -Koop > Well, I'm very new to porting and this may seem to be a very easy task > for experienced porters, so please excuse possible bothering ... > > Thanks in advance, > > Oliver > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Renaming a shared library in the port-framework to match FreeBSD naming schemes?
Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is "libxerces-c-3.1.so" and I need to change this to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm looking for a way avoiding some "post-install:" stuff. Is it possible to manipulate the library name via some variables passed through the port-framework to the build-enviroment? Well, I'm very new to porting and this may seem to be a very easy task for experienced porters, so please excuse possible bothering ... Thanks in advance, Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portlocate updated
Hi freebsd ports, I updated my ruby program called "portlocate" to use Ferret rather than Xapian like before: http://www.algonet.se/~afb/freebsd/portlocate.rb The program works the same as before, but doesn't need Xapian which was reoccuringly broken (and GPL). The main part of Ferret is in C but there is a pure Ruby version too, if needed (it's a port of Lucene): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/rubygem-ferret/ I was originally hoping for it to get included in pkgtools, but since those aren't maintained anymore it should probably be made into a Ruby module too ? So that it can be included from PackageKit, that is. http://lists.freebsd.org/pipermail/freebsd-ruby/2009-September/000107.html One nice thing about Ferret, besides the MIT license, is that the database is smaller. It's a little slower. --anders ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portlocate updated
Hi freebsd ports, I updated my ruby program called "portlocate" to use Ferret rather than Xapian like before: http://www.algonet.se/~afb/freebsd/portlocate.rb The program works the same as before, but doesn't need Xapian which was reoccuringly broken (and GPL). The main part of Ferret is in C but there is a pure Ruby version too, if needed (it's a port of Lucene): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/rubygem-ferret/ I was originally hoping for it to get included in pkgtools, but since those aren't maintained anymore it should probably be made into a Ruby module too ? So that it can be included from PackageKit, that is. http://lists.freebsd.org/pipermail/freebsd-ruby/2009-September/000107.html One nice thing about Ferret, besides the MIT license, is that the database is smaller. It's a little slower. --anders ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 6.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: vlc-1.1.5,3
Hello, in my opinion there are some problems trying to compile vlc-1.1.5,3 on a FreeBSD 7.3 system: inhibit/xscreensaver.c:55: error: expected specifier-qualifier-list before 'posix_spawn_file_actions_t' inhibit/xscreensaver.c: In function 'Activate': inhibit/xscreensaver.c:91: error: implicit declaration of function 'posix_spawn_file_actions_init' inhibit/xscreensaver.c:91: error: 'vlc_inhibit_sys_t' has no member named 'actions' inhibit/xscreensaver.c:94: error: implicit declaration of function 'posix_spawn_file_actions_adddup2' inhibit/xscreensaver.c:94: error: 'vlc_inhibit_sys_t' has no member named 'actions' inhibit/xscreensaver.c:95: error: 'vlc_inhibit_sys_t' has no member named 'actions' inhibit/xscreensaver.c:96: error: implicit declaration of function 'posix_spawn_file_actions_addclose' inhibit/xscreensaver.c:96: error: 'vlc_inhibit_sys_t' has no member named 'actions' inhibit/xscreensaver.c:98: error: 'vlc_inhibit_sys_t' has no member named 'nullfd' inhibit/xscreensaver.c:101: error: implicit declaration of function 'posix_spawnattr_init' inhibit/xscreensaver.c:101: error: 'vlc_inhibit_sys_t' has no member named 'attr' inhibit/xscreensaver.c:103: error: implicit declaration of function 'posix_spawnattr_setsigmask' inhibit/xscreensaver.c:103: error: 'vlc_inhibit_sys_t' has no member named 'attr' [...] It seems the patches made by extra-patch-modules__misc__inhibit__xscreensaver.c are not enough to make that module compilable without spawn.h and its functions/definitions. Thanks for your work, and if you think I can help you in some way (even if I'm not a "strong" C programmer at all!) please tell me! -- Marco Alberoni ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem (again) with portsnap5.FreeBSD.org?
On Tue, Nov 09, 2010 at 01:03:22PM -0800, Jason Helfman wrote: > >> > >>Yep - update5 is currently weighted 50% in the SRV: > >> > >>$ host -t srv _http._tcp.update.freebsd.org > >>_http._tcp.update.freebsd.org has SRV record 1 35 80 update4.FreeBSD.org. > >>_http._tcp.update.freebsd.org has SRV record 1 50 80 update5.FreeBSD.org. > >>_http._tcp.update.freebsd.org has SRV record 1 5 80 update3.FreeBSD.org. > >>_http._tcp.update.freebsd.org has SRV record 1 10 80 update2.FreeBSD.org. > >> > > > >Thank you. This explains what I was seeing and makes it in fact quite > >normal. > > I am seeing similiar issues with portsnap5. > Are you pointing portsnap to update? > > host -t srv _http._tcp.portsnap.freebsd.org > _http._tcp.portsnap.freebsd.org has SRV record 1 10 80 portsnap6.FreeBSD.org. > _http._tcp.portsnap.freebsd.org has SRV record 1 20 80 portsnap5.FreeBSD.org. > _http._tcp.portsnap.freebsd.org has SRV record 2 10 80 portsnap4.FreeBSD.org. > _http._tcp.portsnap.freebsd.org has SRV record 1 10 80 portsnap1.FreeBSD.org. > _http._tcp.portsnap.freebsd.org has SRV record 1 10 80 portsnap2.FreeBSD.org. I'm getting the same DNS result you're getting. portsnap5 has less weight now and is in fact being used less. My systems are more frequently using other servers now. A few days ago portsnap5 did not respond, anyway in that case portsnap simply timed out and tried another server shortly after. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
