Hydraulic simulation software
Are there any hydraulic simulation software in the FreeBSD ecosystem? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Request clear steps for updating own port
On Mon, May 21, 2018, 07:49 Mateusz Piotrowski <0...@freebsd.org> wrote: > On Mon, 21 May 2018 04:47:56 +0530 > Manish Jain wrote: > > >Hi, > > > >I have an active port (sysutils/mkdesktop) which I maintain myself. > > > >A few days back, I had to upgrade the port from 1.6 to 1.7 so as to > >reflect new names of kde4 packages. > > > >I seem to have completely lost memory of what I have to do to get the > >port updated properly in FreeBSD ports. Can someone be kind enough to > >guide me what steps are needed for updating one's own port? > > > >My port uses GitHub and is located at: > >https://github.com/bourne-again/mkdesktop > > > >Essentially, I have an updated Makefile/distinfo which I need to get > >merged into FreeBSD ports. > > > >I have updated the shar attachment for the port at the URL where the > >port was originally submitted: > > > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221370 > > I'd open a new issue if you wish to update your port. > > The title of the issue could be something like: > > sysutils/mkdesktop: Update to 1.7 > > Make sure to upload the diff with the new version of your port. Shar is > OK, I guess, but a patch is much much better. > > The handbook has some useful hints as well probably: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html > > Good luck! > > Mateusz > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > Create a diff Go to FreeBSD bugzilla file a new bug report with diff. Wait for a committer to merge it for you. Profit! Best, Owen > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
conflicts with packages on install
I'm working on updating a port it currently installs in a
${PREFIX}/${PORTNAME}/bin and I'd like to create symlinks t ${PREFIX}/bin
The issue i'm running into is that there's a binary file "terrain" this
conflicts with graphics/mesa-demos/terrain.
I'm looking for options on resolving this conflict, any suggestions?
Best,
Owen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fortran compiler [devel/flang-clang] broken
Hello
devel/flangclang seems to still be broken, on pkg-install I get errors
because flang is installed in {PREFIX}/flang instead of {PREFIX}
Is there any particular reason why flang-clang isn't installed in the
standard directory?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Fortran compiler [devel/flang-clang] broken
On Sun, Jul 8, 2018 at 10:01 PM Rainer Hurling wrote:
> Am 08.07.2018 um 10:20 schrieb blubee blubeeme:
> > Hello
> >
> > devel/flangclang seems to still be broken, on pkg-install I get errors
> > because flang is installed in {PREFIX}/flang instead of {PREFIX}
> >
> > Is there any particular reason why flang-clang isn't installed in the
> > standard directory?
>
>
> Hi blubee blubeeme,
>
> Both, devel/flang-clang and devel/flang, install in ${PREFIX}/flang.
>
> I just tried to reinstall and it works for me. What exactly is wrong
> with it for you?
>
> Regards,
> Rainer Hurling
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
I just noticed that devel/flang doesn't register properly even though the
package builds.
after installation pkg-static fails to register the files and the build
fails;, here's a cmake build log: https://pastebin.com/SCJ3TaKP
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
git checkout branch in makefile
Is it possible to do a git checkout of a specific branch in a ports makefile? How would I go about checking out a particular branch from a github project. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: git checkout branch in makefile
On Tue, Jul 10, 2018 at 6:15 PM Brooks Davis wrote: > On Mon, Jul 09, 2018 at 08:19:13PM +0200, Michael Gmelin wrote: > > > > > > > On 9. Jul 2018, at 19:34, blubee blubeeme wrote: > > > > > > Is it possible to do a git checkout of a specific branch in a ports > > > makefile? > > > > > > How would I go about checking out a particular branch from a github > project. > > > > As branches aren???t stable this won???t buy you anything, that???s why > you should always go for a tag or commit (which is branch agnostic). > > If you want to make it easy to update to the latest commit on a branch, > take > a look at devel/llvm-devel/files/gen-Makefile.snapshot.sh for an example > of automatically extracting that information from the github API. > > -- Brooks > That's actually pretty neat stuff, thanks for the reference. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
automake automake-wrapper installation conflicts
I've been running into this issue today and I'm not sure what's going on. I've read UPDATING and it says there will be autoconf and autoconf213 okay; uname -a: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336196: Wed Jul 11 21:52:50 CST 2018 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I updated my ports to revision 475573. deinstall cleaned all autotools but whenever I try to build a port that requires some form of autotools it fails with something along the lines of: ===> ghc-8.4.3 depends on executable: sphinx-build - found ===> ghc-8.4.3 depends on package: autoconf>=2.69 - found ===> ghc-8.4.3 depends on package: automake>=1.16.1 - not found ===> Installing for automake-1.16.1 ===> Checking if automake already installed ===> Registering installation for automake-1.16.1 as automatic Installing automake-1.16.1... pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 (installs files into the same place). Problematic file: /usr/local/bin/aclocal Do I need to nuke my ports directory and redownload it, or how can I fix this? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
SVN down or slow
Has anyone else noticed that svn is getting this type of error trying to run svn: svn: E65: Error running context: No route to host ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
setting port options for multiple ports
I am working on a port that requires many other ports to be built with specific options selected. Is there any way to have a port enables options in it's dependencies? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
building openjdk without alsa dependency
I would like to build openjdk7 without the asound lib, I already removed ALSA from my kernel so the build fails but I am not writing Java applications that needs sound. I made a few changes to just not build the ALSA parts and the port builds properly. I had to edit the patch-bsd and created a new patch to remove building ALSA sound parts. Would it be possible to have the java team add a knob to the USE_JAVA in bsd.java.mk so that I can use this version with other ports? patch-jdk_make_common_Sanity.gmk : https://pastebin.com/cXej8LES patch-bsd : https://pastebin.com/E9xHTkKH Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: setting port options for multiple ports
On 7/31/18, Guido Falsi wrote: > On 7/30/18 8:48 PM, Jan Beich wrote: >> Guido Falsi writes: >> >>> On 7/30/18 1:02 PM, blubee blubeeme wrote: >>> >>>> I am working on a port that requires many other ports to be built with >>>> specific options selected. >>>> >>>> Is there any way to have a port enables options in it's dependencies? >>>> >>> >>> There is no way to do exactly what you are asking for, but the >>> "traditional" solution is to create a slave port forcing the options you >>> require and naming it accordingly. >>> >>> This could also be done with flavors today, but keep in mind that adding >>> flavors would require approval from both the maintainer and portmgr. >> >> Except anything else that depends on unslaved/unflavored port is likely >> to cause a conflict... until variable dependencies come into play. > > Oh yes, I forgot to mention that. > > Thanks for filling my omission! > > -- > Guido Falsi > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > After thinking about this, implementing something like this will explode in complexity pretty rapidly. The slave ports idea does create install conflicts or bloats a system with prefixed install locations. The port option matrix would be insanely large and require insane amounts of testing to possible get correct. Might as well try to touch the Sun; not saying it's impossible but it's not a task that I want to embark on right now. I'll have to figure out a better way to handle this. Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018, 06:30 Helen Koike wrote:
> Hello,
>
> I am new to the community, I am maintaining two packages and I would
> like to check with you if there is a better workflow to do this.
>
> The upstream project of the port I am maintaining is held in github, and
> I also have patches in the /usr/ports/sysutils/myport/file/ folder.
>
> So I keep a fork of the upstream project with a branch containing a
> commit with the patches from the /usr/ports/sysutils/myport/file/.
>
> Every time I need to update the port to a newer version, I do a git pull
> in this branch, then I run a script [1] to re-generate the patches in
> the /usr/ports/sysutils/myport/file/
>
> This script basically generates a file.orig of all modified files in
> git, then copy the modified file to WORK_DIR, then run make makepatch.
>
>
> for file in ${CHANGES}; do
> mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> done
> make makepatch
>
>
> I would like to know if there is a better way to do this (some tool that
> I am not aware of?).
>
> [1]
>
> https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh
>
> Thanks
> Helen
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
Submit your patches upstream, once they get accepted your work on FreeBSD
is greatly simplified.
Best,
Owen
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018, 08:26 Helen Koike wrote:
>
>
> On 08/13/2018 08:00 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018, 06:30 Helen Koike > <mailto:helen.ko...@collabora.com>> wrote:
> >
> > Hello,
> >
> > I am new to the community, I am maintaining two packages and I would
> > like to check with you if there is a better workflow to do this.
> >
> > The upstream project of the port I am maintaining is held in github,
> and
> > I also have patches in the /usr/ports/sysutils/myport/file/ folder.
> >
> > So I keep a fork of the upstream project with a branch containing a
> > commit with the patches from the /usr/ports/sysutils/myport/file/.
> >
> > Every time I need to update the port to a newer version, I do a git
> pull
> > in this branch, then I run a script [1] to re-generate the patches in
> > the /usr/ports/sysutils/myport/file/
> >
> > This script basically generates a file.orig of all modified files in
> > git, then copy the modified file to WORK_DIR, then run make
> makepatch.
> >
> >
> > for file in ${CHANGES}; do
> > mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> > cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> > done
> > make makepatch
> >
> >
> > I would like to know if there is a better way to do this (some tool
> that
> > I am not aware of?).
> >
> > [1]
> >
> https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh
> >
> > Thanks
> > Helen
> >
> > ___
> > freebsd-ports@freebsd.org <mailto:freebsd-ports@freebsd.org> mailing
> > list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to
> > "freebsd-ports-unsubscr...@freebsd.org
> > <mailto:freebsd-ports-unsubscr...@freebsd.org>"
> >
> > Submit your patches upstream, once they get accepted your work on
> > FreeBSD is greatly simplified.
> >
> > Best,
> > Owen
> >
>
> I am doing that, but there are some changes that I couldn't include in
> upstream yet.
>
> Helen
>
Can you give an example of types of changes can't be upstream yet and their
reasoning why not?
Best,
Owen
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018 at 8:56 PM Helen Koike
wrote:
>
>
> On 08/13/2018 09:50 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018, 08:26 Helen Koike > <mailto:helen.ko...@collabora.com>> wrote:
> >
> >
> >
> > On 08/13/2018 08:00 PM, blubee blubeeme wrote:
> > >
> > >
> > > On Tue, Aug 14, 2018, 06:30 Helen Koike > <mailto:helen.ko...@collabora.com>
> > > <mailto:helen.ko...@collabora.com
> > <mailto:helen.ko...@collabora.com>>> wrote:
> > >
> > > Hello,
> > >
> > > I am new to the community, I am maintaining two packages and I
> > would
> > > like to check with you if there is a better workflow to do
> this.
> > >
> > > The upstream project of the port I am maintaining is held in
> > github, and
> > > I also have patches in the /usr/ports/sysutils/myport/file/
> > folder.
> > >
> > > So I keep a fork of the upstream project with a branch
> > containing a
> > > commit with the patches from the
> /usr/ports/sysutils/myport/file/.
> > >
> > > Every time I need to update the port to a newer version, I do
> > a git pull
> > > in this branch, then I run a script [1] to re-generate the
> > patches in
> > > the /usr/ports/sysutils/myport/file/
>
This one is fairly straight forward, you can simply replace that string
with a regex command;
This is an example of running a replace command for strings after the patch
phase of the build;
post-patch:
@${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
> > >
> > > This script basically generates a file.orig of all modified
> > files in
> > > git, then copy the modified file to WORK_DIR, then run make
> > makepatch.
> > >
> > >
> > > for file in ${CHANGES}; do
> > > mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> > > cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> > > done
> > > make makepatch
>
Depending on how drastic the changes are, you can use the above command to
simply replace strings;
There's also binary alias, that allows to replace sed with gsed:
https://www.freebsd.org/doc/en/books/porters-handbook/binary-alias.html
Speaking of which, FreeBSD has access to all the GNU tools such as;
gmake [gnu make]
gsed[gnu sed]
if it's only a few commands you can use binary alias.
If the project needs GNU tools, then FreeBSD also provides a way to
automatically
run the required scripts
check section 6.5.3 configure Scripts:
https://www.freebsd.org/doc/en/books/porters-handbook/building.html
> > >
> > >
> > > I would like to know if there is a better way to do this (some
> > tool that
> > > I am not aware of?).
> > >
> > > [1]
> > >
> >
> https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh
> > >
> > > Thanks
> > > Helen
> > >
> > > ___
> > > freebsd-ports@freebsd.org <mailto:freebsd-ports@freebsd.org>
> > <mailto:freebsd-ports@freebsd.org
> > <mailto:freebsd-ports@freebsd.org>> mailing
> > > list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > > To unsubscribe, send any mail to
> > > "freebsd-ports-unsubscr...@freebsd.org
> > <mailto:freebsd-ports-unsubscr...@freebsd.org>
> > > <mailto:freebsd-ports-unsubscr...@freebsd.org
> > <mailto:freebsd-ports-unsubscr...@freebsd.org>>"
> > >
> > > Submit your patches upstream, once they get accepted your work on
> > > FreeBSD is greatly simplified.
> > >
> > > Best,
> > > Owen
> > >
> >
> > I am doing that, but there are some changes that I couldn't include
> in
> > upstream yet.
> >
> > Helen
> >
> > Can you give an example of types of changes can't be upstream yet and
> > their reasoning why not?
> >
> > Best,
> > Owen
> >
>
> Sure, e.g. "service -e" vs "service --status-all", there is also sed vs
> gsed (but it just came to
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018 at 10:23 PM Helen Koike
wrote:
>
>
> On 08/14/2018 12:05 AM, Adam Weinberger wrote:
> > On Mon, Aug 13, 2018 at 4:28 PM Helen Koike
> wrote:
> >>
> >> Hello,
> >>
> >> I am new to the community, I am maintaining two packages and I would
> >> like to check with you if there is a better workflow to do this.
> >>
> >> The upstream project of the port I am maintaining is held in github, and
> >> I also have patches in the /usr/ports/sysutils/myport/file/ folder.
> >>
> >> So I keep a fork of the upstream project with a branch containing a
> >> commit with the patches from the /usr/ports/sysutils/myport/file/.
> >>
> >> Every time I need to update the port to a newer version, I do a git pull
> >> in this branch, then I run a script [1] to re-generate the patches in
> >> the /usr/ports/sysutils/myport/file/
> >>
> >> This script basically generates a file.orig of all modified files in
> >> git, then copy the modified file to WORK_DIR, then run make makepatch.
> >>
> >>
> >> for file in ${CHANGES}; do
> >> mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> >> cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> >> done
> >> make makepatch
> >>
> >>
> >> I would like to know if there is a better way to do this (some tool that
> >> I am not aware of?).
> >
> > IIUC, the process you're describing seems to be rebasing your changes
> > and then generating diffs. You might have an easier time if you just
> > do that: rebase, and then generate a diff (see the last point here)>
> > Your script automates some of the routine Makefile changes, and while
> > there are some tools in ports-mgmt/ that can automate that, we don't
> > generally recommend them.
> >
> > It's common for Makefiles to have a maintainer-update: target that
> > keeps the repetitive update tasks in the Makefile (which also helps
> > the next person to maintain the port).
>
> I didn't know about this target, I'll take a look. Thanks.
>
> >
> > Also, where many files are modified on a continually-changing basis,
> > it's acceptable (though less systemically desirable) to put all your
> > patches into one file. The benefit is that you can generate that one
> > file with a single git diff, and it makes PR submission far, far
> > simpler.
>
> Is there a way to easily transform a git patch to the FreeBSD
> file/*.patch format? Because I use make makepatch, and it will generate
> several patches anyway.
> Once I used "diff -Nur", but it doesn't seem to be the same exact format
> as the one generated by make makepatch.
>
FreeBSD patching explained a bit here:
https://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html
I am not too sure on the particulars of git diffs but FreeBSD uses a
unified diff;
The part that will cause your makefile to fail is if the filepath at the
top of each patch file
is incorrect.
section 4.4.2. Manual Patch Generation in the above link gives a good
overview of how to manually generate patch files.
I am pretty sure there has to be tools that can automate transforming
whatever style patch git uses to a unified patch file.
>
> >
> > Do any of those help?
> >
> > # Adam
> >
> >
>
> Thanks
> Helen
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
Best,
Owen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: workflow question: how do you maintain the port in sync with upstream?
On Tue, Aug 14, 2018 at 11:33 PM Mathieu Arnold wrote:
> On Tue, Aug 14, 2018 at 10:41:43PM +0800, blubee blubeeme wrote:
> > This one is fairly straight forward, you can simply replace that string
> > with a regex command;
> > This is an example of running a replace command for strings after the
> patch
> > phase of the build;
> >
> > post-patch:
> > @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
>
> Patching files in post-patch using sed SHOULD only be used to replace
> dynamic content, never static content.
>
This is missing the point of the email since you can call that command in
any stage of the port build process.
Maybe we could append this info to the porters handbook.
>
> --
> Mathieu Arnold
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Executables with [ -def __linux__ ]
This is going out to both current and ports in hopes someone can offer some guidance on this issue. I'm porting some code that seems to want to have -def __linux__ when I run the executable with verbose output, take a look below -- -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x40 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x44 -x 51 0x20 -x 57 0x4c -x 58 0x1 -x 124 0x1000 -tp px -x 57 0xfb -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__ -def __NO_MATH_INLINES -def __LP64__ -def __x86_64 -def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __THROW= -def __extension__= -def __amd_64__amd64__ -def __k8 -def __k8__ -def __PGLLVM__ -freeform -vect 48 -y 54 1 -x 70 0x4000 -y 163 0xc000 -x 189 0x10 -stbfile test-276576.stb -modexport test-276576.cmod -modindex test-276576.cmdx -output test-276576.ilm As you can see from above there's some -def linux, def __linux, etc.. FreeBSD isn't Linux and I'd like to better understand where these things are being set, it's a cmake project and I've grepped through a lot of the sources and can't really find where these flags are coming from. Any tips on finding where they are coming from and fixing them to reflect the correct platform information? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: workflow question: how do you maintain the port in sync with upstream?
On Sun, Aug 19, 2018, 13:02 Helen Koike wrote:
>
>
> On 08/14/2018 01:09 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018 at 11:33 PM Mathieu Arnold > <mailto:m...@freebsd.org>> wrote:
> >
> > On Tue, Aug 14, 2018 at 10:41:43PM +0800, blubee blubeeme wrote:
> > > This one is fairly straight forward, you can simply replace that
> > string
> > > with a regex command;
> > > This is an example of running a replace command for strings after
> > the patch
> > > phase of the build;
> > >
> > > post-patch:
> > > @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g'
> > ${WRKSRC}/README
> >
> > Patching files in post-patch using sed SHOULD only be used to replace
> > dynamic content, never static content.
>
> I am not sure I understand what dynamic content means here in the
> post-patch (as nothing was built, so no new file should be created). Is
> the replacement used by mail/lbdb wrong?
>
> from mail/lbdb/Makefile
> post-patch:
> ${REINPLACE_CMD} -e 's/sed/gsed/' ${WRKSRC}/m_muttalias.sh.in
>
> is it ok if I do the same?
> It is not clear to me when I can use REINPLACE_CMD in the Makefile and
> when I should do a patch.
This is mostly a personal choice. If I'm changing complex strings I'd
> generate a patch, if it's something simple just use the replace command.
The shebang fix does something similar to incorrectly defined shebang lines
at the top of script files.
> >
> > This is missing the point of the email since you can call that command
> > in any stage of the port build process.
> >
> > Maybe we could append this info to the porters handbook.
> >
> >
> > --
> > Mathieu Arnold
> >
>
> Helen
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependancies and the ports that depend on them
On Sat, Sep 22, 2018, 15:55 @lbutlr wrote: > My system has no X11 window system of any sort on it, it is simply a > server which I (or anyone else) only interact with via the command line or > by accessing a service like http or mail. > And yet, there's a lot of x11 packages installed. > > I'd like to find out what packages depend on the many x11 packages that > are installed. I know that quiet a few are under apache25, despite there > being no mention of x11 in make config: > > …www/apache24/# make WITHOUT_X11=yes NOPORTDOCS=yes NOPORTEXAMPLES=yes > all-depends-list | grep x11 > /usr/ports/x11/xcb-util-renderutil > /usr/ports/x11/libxcb > /usr/ports/x11/xcb-proto > /usr/ports/x11/libXau > /usr/ports/x11/xorgproto > /usr/ports/x11/libXdmcp > /usr/ports/x11/xcb-util > /usr/ports/x11/pixman > /usr/ports/x11/libX11 > /usr/ports/x11/xtrans > /usr/ports/x11/libXext > /usr/ports/x11/libXrender > /usr/ports/x11-fonts/fontconfig > /usr/ports/x11/libXdamage > /usr/ports/x11/libXfixes > /usr/ports/x11/libxshmfence > /usr/ports/x11/libXxf86vm > /usr/ports/x11/libXi > /usr/ports/x11-toolkits/libXt > /usr/ports/x11/libSM > /usr/ports/x11/libICE > /usr/ports/x11/libXtst > /usr/ports/x11-fonts/dejavu > /usr/ports/x11-fonts/mkfontdir > /usr/ports/x11-fonts/mkfontscale > /usr/ports/x11-fonts/libfontenc > > So, I'd like to figure out which features (make config toggles) are > responsible for these requirements so i can see if they are things that can > be disabled. > > For example, one thing listed is libX11, so I do > > pkg info -r libX11 > libX11-1.6.6_1,1: > gdk-pixbuf2-2.36.11 > libXdamage-1.1.4_4 > libXxf86vm-1.1.4_2 > mesa-libs-18.1.5 > cairo-1.14.8_2,2 > libXcomposite-0.4.4_4,1 > libXcursor-1.1.15_1 > libXinerama-1.1.4_1,1 > libXrandr-1.5.1_1 > gtk-update-icon-cache-2.24.32 > libXpm-3.5.12_1 > gtk2-2.24.32 > vim-8.1.0342 > libXt-1.1.5_2,1 > libXext-1.3.3_3,1 > libXfixes-5.0.3_2 > libXi-1.7.9_2,1 > libXrender-0.9.10_2 > libXtst-1.2.3_2 > openjdk8-8.181.13 > openjdk-7.161.01,1 > > So now I have to go through each of those to see which one might be > required by apach24. Within a coupe of steps you are checking a hundred > packages. > > Is there som way to say "I want to search everything that requires libx11 > all the way up the tree of dependencies until we match apache24, then show > me that chain. > > (so, for example, if apache24 is set to require libfoo99 and libfoo99 > requires bobsport and bobsport requires libXfoo which requires libx11 > > I get: > > apache24 <= libfoo99 <= bobsport <= libXfoo <= libx11 > > when I search for something like "libx11 in apache24" > > -- > Penny, I'm a physicist. I have a working knowledge of the entire > universe and everything it contains. > > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > I usually do something like this with poudriere Touch /tmp/apache25 && tail -f /tmp/apache25 | grep - i "x11" Then Poudriere testport jail ports_tree xxx/apache25 |& tee /tmp/apache25 Then poudriere will list the depends and that will get you a list of depends. I had to do something like that to find out why certain ports were pulling in GCC. Best, Owen > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
error: undefined symbol: main in poudriere jail
This issue seemed to have come up in the past: https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html Jail name: amd64_cur Jail version: 12.0-ALPHA7 1200084 Jail vcs version: r338898 Jail arch: amd64 Jail method: svn Jail mount:/usr/local/poudriere/jails/amd64_cur Jail fs: zroot/poudriere/jails/amd64_cur Jail updated: 2018-09-24 03:39:31 Tree name: default Tree method: portsnap Status: error /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: lib/libged.so.20.0.1 lib/librtuif_multispectral.a lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread -ldl && : FAILED: bin/rttherm : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: lib/libged.so.20.0.1 lib/librtuif_multispectral.a lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread -ldl && : /usr/bin/ld: error: undefined symbol: main >>> referenced by crt1.c:74 (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74) >>> /usr/lib/crt1.o:(_start) cc: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. *** Error code 1 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: error: undefined symbol: main in poudriere jail
On Mon, Sep 24, 2018 at 7:31 AM blubee blubeeme wrote:
> This issue seemed to have come up in the past:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html
>
>
> Jail name: amd64_cur
> Jail version: 12.0-ALPHA7 1200084
> Jail vcs version: r338898
> Jail arch: amd64
> Jail method: svn
> Jail mount:/usr/local/poudriere/jails/amd64_cur
> Jail fs: zroot/poudriere/jails/amd64_cur
> Jail updated: 2018-09-24 03:39:31
> Tree name: default
> Tree method: portsnap
> Status:
>
> error
> /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99
> -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto
> -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> FAILED: bin/rttherm
> : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions
> -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions
> -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c:74
> (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74)
> >>> /usr/lib/crt1.o:(_start)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
> *** Error code 1
>
> I though that it could be an issue with portsnap so I created a new jail
using svn
poudriere jails -j amd64HD -i
Jail name: amd64HD
Jail version: 12.0-ALPHA7 1200084
Jail vcs version: r338899
Jail arch: amd64
Jail method: svn
Jail mount:/usr/local/poudriere/jails/amd64HD
Jail fs: zroot/poudriere/jails/amd64HD
Jail updated: 2018-09-24 07:34:06
Tree name: default
Tree method: portsnap
Status:
error
#include
__FBSDID("$FreeBSD: head/lib/csu/amd64/crt1.c 326219 2017-11-26 02:00:33Z
pfg $");
#include
#include "libc_private.h"
#include "crtbrand.c"
#include "ignore_init.c"
typedef void (*fptr)(void);
#ifdef GCRT
extern void _mcleanup(void);
extern void monstartup(void *, void *);
exter
Re: error: undefined symbol: main in poudriere jail
On Mon, Sep 24, 2018, 17:34 Lorenzo Salvadore via freebsd-ports < freebsd-ports@freebsd.org> wrote: > > > This issue seemed to have come up in the past: > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html > > > > Jail name: amd64_cur > > Jail version: 12.0-ALPHA7 1200084 > > Jail vcs version: r338898 > > Jail arch: amd64 > > Jail method: svn > > Jail mount: /usr/local/poudriere/jails/amd64_cur > > Jail fs: zroot/poudriere/jails/amd64_cur > > Jail updated: 2018-09-24 03:39:31 > > Tree name: default > > Tree method: portsnap > > Status: > > > > error > > /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions > -std=gnu99 > > -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto > > -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef > > -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement > > -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation > > -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o > > src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm > > -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: > > lib/libged.so.20.0.1 lib/librtuif_multispectral.a > > lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 > > /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so > > /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so > > /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 > > /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a > > lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 > > lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so > > lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 > > lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 > > lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 > > lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so > lib/liblz4.so > > lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm > -pthread > > -ldl && : > > FAILED: bin/rttherm > > : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions > > -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions > > -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra > -Wundef > > -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement > > -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation > > -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o > > src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm > > -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: > > lib/libged.so.20.0.1 lib/librtuif_multispectral.a > > lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 > > /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so > > /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so > > /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 > > /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a > > lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 > > lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so > > lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 > > lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 > > lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 > > lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so > lib/liblz4.so > > lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm > -pthread > > -ldl && : > > /usr/bin/ld: error: undefined symbol: main > > > > > > > referenced by crt1.c:74 > > > > (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74) > > > > > > > /usr/lib/crt1.o:(_start) > > > > > > > > > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > > ninja: build stopped: subcommand failed. > > *** Error code 1 > > Can you please explain what were you trying to do and how the error can > be reproduced? > > Lorenzo Salvadore. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > I am trying to update cad/brlcad there's an open issue on the Bugzilla that I'd like to resolve. I'm getting this error both in poudriere but now it's also showing up when trying to build outside of poudriere. Here is the build log https://transfer.sh/bn41v/brlcad-7.26.4_8.log this is a .shar file with the changes https://transfer.sh/wVh1c/brlcad-7.26.4.shar both my machine and poudriere are on r338902 Is this link error only affecting me? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.free
Re: error: undefined symbol: main in poudriere jail
On Mon, Sep 24, 2018, 22:04 Lorenzo Salvadore via freebsd-ports < freebsd-ports@freebsd.org> wrote: > > I am trying to update cad/brlcad there's an open issue on the Bugzilla > that > > I'd like to resolve. > > > > I'm getting this error both in poudriere but now it's also showing up > when > > trying to build outside of poudriere. > > > > Here is the build log > > https://transfer.sh/bn41v/brlcad-7.26.4_8.log > > > > this is a .shar file with the changes > > https://transfer.sh/wVh1c/brlcad-7.26.4.shar > > > > both my machine and poudriere are on r338902 > > > > Is this link error only affecting me? > > I am testing both the actual version of brlcad and your changes. Since I > have a > slow computer, this will take some time (if someone else with a more > powerful > computer can perform the tests in less time it is welcomed). > I have been unofficially maintaining this port for a while now. > > While we wait the results, here are two suggestions: > - ask the mantainer: he is the probably the one that knows better the port > and hence > the best person that can help you (since you are dealing with a bug > report, you might > like to contact him through this same bug report); > - I gave a quick look to your changes and seen the line > CMAKE_ARGS+= -DBRLCAD_BUNDLED_LIBS=ON. Bundled libraries often bring > problems > and, since you are having a linking problem, this might be the cause; > anyway, you should > avoid using them if you can > (see > https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html ) > I typically port all required libs but brlcad is a special set of tools. The linker worked to find earlier but recently stopped. I have want to use native libs but that's a much larger project that needs to be coordinated with the upstream devs. > > If someone else wants to help, it might be useful to give the link to the > bug report that you are working > on. Probably this is the link (it is the only open issue on cad/brlcad > that I found): > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211921 That is indeed the bug report and I've been patching things slowly, yes there were some issues with man pages, those were fixed and then I updated my jail to do one last test before submitting this new patch but then this issue shows up. > > > Lorenzo Salvadore. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: error: undefined symbol: main in poudriere jail
On Tue, Sep 25, 2018 at 4:37 AM Lorenzo Salvadore via freebsd-ports < freebsd-ports@freebsd.org> wrote: > > I am testing both the actual version of brlcad and your changes. Since I > have a > > slow computer, this will take some time (if someone else with a more > powerful > > computer can perform the tests in less time it is welcomed). > > I have finished testing. While the actual version of brlcad fails to build > for me, > your changes worked: the build was successful (on poudriere with a jail > with > 11.2-RELEASE). > > Lorenzo Salvadore. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > That's the problem, the same code works for earlier version of FreeBSD. I understand that current is in ALPHA stage right now and things will break but the linker code is changing under my feet. If it's a problem that's resolved with svn update or a particular revision it would help to know. I am reporting it here so people who are working on those parts of the system can chime in to help, do I just sit tight and wait for the toolchain guys to take notice? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: error: undefined symbol: main in poudriere jail
On Tue, Sep 25, 2018 at 5:27 PM Lorenzo Salvadore via freebsd-ports < freebsd-ports@freebsd.org> wrote: > > > That's the problem, the same code works for earlier version of FreeBSD. > > > > You can try switching back to the old GNU ld via something like "ln > > -fs ld.bfd /usr/bin/ld" and building the port on 12. (Or, set > > WITHOUT_LLD_IS_LD in src.conf.) If that works I'll try to suggest some > > further steps. > > I will repeat the test for current: this will need some time. However I > fear > that I will only confirm that I receive the same error and probably the > best > solution is to try something like Ed Maste's suggestion. > > Lorenzo Salvadore. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > poudriere jail -j 12amd64 -i Password: Jail name: 12amd64 Jail version: 12.0-CURRENT Jail arch: amd64 Jail method: ftp Jail mount:/usr/local/poudriere/jails/freebsd_12-current Jail fs: zroot/poudriere/jails/freebsd_12-current Jail updated: 2018-09-24 07:33:02 Tree name: default Tree method: portsnap Status: cat /usr/local/etc/poudriere.d/12amd64-src.conf | pastebinit https://pastebin.com/sdAEjNfX curl --upload-file /usr/local/poudriere/data/logs/bulk/12amd64-FLANG/2018-09-25_21h02m39s/logs/flang-r.60.log https://transfer.sh https://transfer.sh/th9hi/flang-r.60.log build successfully -- Jail name: amd64HD Jail version: 12.0-ALPHA7 1200084 Jail vcs version: r338899 Jail arch: amd64 Jail method: svn Jail mount:/usr/local/poudriere/jails/amd64HD Jail fs: zroot/poudriere/jails/amd64HD Jail updated: 2018-09-24 07:34:06 Tree name: default Tree method: portsnap Status: cat /usr/local/etc/poudriere.d/amd64HD-src.conf | pastebinit https://pastebin.com/muSvZNLf curl --upload-file /usr/local/poudriere/data/logs/bulk/amd64HD-FLANG/2018-09-25_21h17m08s/logs/flang-r.60.log https://transfer.sh https://transfer.sh/l7Zxa/flang-r.60.log build fails going into the jail on this failed poudiere build making the symlink and building; the build succeeds. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
firefox/ rust failed to install on FreeBSD 12-CURRENT
I'm trying to install firefox on FreeBSD FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318998: Sun May 28 04:38:22 CST 2017 /usr/obj/usr/src/sys/GENERIC amd64 ===> firefox-i18n-53.0.3 depends on file: /usr/local/lib/firefox/firefox - not found ===> firefox-53.0.3_1,1 depends on package: nspr>=4.13.1 - found ===> firefox-53.0.3_1,1 depends on package: nss>=3.29.5 - found ===> firefox-53.0.3_1,1 depends on package: libevent>=2.0.21_2 - found ===> firefox-53.0.3_1,1 depends on package: harfbuzz>=1.4.1 - found ===> firefox-53.0.3_1,1 depends on package: graphite2>=1.3.8 - found ===> firefox-53.0.3_1,1 depends on package: png>=1.6.28 - found ===> firefox-53.0.3_1,1 depends on package: libvorbis>=1.3.5,3 - found ===> firefox-53.0.3_1,1 depends on package: libvpx>=1.5.0 - found ===> firefox-53.0.3_1,1 depends on package: sqlite3>=3.17.0 - found ===> firefox-53.0.3_1,1 depends on package: py27-sqlite3>0 - found ===> firefox-53.0.3_1,1 depends on package: v4l_compat>0 - found ===> firefox-53.0.3_1,1 depends on executable: autoconf-2.13 - found ===> firefox-53.0.3_1,1 depends on executable: yasm - found ===> firefox-53.0.3_1,1 depends on executable: zip - found ===> firefox-53.0.3_1,1 depends on package: gtk3>=3.14.6 - found ===> firefox-53.0.3_1,1 depends on package: libnotify>0 - found ===> firefox-53.0.3_1,1 depends on executable: rustc - not found ===> Building for rust-1.17.0 gmake[7]: Entering directory '/usr/ports/lang/rust/work/rustc-1.17.0-src' "/usr/local/bin/python2.7" /usr/ports/lang/rust/work/rustc-1.17.0-src/src/bootstrap/bootstrap.py build -v info: looks like you are running this command under `sudo` and so in order to preserve your $HOME this will now use vendored sources by default. Note that if this does not work you should run a normal build first before running a command like `sudo make install` extracting /usr/ports/lang/rust/work/rustc-1.17.0-src/build/cache/ 2017-03-11/rust-std-1.16.0-x86_64-unknown-freebsd.tar.gz extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/lib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/manifest.in extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/lib/rustlib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/ librustc_llvm-74a1be1110b5d4d0.so gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src' *** Error code 1 Stop. make[6]: stopped in /usr/ports/lang/rust *** Error code 1 Stop. make[5]: stopped in /usr/ports/lang/rust *** Error code 1 Stop. make[4]: stopped in /usr/ports/www/firefox *** Error code 1 Stop. make[3]: stopped in /usr/ports/www/firefox *** Error code 1 Stop. make[2]: stopped in /usr/ports/www/firefox-i18n *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/firefox-i18n *** Error code 1 Stop. make: stopped in /usr/ports/www/firefox-i18n I am getting build failures with or without make_build_unsafe flags. I am building from source and ports tree is updated to revision 441919. Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
nvidia drivers mutex lock
I'm running nvidia-drivers 375.66 with a GTX 1070 on FreeBSD-Current This problem just started happening recently but, every so often my laptop screen will just blank out and then I have to power cycle to get the machine up and running again. It seems to be a problem with nvidia drivers acquiring duplicate lock. Any info on this? Jun 2 02:29:41 blubee kernel: acquiring duplicate lock of same type: "os.lock_mtx" Jun 2 02:29:41 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841 Jun 2 02:29:41 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841 Jun 2 02:29:41 blubee kernel: stack backtrace: Jun 2 02:29:41 blubee kernel: #0 0x80ab7770 at witness_debugger+0x70 Jun 2 02:29:41 blubee kernel: #1 0x80ab7663 at witness_checkorder+0xe23 Jun 2 02:29:41 blubee kernel: #2 0x80a35b93 at __mtx_lock_flags+0x93 Jun 2 02:29:41 blubee kernel: #3 0x82f4397b at os_acquire_spinlock+0x1b Jun 2 02:29:41 blubee kernel: #4 0x82c48b15 at _nv012002rm+0x185 Jun 2 02:29:41 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170303/nsarguments-205) Jun 2 02:29:42 blubee kernel: nvidia-modeset: Allocated GPU:0 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0 Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[Help] Linux low level data structures < - > FreeBSD low level data structures
Hello Is there anyone on either of these lists that have experience with both linux low level data structures and their equivalents on FreeBSD? For instance the linux header file: which includes the header file: Then looking at that file: I'll be doing a lot of work trying to find these FreeBSD equivalent of these types of files to port some code. Does anyone here have experience with something like this? Is there any other projects that maps these low level data structures from Linux <-> FreeBSD, etc? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [Help] Linux low level data structures < - > FreeBSD low level data structures
Hi Julian My goals are to port the Linux graphics stack over to FreeBSD w/o relying too heavily on the linuxkpi stuff. That's cool for a lot of use cases but it just seems a bit too brittle. It is a very large I understand the task will not be easy but I am willing to do the work, even from scratch if necessary although some help would be appreciated. I've been watching the Linux DRM project grow and while the top levels has changed, it's been a very long time since the actual low level stuff has been changed. Most of the diffs have shown changes in the [linux/driver/gpu/drm] layer which relies heavily on the [linux/include/drm] that does a lot of the heavy lifting here's a link to the latest version files: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm?h=v4.12-rc3 here's a diff of the latest version of the [linux/driver/gpu/drm] : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 The diffs in the drivers change constantly but the lower level stuff hasn't changed as much. Doing some of the lower level translation to native FreeBSD style data structures then the upper part could be easily migrated, even with something as using AST to translate the headers to their FreeBSD equivalent without worrying about inadvertently breaking something or having major diffs that needs people to actively look at maintaining. That's a high level overview of my plan and what I'd like to achieve. Will it be easy, most likely not but once it's done FreeBSD will be just fine. Hope that helps clarify things for anyone who is interested. Any assistance would be greatly appreciated. Best, Owen On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer wrote: > On 4/6/17 7:07 pm, blubee blubeeme wrote: > >> Hello >> >> Is there anyone on either of these lists that have experience with both >> linux low level data structures and their equivalents on FreeBSD? >> >> For instance the linux header file: >> >> >> which includes the header file: >> >> >> Then looking at that file: >> >> >> >> >> >> > > You are going to have to be a lot more specific about this. > I have worked in several places where they use s shim layer to make Linux > basic services work on freeBSD. > usually a mix of functions, macros and inlines. > However you need to narrow down your questions a bit as the POSSIBLE scope > of your question is too large for anyone to attempt an answer. > > Remember that both systems are POSIX inspired so outside the kernel there > are many more simlarities than one might be led to expect, > but you need to be way more specific. > It's even possible to write kernel code to run on both, but it is usually > domain specific. > > > >> I'll be doing a lot of work trying to find these FreeBSD equivalent of >> these types of files to port some code. >> >> Does anyone here have experience with something like this? Is there any >> other projects that maps these low level data structures from >> Linux <-> FreeBSD, etc? >> >> Best, >> Owen >> ___ >> freebsd-curr...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [Help] Linux low level data structures < - > FreeBSD low level data structures
＠Hans I've noticed these things about Linux. A lot of stuff relies on knowing the internals of the data structures instead of working with the API but I don't want to start all that stuff up. The goal is to lift up FreeBSD w/o tearing down Linux and as u know needing to be glued to the Linux data structures, while they always seem to be in flux is one reason why I want to steer clear from the linuxkpi stuff. I cam across the webcamd thing a while ago, it was written when Linux was not moving so fast if I remember correctly. This is a big challenge but I think once it's up and running it will bring some additional resources to FreeBSD that can bring the desktop world up to snuff with it's server acumen. Thanks for the tips though! Best, Owen On Mon, Jun 5, 2017 at 12:07 AM, Hans Petter Selasky wrote: > Hi Owen, > > The most comprehensive open-source wrappers for Linux kernel APIs in the > FreeBSD kernel is found at: > > https://github.com/FreeBSDDesktop/freebsd-base-graphics/ > tree/drm-next/sys/compat/linuxkpi > > The most comprehensive open-source wrappers for Linux kernel APIs in > FreeBSD user-space is found at: > > http://www.freshports.org/multimedia/webcamd > > I recommend you start with webcamd. Download the source code and look at > the sources. See if there is something you think you can improve. It is > much easier to debug using GDB and if something goes wrong it can easily be > restarted. > > When you have a working solution for webcamd, try to use the same solution > with the kernel. > > There is no simple 1:1 mapping for Linux APIs to FreeBSD APIs. Take for > example linux/list.h . You might think that a list can be re-implemented > and mapped to our sys/queue.h. But oh-no. Linux kernel code depends on all > the characteristics of list.h, how the structure members are stored and > named, and how foreach() macros complete with NULL or non-NULL in the > iterator. Further you'll find resistance among the Linux kernel developers > to support compilers different from GCC. I recently found a piece of code > in a header file, which works with GCC and causes a panic() when compiled > with clang. I reported it to one of the Linux kernel team members and they > didn't care about it. Even if you get everything compiling it doesn't it > will work :-( > > --HPS > > > On 06/04/17 16:35, blubee blubeeme wrote: > >> Hi Julian >> >> My goals are to port the Linux graphics stack over to FreeBSD w/o relying >> too heavily on the linuxkpi stuff. That's cool for a lot of use cases but >> it just seems a bit too brittle. >> >> It is a very large I understand the task will not be easy but I am willing >> to do the work, even from scratch if necessary although some help would be >> appreciated. >> >> I've been watching the Linux DRM project grow and while the top levels has >> changed, it's been a very long time since the actual low level stuff has >> been changed. Most of the diffs have shown changes in the >> [linux/driver/gpu/drm] layer which relies heavily on the >> [linux/include/drm] that does a lot of the heavy lifting here's a link to >> the latest version files: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/tree/include/drm?h=v4.12-rc3 >> >> here's a diff of the latest version of the [linux/driver/gpu/drm] : >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 >> >> The diffs in the drivers change constantly but the lower level stuff >> hasn't >> changed as much. >> >> Doing some of the lower level translation to native FreeBSD style data >> structures then the upper part could be easily migrated, even with >> something as using AST to translate the headers to their FreeBSD >> equivalent >> without worrying about inadvertently breaking something or having major >> diffs that needs people to actively look at maintaining. >> >> That's a high level overview of my plan and what I'd like to achieve. Will >> it be easy, most likely not but once it's done FreeBSD will be just fine. >> >> Hope that helps clarify things for anyone who is interested. Any >> assistance >> would be greatly appreciated. >> >> Best, >> Owen >> >> On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer >> wrote: >> >> On 4/6/17 7:07 pm, blubee blubeeme wrote: >>> >>> Hello >>>> >>>> Is there anyone on either of these lists that have experience with both >>>> linux low level data structures and their equivalents on Fre
Writing a port make deinstall
Hello FreeBSD ports team
I am writing a Makefile to install a port
I've written this much so far
PORTNAME= epson-inkjet-printer-201401w
PORTVERSION= 201401w
PORTREVISION= 1
PORTEPOCH= 0
CATEGORIES= print
MASTER_SITES=
https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/d95c03482376873661d7a8d4c165b385cd082cf3/:amd64
\
https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/0c527f1eef727e350302db951a45d31319ee501b/:i386
DISTFILES_amd64=
epson-inkjet-printer-201401w-1.0.0-1lsb3.2.x86_64.rpm:amd64
DISTFILES_i386=epson-inkjet-printer-201401w-1.0.0-1lsb3.2.i486.rpm:i386
LICENSE= GPLv2
DIST_SUBDIR= ${PORTNAME}/${PORTVERSION}
COMMENT= CUPS filter for Seiko Epson Color Ink Jet Printers
RESTRICTED= GNU Lesser General Public License version 2.1. \
This program links the following object codes \
which are distributed under the conditions of \
SEIKO EPSON CORPORATION SOFTWARE LICENSE AGREEMENT. \
*libEpson_201401w.so.1.0.0 \
*libEpson_201401w.MT.so.1.0.0
NO_BUILD= yes
NO_WRKSUBDIR= yes
PLIST_SUB= LINUXBASE=${LINUXBASE}
USES= linux
USE_LINUX= cups-libs jpeg
do-install:
(gunzip ${WRKSRC}/opt/${PORTNAME}/ppds/Epson/*)
(find ${WRKSRC}/opt/${PORTNAME}/ppds/Epson -type f -exec sed -i ""
's/\/opt\/epson/\/compat\/linux\/opt\/epson/g' {} \;)
(cp -r ${WRKSRC}/opt/${PORTNAME} /compat/linux/opt/)
(ln -s /compat/linux/opt/${PORTNAME}/ppds/Epson
/usr/local/share/cups/model/)
#cleanup?
# rm -r /usr/local/share/cups/model/Epson
# rm -r /compat/linux/opt/epson-inkjet-printer-201401w/
# rm -r ${WRKSRC}
.include
I don't know how to make the cleanup work.
This Makefile passes works for installing the drivers and they work but
doing
make deinstall clean
doesn't remove the files that I placed, the symlinks, etc.
How do I properly write this Makefile so deinstall works as expected?
Best,
Owen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Writing a port make deinstall
Oh,
Thank you both for the fast response. You'll definitely see me around these
parts more often.
Best,
Owen
On Wed, Jul 12, 2017 at 10:42 AM, Kubilay Kocak wrote:
> On 7/12/17 12:38 PM, blubee blubeeme wrote:
> > Hello FreeBSD ports team
> >
> > I am writing a Makefile to install a port
> >
> > I've written this much so far
> >
> > PORTNAME= epson-inkjet-printer-201401w
> > PORTVERSION= 201401w
> > PORTREVISION= 1
> > PORTEPOCH= 0
> > CATEGORIES= print
> > MASTER_SITES=
> > https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/
> d95c03482376873661d7a8d4c165b385cd082cf3/:amd64
> > \
> >
> > https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/
> 0c527f1eef727e350302db951a45d31319ee501b/:i386
> >
> > DISTFILES_amd64=
> > epson-inkjet-printer-201401w-1.0.0-1lsb3.2.x86_64.rpm:amd64
> > DISTFILES_i386=epson-inkjet-printer-201401w-
> 1.0.0-1lsb3.2.i486.rpm:i386
> >
> >
> > LICENSE= GPLv2
> > DIST_SUBDIR= ${PORTNAME}/${PORTVERSION}
> >
> > COMMENT= CUPS filter for Seiko Epson Color Ink Jet Printers
> >
> > RESTRICTED= GNU Lesser General Public License version 2.1. \
> >This program links the following object codes \
> > which are distributed under the conditions of \
> > SEIKO EPSON CORPORATION SOFTWARE LICENSE AGREEMENT. \
> > *libEpson_201401w.so.1.0.0 \
> > *libEpson_201401w.MT.so.1.0.0
> >
> >
> > NO_BUILD= yes
> > NO_WRKSUBDIR= yes
> > PLIST_SUB= LINUXBASE=${LINUXBASE}
> > USES= linux
> > USE_LINUX= cups-libs jpeg
> >
> > do-install:
> > (gunzip ${WRKSRC}/opt/${PORTNAME}/ppds/Epson/*)
> > (find ${WRKSRC}/opt/${PORTNAME}/ppds/Epson -type f -exec sed -i ""
> > 's/\/opt\/epson/\/compat\/linux\/opt\/epson/g' {} \;)
> > (cp -r ${WRKSRC}/opt/${PORTNAME} /compat/linux/opt/)
> > (ln -s /compat/linux/opt/${PORTNAME}/ppds/Epson
> > /usr/local/share/cups/model/)
> >
> > #cleanup?
> > # rm -r /usr/local/share/cups/model/Epson
> > # rm -r /compat/linux/opt/epson-inkjet-printer-201401w/
> > # rm -r ${WRKSRC}
> > .include
> >
> >
> > I don't know how to make the cleanup work.
> >
> > This Makefile passes works for installing the drivers and they work but
> > doing
> >
> > make deinstall clean
> >
> > doesn't remove the files that I placed, the symlinks, etc.
> >
> > How do I properly write this Makefile so deinstall works as expected?
> >
> > Best,
> > Owen
>
> Hi Owen,
>
> deinstall automatically works if and when all files/directories are
> correctly referenced in the pkg-plist. Writing a deinstallation
> procedure manually is not necessary.
>
> Porters Handbook:
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-
> handbook/book.html#porting-desc
>
> See Also: PLIST_FILES and other pkg-plist related entries
>
> Testing the port with poudriere and other tools will help you determine
> what is not working, in particular which files were installed but not
> referenced in the pkg-plist, and vice-versa.
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-
> handbook/testing.html
>
> For more help, there's also the #freebsd-ports IRC channel on freenode
>
> Hope that helps :)
>
> ./koobs
>
>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Making port check-plist errors
I am running into errors when trying to register the installation files.
The Makefile is pretty barebones, it looks like this so far:
PORTNAME=epson-inkjet-printer-201401w
PORTVERSION=201401w
PORTREVISION=1
PORTEPOCH=0
CATEGORIES=print
MASTER_SITES= https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/
d95c03482376873661d7a8d4c165b385cd082cf3/:amd64 \
https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/
0c527f1eef727e350302db951a45d31319ee501b/:i386
DISTFILES_amd64= epson-inkjet-printer-201401w-
1.0.0-1lsb3.2.x86_64.rpm:amd64
DISTFILES_i386=epson-inkjet-printer-201401w-1.0.0-1lsb3.2.i486.rpm:i386
LICENSE=LGPLv21
DIST_SUBDIR=${PORTNAME}/${PORTVERSION}
MAINTAINER=he...@blubee.me
COMMENT=CUPS filter for Seiko Epson Color Ink Jet Printers
RESTRICTED=GNU Lesser General Public License version 2.1. \
This program links the following object codes \
which are distributed under the conditions of \
SEIKO EPSON CORPORATION SOFTWARE LICENSE AGREEMENT. \
*libEpson_201401w.so.1.0.0 \
*libEpson_201401w.MT.so.1.0.0
NO_BUILD=yes
NO_WRKSUBDIR=yes
PLIST_SUB=LINUXBASE=${LINUXBASE}
USES=linux
USE_LINUX=cups-libs jpeg
do-install:
(echo ${WRKSRC})
(gunzip ${WRKSRC}/opt/${PORTNAME}/ppds/Epson/*)
(find ${WRKSRC}/opt/${PORTNAME}/ppds/Epson -type f -exec sed -i ""
's/\/opt\/epson/\/compat\/linux\/opt\/epson/g' {} \;)
(cp -r ${WRKSRC}/opt/${PORTNAME} /compat/linux/opt/)
(ln -sf /compat/linux/opt/${PORTNAME}/ppds/Epson
/usr/local/share/cups/model/)
(touch ./pkg-plist)
(find /compat/linux/opt/${PORTNAME} > ./pkg-plist)
(echo '/usr/local/share/cups/model/Epson' >> ./pkg-plist)
this is what the pkg-plist file looks like after that running make makeplist
cat ./pkg-plist
/compat/linux/opt/epson-inkjet-printer-201401w
/compat/linux/opt/epson-inkjet-printer-201401w/cups
/compat/linux/opt/epson-inkjet-printer-201401w/cups/lib
/compat/linux/opt/epson-inkjet-printer-201401w/cups/lib/filter
/compat/linux/opt/epson-inkjet-printer-201401w/cups/lib/filter/epson_inkjet_
printer_filter
/compat/linux/opt/epson-inkjet-printer-201401w/lib64
/compat/linux/opt/epson-inkjet-printer-201401w/lib64/
libEpson_201401w.so.1.0.0
/compat/linux/opt/epson-inkjet-printer-201401w/lib64/
libEpson_201401w.MT.so.1.0.0
/compat/linux/opt/epson-inkjet-printer-201401w/ppds
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/Epson
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L222_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L456_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L132_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L360_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L455_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L310_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L366_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L362_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L312_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L365_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L220_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/ppds/
Epson/Epson-L130_Series-epson-driver.ppd
/compat/linux/opt/epson-inkjet-printer-201401w/doc
/compat/linux/opt/epson-inkjet-printer-201401w/doc/README
/compat/linux/opt/epson-inkjet-printer-201401w/doc/Manual.txt
/compat/linux/opt/epson-inkjet-printer-201401w/doc/COPYING.EPSON
/compat/linux/opt/epson-inkjet-printer-201401w/doc/COPYING.LIB
/compat/linux/opt/epson-inkjet-printer-201401w/doc/COPYING
/compat/linux/opt/epson-inkjet-printer-201401w/doc/AUTHORS
/compat/linux/opt/epson-inkjet-printer-201401w/watermark
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG07.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG00.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG09.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG08.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG01.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG06.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG05.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG02.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG03.EID
/compat/linux/opt/epson-inkjet-printer-201401w/watermark/WEPCG04.EID
/compat/linux/opt/epson-inkjet-printer-201401w/resource
/compat/linux/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.MT.3.
data
/compat/linux/opt/epson-inkjet-printer-201401w/resource/Epson_
Re: Making port check-plist errors
/lib/filter
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/cups/lib/filter/epson_inkjet_printer_filter
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/AUTHORS
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/COPYING
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/COPYING.EPSON
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/COPYING.LIB
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/Manual.txt
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/doc/README
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/lib64
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/lib64/libEpson_201401w.MT.so.1.0.0
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/lib64/libEpson_201401w.so.1.0.0
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L130_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L132_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L220_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L222_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L310_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L312_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L360_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L362_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L365_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L366_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L455_Series-epson-driver.ppd
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/ppds/Epson/Epson-L456_Series-epson-driver.ppd
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.1.data
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.MT.1.data
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.MT.2.data
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.MT.3.data
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/resource/Epson_201401w.MT.4.data
Error: Missing: %%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG00.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG01.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG02.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG03.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG04.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG05.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG06.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG07.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG08.EID
Error: Missing:
%%LINUXBASE%%/opt/epson-inkjet-printer-201401w/watermark/WEPCG09.EID
Error: Missing: share/cups/model/Epson
===> Error: Plist issues found.
*** Error code 1
Stop.
make: stopped in /usr/ports/print/epson-inkjet-printer-201401w
I tried copying the work/epson-injket-2xxx to the stage dir with this
command
(cp -r ${WRKSRC}/opt/${PORTNAME} ${STAGEDIR}/${PORTNAME})
but that just produces a bunch of orphaned files but still failing.
Best,
Owen
On Wed, Jul 12, 2017 at 2:05 PM, Jov wrote:
> Hi
> you should use 'make makeplist' to generate pkg-plist file. make
> check-plist to verify to pkg-plist after make.
>
> 2017-07-12 13:46 GMT+08:00 blubee blubeeme :
>
>> I am running into errors when trying to register the installation files.
>>
>> The Makefile is pretty barebones, it looks like this so far:
>> PORTNAME=epson-inkjet-printer-201401w
>> PORTVERSION=201401w
>> PORTREVISION=1
>> PORTEPOCH=0
>> CATEGORIES=print
>> MASTER_SITES= https://download3.ebz.epson.net/dsc/f/03/00/03/45/41/
>> d95c03482376873661d7a8d4c165b385cd082cf3/:amd64
>> <https://download3.ebz.ep
updating cad/opencascade
Hey Is it possible to update cad/opencascade to version 7? Is there any dependencies on version 6? Best, Owen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: updating cad/opencascade
Andrea can you send the Makefile for that port? Thierry can you take a look at his Makefile and bring it up to snuff to get it into the ports tree to sort out the issues with FreeCAD? Best, Owen On Thu, Jul 13, 2017 at 9:07 PM, wrote: > Selon thie...@freebsd.org le jeu. 13 juil. 14:26:13 2017 : > > Can you put it in some PR on bugs.freebsd.org ? >>> >>> >> We allready have a port for it: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220110 >> > > Sorry, I meant a PR, not a port! > > -- > Th. Thomas. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
GNU Makefile to FreeBSD Makefile
Hey guys I am trying to port some software to FreeBSD it uses GNU Makefile convention that uses these variables all over the place. https://stackoverflow.com/questions/3220277/what-do-the-makefile-symbols-and-mean I understand what they mean all: library.cpp main.cpp - $@ evaluates to all - $< evaluates to library.cpp - $^ evaluates to library.cpp main.cpp The question is, how do I remove those to just use the proper filenames? They are in the Makefile.am, here's an example line. src=`echo $< | sed 's,^.*/,,; s,\.dat$$,,'`; \ dst=`echo $@ | sed 's,^.*/,,; s,\.dat$$,,'`; \ Does anyone have experience with this that can give me some guidance on this? Best, ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: GNU Makefile to FreeBSD Makefile
Hi Kurt Thanks for that hint, I am trying to port the project to FreeBSD. Let's see if I can get it properly ported. Best On Mon, Jul 31, 2017 at 6:25 PM, Kurt Jaeger wrote: > Hi! > > > I am trying to port some software to FreeBSD it uses GNU Makefile > > convention that uses these variables all over the place. > > If you are porting to FreeBSD as a port, use > > USES= gmake > > and the build process will use GNU make, so you do not need > to adapt all that stuff. > > -- > p...@opsec.eu+49 171 3101372 3 years to > go ! > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
LibreOffice FreeBSD landscape printing
Hello I am running into a printing bug with libreoffice : http://www.freshports.org/editors/libreoffice When I try to print, the options to select landscape is greyed out. It's locked in at portrait. Has anyone else experienced this issue? Best ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Python programs in a port
I installed libciangjie for the ibis on my local system: https://cangjians.github.io I was looking into turning it into a port. There's q libpython that acts as an interface to link ibus with libciangjie but I had to install that with pip. How do I handle that in the port? Do other ports that require python to install a package, how do they handle that? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Extra Clang Tools
FreeBSD switched to clang as it's compiler some time ago; was clang extra tools: http://clang.llvm.org/extra/index.html ever ported over? If yes, where is it located? Best ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Extra Clang Tools
Howdy I made a few changes to the devel/llvm40/Makefile and added pp-trace as the last line of EXTRA_COMMANDS Then I rebuilt llvm40, then I noticed that the pp-trace executable is built, here's a output of the work directory grepping for pp-trace: /usr/local/share/doc/llvm38/clang-tools/html/_sources/pp-trace.txt /usr/local/share/doc/llvm38/clang-tools/html/pp-trace.html /usr/local/share/doc/llvm39/clang-tools/html/_sources/pp-trace.txt /usr/local/share/doc/llvm39/clang-tools/html/pp-trace.html /usr/local/share/doc/llvm40/clang-tools/html/_sources/pp-trace.txt /usr/local/share/doc/llvm40/clang-tools/html/pp-trace.html /usr/ports/devel/llvm40/work/.build/bin/pp-trace /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/_doctrees-html/pp-trace.doctree /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/_doctrees-man/pp-trace.doctree /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/html/_sources/pp-trace.txt /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/docs/html/pp-trace.html /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir/PPCallbacksTracker.cpp.o /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/CMakeFiles/pp-trace.dir/PPTrace.cpp.o /usr/ports/devel/llvm40/work/.build/tools/clang/tools/extra/pp-trace/cmake_install.cmake /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/docs/pp-trace.rst /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/CMakeLists.txt /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPCallbacksTracker.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPCallbacksTracker.h /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/pp-trace/PPTrace.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level1A.h /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level1B.h /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level2A.h /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/Level2B.h /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/ModularizeList.txt /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/Inputs/module.map /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-conditional.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-ident.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-include.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-macro.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-modules.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-general.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-ms.cpp /usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/extra/test/pp-trace/pp-trace-pragma-opencl.cpp /usr/ports/devel/llvm40/work/stage/usr/local/share/doc/llvm40/clang-tools/html/_sources/pp-trace.txt /usr/ports/devel/llvm40/work/stage/usr/local/share/doc/llvm40/clang-tools/html/pp-trace.html So it now gets built but not installed; is it possible to have the port updated to move these files to the proper after they are built? I made a one line change to the Makefile: # $FreeBSD: head/devel/llvm40/Makefile 449591 2017-09-10 20:55:38Z gerald $ EXTRAS_COMMANDS+= \ clang-apply-replacements \ clang-change-namespace \ clang-include-fixer \ clang-modernize \ clang-query \ clang-rename \ clang-reorder-fields \ clang-tidy \ find-all-symbols \ modularize \ pp-trace #===# My edit Best On Sat, Sep 16, 2017 at 2:01 PM, Shane Ambler wrote: > On 16/09/2017 11:59, blubee blubeeme wrote: > >> FreeBSD switched to clang as it's compiler some time ago; was clang extra >> tools: http://clang.llvm.org/extra/index.html ever ported over? >> >> If yes, where is it located? >> > > You will find them included in the llvm ports with EXTRAS enabled > > clang-tidy is in llvm 3.8+ > clang-include-fixer is in llvm 3.9+ > modularize is in llvm 3.8+
Re: Extra Clang Tools
Bug created: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222380 Can someone take a look? Different email addresses; it's fine I had the bug created. Best On Sun, Sep 17, 2017 at 11:44 AM, Shane Ambler wrote: > On 16/09/2017 23:22, blubee blubeeme wrote: > >> Howdy >> >> I made a few changes to the devel/llvm40/Makefile and added pp-trace as >> the >> last line of EXTRA_COMMANDS >> >> Then I rebuilt llvm40, then I noticed that the pp-trace executable is >> built, here's a output of the work directory grepping for pp-trace: >> > > >> >> So it now gets built but not installed; is it possible to have the port >> updated to move these files to the proper after they are built? >> > > Create a new report at https://bugs.freebsd.org with a patch for the > Makefile and pkg-plist. While the pp-trace binary has not been included, > the docs for it are already in the existing packages, the makefile is > done in a way that adding it to the command list adds it to the package. > > To make the following patch you would use > diff -udp Makefile.orig Makefile > diff -udp pkg-plist.orig pkg-plist > > --- Makefile.orig 2017-09-17 13:02:06.907563000 +0930 > +++ Makefile2017-09-17 13:02:16.043096000 +0930 > @@ -164,7 +164,8 @@ EXTRAS_COMMANDS+= \ > clang-reorder-fields \ > clang-tidy \ > find-all-symbols \ > - modularize > + modularize \ > + pp-trace > EXTRAS_LIBS= libclangApplyReplacements \ > libclangChangeNamespace \ > libclangIncludeFixer \ > --- pkg-plist.orig 2017-05-26 17:46:41.237943000 +0930 > +++ pkg-plist 2017-09-17 12:46:44.526703000 +0930 > @@ -58,6 +58,7 @@ bin/sancov%%LLVM_SUFFIX%% > %%EXTRAS%%bin/clang-tidy%%LLVM_SUFFIX%% > %%EXTRAS%%bin/find-all-symbols%%LLVM_SUFFIX%% > %%EXTRAS%%bin/modularize%%LLVM_SUFFIX%% > +%%EXTRAS%%bin/pp-trace%%LLVM_SUFFIX%% > %%LLD%%bin/lld%%LLVM_SUFFIX%% > %%LLD%%bin/lld-link%%LLVM_SUFFIX%% > %%LIT%%bin/lit%%LLVM_SUFFIX%% > > > > -- > FreeBSD - the place to B...Software Developing > > Shane Ambler > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster, portupgrade, etc
Interesting thread, I've learned more about FreeBSD build here than almost anywhere else. Thanks OP for the email. On Thu, Oct 5, 2017, 09:14 Adam Weinberger wrote: > > On 4 Oct, 2017, at 10:16, Michael W. Lucas > wrote: > > > > Hi, > > > > I'm doing tech edits on the new edition of "Absolute FreeBSD," and > > stumbled into what's apparently a delicate topic. > > > > Some of my reviewers are happy I included portmaster in the book. > > > > Some reviewers beg me not to include it. > > > > Unfortunately, people will be reading af3e and considering it > > definitive for the next several years. So I have to get a feel for > > where things are going. :-/ > > > > I've read a couple threads on portmaster's current problems/growing > > pains and its looming difficulty with forthcoming flavors. > > > > I've been a happy portmaster user for many years now. All things being > > equal, if its future is still being debated I'm inclined to keep it in > > the book. > > > > Poudriere really needs its own small book. Yes, you can do simple > > poudriere installs, but once you start covering it properly the docs > > quickly expand. My notes alone are longer than my af3e chapter > > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in > > 2018). > > > > Truly, I'm not looking to start a flame war here. I only want a bit of > > guidance on The Future... > > > > ==ml > > Hi Michael, > > Poudriere is indeed intended to be the canonical port building and > management tool. It is what essentially the entire ports committer team > uses, it's what the clusters build with, and it is where support for new > features land first. > > Portmaster is a tried-and-tested tool for automating port builds. > Poudriere wants to be everything to everybody, but portmaster is as simple > to use as possible. The current issue is that portmaster is no longer > actively developed. Major new features are about to land in the ports tree, > and portmaster will either not support them, or will break entirely. > > The official message is that everybody for whom Poudriere's workflow works > should migrate to Poudriere to avoid the impending breakage. > > Portmaster is still very much a part of the current landscape, and if > somebody steps in to fix it (which I have every expectation will happen > eventually), it will continue being a usable alternative. > > # Adam > > > -- > Adam Weinberger > ad...@adamw.org > https://www.adamw.org > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster, portupgrade, etc
I'd vote to have Chris H be the maintainer of this port. Why knock the guy if he wants to invest his time and energy into doing something to help the project? Does it cause anyone pain to see someone working on maintaining the project? Why would someone say no you cannot maintain this port, especially when no one else is doing the work? The only best way I've ever seen to find a really good developer is find someone with dedication and willingness to take on hard challenges and stick to it. Chris seems like that type of person, who would deny the man a chance to donate his time to the FreeBSD project? Who would stand up and say, no Chris you can't maintain the port and why? On Fri, Oct 6, 2017 at 11:26 AM, Kurt Jaeger wrote: > Hi! > > > > a few inquiries regarding taking maintainer for the port. My request > > > was ultimately declined. I was deemed unqualified. That judgement was > > > unfounded. :( > > Right now, tz@ is the maintainer of ports-mgmt/portmaster. > > If someone wants to become maintainer, the best way is to > look at the open PRs: > > https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster > > verify their status and provide patches. > > -- > p...@opsec.eu+49 171 3101372 3 years to > go ! > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting github code to FreeBSD [configure]
I'm trying to port some code from github to FreeBSD but I run into a few issues; 1) The project needs to use gnu make, gnu sed and other gnu tools since it uses the gnu version of @< for variable names 2) The project also uses autoreconf because there's .am and .in files I can pull the files down and run autoreconf that seems to populate the proper files but then I need to run the configure script then the make command as well but I am running into issues there. In my Makefile, I added this line: USES= autoreconf gmake .include # post-extract: # post-patch: # do-install: .include connexions/Makefile.am: installing 'upstream/depcomp' parallel-tests: installing 'upstream/test-driver' ===> Building for utsushi-1.0.0 gmake[1]: Entering directory '/usr/ports/graphics/tmp/work/test' gmake[1]: Makefile: No such file or directory gmake[1]: *** No rule to make target 'Makefile'. Stop. gmake[1]: Leaving directory '/usr/ports/graphics/tmp/work/test' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code What do I need to add to my uses command to get things to proceed? Doing things by hand I have to follow these steps: change to the download folder and run: autoreconf -fi ./configure make ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting github code to FreeBSD [configure]
I figured out the configure script part by adding: GNU_CONFIGURE= yes and that works fine so far. I also found that I could use build_depends macro and I added this line below BUILD_DEPENDS= gsed:textproc/gsed but looking at the output command, the build steps is still attempting to use regular sed, you can see the error here: On Sun, Oct 15, 2017 at 6:44 PM, blubee blubeeme wrote: > I'm trying to port some code from github to FreeBSD but I run into a few > issues; > > 1) The project needs to use gnu make, gnu sed and other gnu tools since it > uses the gnu version of @< for variable names > 2) The project also uses autoreconf because there's .am and .in files > > I can pull the files down and run autoreconf that seems to populate the > proper files but then I need to run the configure script then the make > command as well but I am running into issues there. > > > In my Makefile, I added this line: > USES= autoreconf gmake > > .include > > # post-extract: > # post-patch: > # do-install: > > .include > > connexions/Makefile.am: installing 'upstream/depcomp' > parallel-tests: installing 'upstream/test-driver' > ===> Building for utsushi-1.0.0 > gmake[1]: Entering directory '/usr/ports/graphics/tmp/work/test' > gmake[1]: Makefile: No such file or directory > gmake[1]: *** No rule to make target 'Makefile'. Stop. > gmake[1]: Leaving directory '/usr/ports/graphics/tmp/work/test' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code > > What do I need to add to my uses command to get things to proceed? Doing > things by hand I have to follow these steps: > > change to the download folder and run: > autoreconf -fi > ./configure > make > > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting github code to FreeBSD [configure]
trigger happy missed sending the error:
format=`echo tmp/tag.hpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
sed -n \
-e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
tmp/tag.hpp; \
xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
tmp/tag.hpp
format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
sed -n \
-e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
lib/tag.cpp; \
xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
lib/tag.cpp
sed -i 's/SEC_N_("%1%")/"%1%"/' tmp/tag.hpp
sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
sed: 1: "tmp/tag.hpp": invalid command code u
sed: 1: "lib/tag.cpp": extra characters at the end of l command
You can see the FreeBSD version of sed failing on the commands, If I
remember correctly this requires gnu sed to work properly.
How can I set that in my Makefile?
On Sun, Oct 15, 2017 at 7:22 PM, blubee blubeeme
wrote:
> I figured out the configure script part by adding: GNU_CONFIGURE= yes
> and that works fine so far.
>
> I also found that I could use build_depends macro and I added this line
> below
> BUILD_DEPENDS= gsed:textproc/gsed
>
> but looking at the output command, the build steps is still attempting to
> use regular sed, you can see the error here:
>
>
> On Sun, Oct 15, 2017 at 6:44 PM, blubee blubeeme
> wrote:
>
>> I'm trying to port some code from github to FreeBSD but I run into a few
>> issues;
>>
>> 1) The project needs to use gnu make, gnu sed and other gnu tools since
>> it uses the gnu version of @< for variable names
>> 2) The project also uses autoreconf because there's .am and .in files
>>
>> I can pull the files down and run autoreconf that seems to populate the
>> proper files but then I need to run the configure script then the make
>> command as well but I am running into issues there.
>>
>>
>> In my Makefile, I added this line:
>> USES= autoreconf gmake
>>
>> .include
>>
>> # post-extract:
>> # post-patch:
>> # do-install:
>>
>> .include
>>
>> connexions/Makefile.am: installing 'upstream/depcomp'
>> parallel-tests: installing 'upstream/test-driver'
>> ===> Building for utsushi-1.0.0
>> gmake[1]: Entering directory '/usr/ports/graphics/tmp/work/test'
>> gmake[1]: Makefile: No such file or directory
>> gmake[1]: *** No rule to make target 'Makefile'. Stop.
>> gmake[1]: Leaving directory '/usr/ports/graphics/tmp/work/test'
>> ===> Compilation failed unexpectedly.
>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure
>> to
>> the maintainer.
>> *** Error code
>>
>> What do I need to add to my uses command to get things to proceed? Doing
>> things by hand I have to follow these steps:
>>
>> change to the download folder and run:
>> autoreconf -fi
>> ./configure
>> make
>>
>>
>>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting github code to FreeBSD [configure]
Hey
That was cool and solved the issue real fast!
Thanks you
On Sun, Oct 15, 2017 at 7:30 PM, Romain Tartière wrote:
> On Sun, Oct 15, 2017 at 07:23:49PM +0800, blubee blubeeme wrote:
> > trigger happy missed sending the error:
> >
> > format=`echo tmp/tag.hpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
> > sed -n \
> > -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
> > tmp/tag.hpp; \
> > xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
> > tmp/tag.hpp
> > format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
> > sed -n \
> > -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
> > lib/tag.cpp; \
> > xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
> > lib/tag.cpp
> > sed -i 's/SEC_N_("%1%")/"%1%"/' tmp/tag.hpp
> > sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
> > sed: 1: "tmp/tag.hpp": invalid command code u
> > sed: 1: "lib/tag.cpp": extra characters at the end of l command
> >
> > You can see the FreeBSD version of sed failing on the commands, If I
> > remember correctly this requires gnu sed to work properly.
> >
> > How can I set that in my Makefile?
>
> The easiest way could be BINARY_ALIAS introducted a few days ago:
> https://svnweb.freebsd.org/ports?view=revision&revision=451772
>
> --
> Romain Tartière http://people.FreeBSD.org/~romain/
> pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
> (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
configure scripts and dlopen
I am running into some compiling/ linking errors further along in my porting process so I re-checked the configure step. It seems to be that the issue is related to dlopen. What configure options can I pass to use the standard FreeBSD dlopen equivalent calls? The gmake error occurs here: gmake[4]: Entering directory '/usr/ports/dev/tmp/work/tmp-c590592/upstream/ltdl' CC loaders/dlopen.lo CC loaders/libltdlc_la-preopen.lo CC libltdlc_la-lt__alloc.lo CC libltdlc_la-lt_dlloader.lo CC libltdlc_la-lt_error.lo CC libltdlc_la-ltdl.lo CC libltdlc_la-slist.lo CC lt__argz.lo In file included from lt__alloc.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. In file included from lt_dlloader.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. In file included from loaders/dlopen.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. In file included from lt_error.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. In file included from ltdl.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. gmake[4]: *** [Makefile:788: libltdlc_la-lt__alloc.lo] Error 1 gmake[4]: *** Waiting for unfinished jobs gmake[4]: *** [Makefile:795: libltdlc_la-lt_dlloader.lo] Error 1 In file included from loaders/preopen.c:32:0: libltdl/lt__private.h:35:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. gmake[4]: *** [Makefile:731: loaders/dlopen.lo] Error 1 gmake[4]: *** [Makefile:802: libltdlc_la-lt_error.lo] Error 1 gmake[4]: *** [Makefile:809: libltdlc_la-ltdl.lo] Error 1 gmake[4]: *** [Makefile:781: loaders/libltdlc_la-preopen.lo] Error 1 lt__argz.c:33:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H ^ compilation terminated. In file included from libltdl/slist.h:46:0, from slist.c:34: ./libltdl/lt__glibc.h:36:23: fatal error: config.h: No such file or directory # include LT_CONFIG_H There is a config.h file in the root of my source files, here's the contents: https://pastebin.com/j7uAJGw6 This is the output of the configure script: --- checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '0' is supported by ustar format... yes checking whether GID '0' is supported by ustar format... yes checking how to create a ustar tar archive... (cached) /usr/bin/tar checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... (cached) yes checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking whether cc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking for cc option to support OpenMP... unsupported checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking standard compliance level of c++... 199711L checking for ar... ar checking the archiver (ar) interface... ar checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for a sed that does not truncate output... (cached) /usr/bin/sed checking whether NLS is requested... yes checking for msgfmt... /usr/local/bin/msgfmt checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for msgmerge... /usr/local/bin/msgmerge checking build system type... amd64-portbld-freebsd12.0 checking host system type... amd64-portbld-freebsd12.0 checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... (cached) /usr/bin/egrep checking for CFPreferenc
Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?
I just ran into this issue yesterday myself. To find the tagname I went to the project in githib, looked at their committed files and found the one with the latest date. Click on that file, then you'll see three buttons in the upper right hand side; raw, blame, history. Click on history and you'll see the tagnames on the right have column. Copy that to your GH_TAGNAME in the makefile and you should be fine. There are ways to get the tagname from git but that's if you've cloned the repo locally which I didn't want to bother doing. Best On Mon, Oct 16, 2017, 04:58 Yuri wrote: > On 10/15/17 12:47, O. Hartmann wrote: > > all right, that is what I picked up from the porter's handbook, but I > must have > > overlooked the note (if there is anything like that) regarding the > sufficient first 7 > > digits. > > If you look at other ports, most use 7 digits. > > > I tried this earlier (yes, and I do also a make makesum ;-))), but I get > a complete > > different "structure" right now - no tarball which contains exactly > OpenCL 2.1 or OpenCL > > 2.2 (the one I'd like to download), but a complete hierarchie of the CL > sources, starting > > from OpenCL 1.0 to OpenCL 2.2. Either, there has been a change in the > way OpenCL headers > > are provided, or there is a magic trick to download, depending on the > GH_TAGNAME, a > > tarball ending in "*_GH0.tar.xz" > > > The version downloaded using GH_TAGNAME should have the same structure > as releases, unless the project structure itself has been radically > changed between releases. The top folder name is going to be different > for GH_TAGNAME. A release is just an alpa-numeric tag in a sequence of > commits, nothing more. > > > Yuri > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
gnu ltdl and FreeBSD
I'm trying to port some software that keeps failing when it tries to find a config.h. I know the config.h file is there but I think the compilation is failing because it's trying to build ltdl and freebsd doesn't need that since freebsd already has dlopen in libc. Which configure flag could I try to get rid of building that lib? The full configure --help file is below. My current makefile has these settings: HAS_CONFIGURE= yes CONFIGURE_ARGS= --without-included-ltdl --disable-ltdl-install USES=autoreconf gmake the compilation fails with these errors: Making all in upstream/ltdl gmake[3]: Entering directory '/usr/ports/dev/tmp/work/tmp-c590592/upstream/ltdl' GEN libltdl/lt__argz.h gmake all-am gmake[4]: Entering directory '/usr/ports/dev/tmp/work/tmp-c590592/upstream/ltdl' CC loaders/dlopen.lo In file included from loaders/dlopen.c:32: libltdl/lt__private.h:35:12: fatal error: 'config.h' file not found # include LT_CONFIG_H ^ :2:21: note: expanded from here #define LT_CONFIG_H ^~ 1 error generated. gmake[4]: *** [Makefile:731: loaders/dlopen.lo] Error 1 gmake[4]: Leaving directory '/usr/ports/dev/tmp/work/tmp-c590592/upstream/ltdl' gmake[3]: *** [Makefile:561: all] Error 2 gmake[3]: Leaving directory '/usr/ports/dev/tmp/work/tmp-c590592/upstream/ltdl' gmake[2]: *** [Makefile:605: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/ports/dev/tmp/work/tmp-c590592' gmake[1]: *** [Makefile:513: all] Error 2 gmake[1]: Leaving directory '/usr/ports/dev/tmp/work/tmp-c590592' *** Error code 1 Stop. make: stopped in /usr/ports/dev/tmp To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. Configuration: -h, --help display this help and exit --help=shortdisplay options specific to this package --help=recursivedisplay the short help of all the included packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking ...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIRfind the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIRuser executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIRprogram executables [EPREFIX/libexec] --sysconfdir=DIRread-only single-machine data [PREFIX/etc] --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIRobject code libraries [EPREFIX/lib] --includedir=DIRC header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIRman documentation [DATAROOTDIR/man] --docdir=DIRdocumentation root [DATAROOTDIR/doc/tmp] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIRdvi documentation [DOCDIR] --pdfdir=DIRpdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] Program names: --program-prefix=PREFIXprepend PREFIX to installed program names --program-suffix=SUFFIXappend SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] Optional Features: --disable-option-checking ignore unrecognized --enable/--with options --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --enable-test-reports generate XML test reports [no]. Implies --with-boost-unit-test-framework. XML test reports
Re: gnu ltdl and FreeBSD
This is what the Makefile looks like, the file still fails: LICENSE= GPLv3+ BUILD_DEPENDS= gsed:textproc/gsed BINARY_ALIAS=sed=gsed LIB_DEPENDS= libltdl.so:devel/libltdl GNU_CONFIGURE= yes USES=autoreconf gmake same compile error. That config.h should be auto generated and setup by autoreconf but its not. On Mon, Oct 16, 2017 at 4:07 PM, Baptiste Daroussin wrote: > On Mon, Oct 16, 2017 at 05:37:57AM +0000, blubee blubeeme wrote: > > I'm trying to port some software that keeps failing when it tries to > find a > > config.h. > > > > I know the config.h file is there but I think the compilation is failing > > because it's trying to build ltdl and freebsd doesn't need that since > > freebsd already has dlopen in libc. > > > > Which configure flag could I try to get rid of building that lib? The > full > > configure --help file is below. > > > > My current makefile has these settings: > > HAS_CONFIGURE= yes > > CONFIGURE_ARGS= --without-included-ltdl --disable-ltdl-install > > USES=autoreconf gmake > > First this is wrong, if you have USES=autoreconf it means you are using GNU > configure, so s/HAS_CONFIGURE/GNU_CONFIGURE/g > > Do you have libltdl.so:devel/libltdl in your LIB_DEPENDS line > > Bapt > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gnu ltdl and FreeBSD
/ltdl.m4:200:
_LT_SHELL_INIT([lt_dlopen_dir=$lt_ltdl_dir])],
work/utsushi-c590592/upstream/aclocal/ltdl.m4:201: [nonrecursive],
[_LT_SHELL_INIT([lt_dlopen_dir=$lt_ltdl_dir;
lt_libobj_prefix=$lt_ltdl_dir/])],
work/utsushi-c590592/upstream/aclocal/ltdl.m4:669: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"],
work/utsushi-c590592/upstream/aclocal/ltdl.m4:677:
LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"],
work/utsushi-c590592/upstream/aclocal/ltdl.m4:682: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la"])])])
work/utsushi-c590592/upstream/aclocal/ltdl.m4:696: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"],
work/utsushi-c590592/upstream/aclocal/ltdl.m4:700:
LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}shl_load.la"
work/utsushi-c590592/upstream/aclocal/ltdl.m4:710: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dyld.la"])
work/utsushi-c590592/upstream/aclocal/ltdl.m4:713:
LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}load_add_on.la"
work/utsushi-c590592/upstream/aclocal/ltdl.m4:717:
LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}loadlibrary.la"
work/utsushi-c590592/upstream/aclocal/ltdl.m4:724: LT_DLLOADERS="$LT_DLLOADERS
${lt_dlopen_dir+$lt_dlopen_dir/}dld_link.la"])
work/utsushi-c590592/upstream/ltmain.sh.bak:8021: # Otherwise, use the
dlname, so that lt_dlopen finds it.
work/utsushi-c590592/upstream/ltmain.sh:8021: # Otherwise, use the
dlname, so that lt_dlopen finds it.
work/utsushi-c590592/upstream/ltdl/loaders/dlopen.c:70: vtable->name =
"lt_dlopen";
work/utsushi-c590592/upstream/ltdl/loaders/preopen.c:366: lt_dlhandle
handle = lt_dlopen (symbol->name);
work/utsushi-c590592/upstream/ltdl/ltdl.h:77:LT_SCOPE lt_dlhandle
lt_dlopen (const
char *filename);
work/utsushi-c590592/upstream/ltdl/ltdl.h:78:LT_SCOPE lt_dlhandle
lt_dlopenext (const char *filename);
work/utsushi-c590592/upstream/ltdl/ltdl.h:79:LT_SCOPE lt_dlhandle
lt_dlopenadvise (const char *filename,
work/utsushi-c590592/upstream/ltdl/ltdl.h:134: int ref_count; /* number of
times lt_dlopened minus
work/utsushi-c590592/upstream/ltdl/ltdl.c:243: can use _them_ to lt_dlopen
its own modules. */
work/utsushi-c590592/upstream/ltdl/ltdl.c:953: cur->deplibs[j] =
lt_dlopenext(names[depcount-1-i]);
work/utsushi-c590592/upstream/ltdl/ltdl.c:1624:lt_dlopen (const char
*filename)
work/utsushi-c590592/upstream/ltdl/ltdl.c:1626: return lt_dlopenadvise
(filename, NULL);
work/utsushi-c590592/upstream/ltdl/ltdl.c:1635:lt_dlopenext (const char
*filename)
work/utsushi-c590592/upstream/ltdl/ltdl.c:1641:handle = lt_dlopenadvise
(filename, advise);
work/utsushi-c590592/upstream/ltdl/ltdl.c:1649:lt_dlopenadvise (const char
*filename, lt_dladvise advise)
work/utsushi-c590592/upstream/ltdl/ltdl.c:1899: passing to lt_dlopenext.
The extensions are stripped so that
work/utsushi-c590592/upstream/ltdl/ltdl.c:1902: then the same directories
that lt_dlopen would search are examined. */
It's still pretty much the same error
gmake[4]: Entering directory
'/usr/ports/graphics/utsushi/work/utsushi-c590592/upstream/ltdl'
/bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
-DLTDLOPEN=libltdl -DLT_CONFIG_H='' -DLTDL -I. -I. -Ilibltdl
-I./libltdl -I/usr/local/include -I/usr/local/include -O2 -pipe
-fstack-protector -fno-strict-aliasing -MT loaders/libltdl_la-preopen.lo
-MD -MP -MF loaders/.deps/libltdl_la-preopen.Tpo -c -o
loaders/libltdl_la-preopen.lo `test -f 'loaders/preopen.c' || echo
'./'`loaders/preopen.c
libtool: compile: cc -DHAVE_CONFIG_H -DLTDLOPEN=libltdl
"-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl -I./libltdl
-I/usr/local/include -I/usr/local/include -O2 -pipe -fstack-protector
-fno-strict-aliasing -MT loaders/libltdl_la-preopen.lo -MD -MP -MF
loaders/.deps/libltdl_la-preopen.Tpo -c loaders/preopen.c -fPIC -DPIC -o
loaders/.libs/libltdl_la-preopen.o
In file included from loaders/preopen.c:32:
libltdl/lt__private.h:35:12: fatal error: 'config.h' file not found
# include LT_CONFIG_H
^
:3:21: note: expanded from here
#define LT_CONFIG_H
On Mon, Oct 16, 2017 at 4:50 PM, Baptiste Daroussin
wrote:
> On Mon, Oct 16, 2017 at 08:25:57AM +, blubee blubeeme wrote:
> > This is what the Makefile looks like, the file still fails:
> >
> > LICENSE= GPLv3+
> > BUILD_DEPENDS= gsed:textproc/gsed
> >
> > BINARY_ALIAS=sed=gsed
> >
> > LIB_DEPENDS= libltdl.so:devel/libltdl
> > GNU_CONFIGURE= yes
> > USES=autoreconf gmake
> >
> > same compile error.
> > That config.h should be auto generated and setup by autoreconf but its
> not.
>
> The config.h is not setup by autoreconf neither generated by autoreconf.
> the run
> of the configure script should generated it except if it fails. Have you
> read
> the config.log (very long and verbose script that explains what happened -
> including failures - during the run of the configure script)
>
> Also you should add "libtool" to your USES line
>
> Best regards,
> Bapt
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gnu ltdl and FreeBSD
@Baptiste adding localbase to the USES macros made it past the previous errors. The compilation fails with this error: gmake[4]: Entering directory '/usr/ports/graphics/utsushi/work/utsushi-c590592/lib' depbase=`echo connexion.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include -DPKGLIBEXECDIR="\"/usr/local/libexec/utsushi\"" -DPKGLIBDIR="\"/usr/local/lib/utsushi\"" -DPKGDATADIR="\"/usr/local/share/utsushi\"" -DLOCALEDIR="\"/usr/local/share/locale\"" -DPKGSYSCONFDIR="\"/usr/local/etc/utsushi\"" -DPKGCONFFILE="\"utsushi.conf\"" -DCOMBOCONFFILE="\"combo.conf\"" -isystem /usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Werror -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -MT connexion.lo -MD -MP -MF $depbase.Tpo -c -o connexion.lo connexion.cpp &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include -DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\" -DPKGLIBDIR=\"/usr/local/lib/utsushi\" -DPKGDATADIR=\"/usr/local/share/utsushi\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\" -DPKGCONFFILE=\"utsushi.conf\" -DCOMBOCONFFILE=\"combo.conf\" -isystem /usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Werror -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -MT connexion.lo -MD -MP -MF .deps/connexion.Tpo -c connexion.cpp -fPIC -DPIC -o .libs/connexion.o In file included from connexion.cpp:44: ../utsushi/log.hpp:155:36: error: instantiation of variable 'utsushi::log::basic_logger >::os_' required here, but no definition is available [-Werror,-Wundefined-var-template] basic_logger::os_ << *this; ^ ../utsushi/log.hpp:265:23: note: in instantiation of member function 'utsushi::log::basic_message, std::__1::allocator >::~basic_message' requested here expand_named_ctors (fatal, FATAL); ^ ../utsushi/log.hpp:49:47: note: forward declaration of template entity is here static std::basic_ostream& os_; ^ 1 error generated. looking through the config.log files I see many similar errors such as: /usr/bin/ld: cannot find -lusb-1.0 cc: error: linker command failed with exit code 1 (use -v to see invocation) configure:24532: $? = 1 configure:15640: result: no configure:15644: checking for shl_load in -ldld configure:15669: cc -o conftest -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -I/usr/local/include -fstack-protector -L/usr/local/lib conftest.c -ldld >&5 /usr/bin/ld: cannot find -ldld configure:19867: cc -o conftest -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -I/usr/local/include -fstack-protector -L/usr/local/lib conftest.c -ldld >&5 /usr/bin/ld: cannot find -ldld cc: error: linker command failed with exit code 1 (use -v to see invocation) are those the reasons for the compilation error up above? On Mon, Oct 16, 2017 at 5:09 PM, Baptiste Daroussin wrote: > On Mon, Oct 16, 2017 at 08:58:32AM +, blubee blubeeme wrote: > > I've tried passing CONFIGURE_ARGS or removing it, both gives the same > error > > below. > > LIB_DEPENDS= libltdl.so:devel/libltdl > > GNU_CONFIGURE= yes > > CONFIGURE_ARGS= --enable-ltdl-install > > USES=autoreconf gmake libtool > > > > the config.log file is there and it's pretty long as well I am looking > > through it but I am not sure what exactly to look for. > > > > Here's a pastebin with that config.log file: > https://pastebin.com/NjkgBTeM > > configure:20354: cc -o conftest -O2 -pipe -fstack-protector > -fno-strict-aliasing -I/usr/local/include -fstack-protector conftest.c > -lltdl > >&5 > /usr/bin/ld: cannot find -lltdl > > > this is your failure. > > Try adding USES=localbase and if it fails adding USES=localbase:ldflags > > Bapt > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gnu ltdl and FreeBSD
I had an idea that maybe the port was failing because of Clang compiler, so
I looked through the porters handbook and found
USE_GCC
this prompted me to install gcc 6.2 which i think is a little overkill plus
it also installed a few other packages as well. The build went through and
failed at this step trying to install
how can I control which version of gcc to use? I think this project should
build fine with gcc 4.8
install -m 0644 ./iconv.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv.3
install -m 0644 ./iconv_close.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_close.3
install -m 0644 ./iconv_open.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_open.3
install -m 0644 ./iconv_open_into.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconv_open_into.3
install -m 0644 ./iconvctl.3
/usr/ports/converters/libiconv/work/stage/usr/local/man/man3/iconvctl.3
if [ ! -d
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv ] ;
then /bin/sh ../build-aux/mkinstalldirs
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv ; fi
mkdir /usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv
builddir="`pwd`"; cd . && for f in *.html ; do (cd "$builddir"; echo
install -m 0644 ./$f
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/$f ;
install -m 0644 ./$f
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/$f)
; done
install -m 0644 ./iconv.1.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv.1.html
install -m 0644 ./iconv.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv.3.html
install -m 0644 ./iconv_close.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_close.3.html
install -m 0644 ./iconv_open.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_open.3.html
install -m 0644 ./iconv_open_into.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconv_open_into.3.html
install -m 0644 ./iconvctl.3.html
/usr/ports/converters/libiconv/work/stage/usr/local/share/doc/libiconv/iconvctl.3.html
> Compressing man pages (compress-man)
> Running Q/A tests (stage-qa)
Warning: 'lib/libcharset.so.1.0.0' is not stripped consider trying
INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'lib/libiconv.so.2.5.1' is not stripped consider trying
INSTALL_TARGET=install-strip or using ${STRIP_CMD}
===> Installing for libiconv-1.14_11
===> Checking if libiconv already installed
===> An older version of libiconv is already installed (libiconv-1.14_10)
You may wish to ``make deinstall'' and install this port again
by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of libiconv
without deleting it first, set the variable "FORCE_PKG_REGISTER"
in your environment or the "make install" command line.
*** Error code 1
Stop.
make[4]: stopped in /usr/ports/converters/libiconv
*** Error code 1
On Mon, Oct 16, 2017 at 5:50 PM, blubee blubeeme
wrote:
> @Baptiste
>
> adding localbase to the USES macros made it past the previous errors. The
> compilation fails with this error:
>
> gmake[4]: Entering directory '/usr/ports/graphics/utsushi/
> work/utsushi-c590592/lib'
> depbase=`echo connexion.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I..
> -pthread -I/usr/local/include
> -DPKGLIBEXECDIR="\"/usr/local/libexec/utsushi\""
> -DPKGLIBDIR="\"/usr/local/lib/utsushi\""
> -DPKGDATADIR="\"/usr/local/share/utsushi\""
> -DLOCALEDIR="\"/usr/local/share/locale\""
> -DPKGSYSCONFDIR="\"/usr/local/etc/utsushi\""
> -DPKGCONFFILE="\"utsushi.conf\"" -DCOMBOCONFFILE="\"combo.conf\""
> -isystem /usr/local/include -I/usr/local/include -I/usr/local/include -Wall
> -Werror -O2 -pipe -fstack-protector -isystem /usr/local/include
> -fno-strict-aliasing -isystem /usr/local/include -MT connexion.lo -MD -MP
> -MF $depbase.Tpo -c -o connexion.lo connexion.cpp &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile: c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include
> -DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\"
> -DPKGLIBDIR=\"/usr/local/lib/utsushi\"
> -DPKGDATADIR=\"/usr/local/share/utsushi\"
> -DLOCALEDIR=\"/usr/local/share/locale\"
> -DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\"
> -DPKGCONFFILE=\"utsushi.conf\" -DCOMBOCONFFILE=\"combo.conf\" -isystem
> /usr/l
Makefile cannot download from Sourceforge
I'm trying to download some files from sourceforge but it fails constantly. PORTNAME= zipios++ PORTVERSION= 2.1.1 MASTER_SITES= SF/zipios/ DISTFILES=zipios-2.1.1.tar.gz here's the output from trying to run make makesum sudo make makesum => zipios-2.1.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch https://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: https://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://downloads.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://cytranet.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://excellmedia.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://freefr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://jaist.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://kent.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://nchc.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://netcologne.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://netix.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://superb-dca2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://superb-sea2.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://ufpr.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz: Not Found => Attempting to fetch http://vorboss.dl.sourceforge.net/project/zipios/zipios-2.1.1.tar.gz fetch: http://vorboss.dl.sourceforge.net/project/zipios/zipios-2.
Re: [ports]: GH_TAGNAME: how to figure out this tagname on downloadable archives?
I expanded how to get the most up to date hash that works without going through the hassle of cloning the repo. Best On Tue, Oct 17, 2017, 13:01 Yuri wrote: > On 10/16/17 07:46, Mathieu Arnold wrote: > > The first 7 digits may, or may not be sufficient. 7 is a magic number, > > and should not be used. You should, instead, ask git directly what the > > abbreviation should be with, for instance, `git log --abbrev-commit`. > > It may give you a number that seven digits long, but it may very well > > give you a longer one. I repeat, do not simply truncate a hash to its > > first 7 digits, it may not be enough. > > `git log --abbrev-commit` solution has two shortcomings. It only protects > against preexisting hash collisions and not from future collisions. So, the > port's fetch can still spontaneously fail in the future as a result of a > future commit that introduces a collision. Secondly, it requires the manual > clone of the repository which is inconvenient. IMO, it's more practical to > just use 7 digits, and switch to the full hash in an unlikely event when 7 > digits fail. So far, this method virtually always worked. > > Yuri > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gnu ltdl and FreeBSD
The error seems related to libudev. I tried adding libudev to the lib_dependencies like this below LIB_DEPENDS= libltdl.so:devel/libltdl libudev.so:devel/libudev-devd but the compilation still fails with this compilation error below, any tips on getting past this issue? gmake[4]: *** Waiting for unfinished jobs libtool: compile: c++ -DHAVE_CONFIG_H -I.. -pthread -I/usr/local/include -DPKGLIBEXECDIR=\"/usr/local/libexec/utsushi\" -DPKGLIBDIR=\"/usr/local/lib/utsushi\" -DPKGDATADIR=\"/usr/local/share/utsushi\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPKGSYSCONFDIR=\"/usr/local/etc/utsushi\" -DPKGCONFFILE=\"utsushi.conf\" -DCOMBOCONFFILE=\"combo.conf\" -isystem /usr/local/include -I/usr/local/include -I/usr/local/include -Wall -Werror -I/usr/local/include -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -MT stream.lo -MD -MP -MF .deps/stream.Tpo -c stream.cpp -fPIC -DPIC -o .libs/stream.o 1 error generated. gmake[4]: *** [Makefile:667: run-time.lo] Error 1 In file included from scanner.cpp:35: ../utsushi/log.hpp:155:36: error: instantiation of variable 'utsushi::log::basic_logger >::os_' required here, but no definition is available [-Werror,-Wundefined-var-template] basic_logger::os_ << *this; ^ ../utsushi/log.hpp:265:23: note: in instantiation of member function 'utsushi::log::basic_message, std::__1::allocator >::~basic_message' requested here expand_named_ctors (fatal, FATAL); ^ ../utsushi/log.hpp:49:47: note: forward declaration of template entity is here static std::basic_ostream& os_; ^ In file included from monitor.cpp:40: ../utsushi/log.hpp:155:36: error: instantiation of variable 'utsushi::log::basic_logger >::os_' required here, but no definition is available [-Werror,-Wundefined-var-template] basic_logger::os_ << *this; ^ ../utsushi/log.hpp:265:23: note: in instantiation of member function 'utsushi::log::basic_message, std::__1::allocator >::~basic_message' requested here expand_named_ctors (fatal, FATAL); ^ ../utsushi/log.hpp:49:47: note: forward declaration of template entity is here static std::basic_ostream& os_; ^ 1 error generated. 1 error generated. gmake[4]: *** [Makefile:667: scanner.lo] Error 1 gmake[4]: *** [Makefile:667: monitor.lo] Error 1 In file included from buffer.cpp:26: ../utsushi/log.hpp:155:36: error: instantiation of variable 'utsushi::log::basic_logger >::os_' required here, but no definition is available [-Werror,-Wundefined-var-template] basic_logger::os_ << *this; ^ ../utsushi/log.hpp:265:23: note: in instantiation of member function 'utsushi::log::basic_message, std::__1::allocator >::~basic_message' requested here expand_named_ctors (fatal, FATAL); ^ ../utsushi/log.hpp:49:47: note: forward declaration of template entity is here static std::basic_ostream& os_; ^ In file included from device.cpp:31: ../utsushi/log.hpp:155:36: error: instantiation of variable 'utsushi::log::basic_logger >::os_' required here, but no definition is available [-Werror,-Wundefined-var-template] basic_logger::os_ << *this; ^ ../utsushi/log.hpp:265:23: note: in instantiation of member function 'utsushi::log::basic_message, std::__1::allocator >::~basic_message' requested here expand_named_ctors (fatal, FATAL); ^ ../utsushi/log.hpp:49:47: note: forward declaration of template entity is here static std::basic_ostream& os_; ^ 1 error generated. gmake[4]: *** [Makefile:667: buffer.lo] Error 1 On Mon, Oct 16, 2017 at 6:16 PM, blubee blubeeme wrote: > I had an idea that maybe the port was failing because of Clang compiler, > so I looked through the porters handbook and found > USE_GCC > > this prompted me to install gcc 6.2 which i think is a little overkill > plus it also installed a few other packages as well. The build went through > and failed at this step trying to install > > how can I control which version of gcc to use? I think this project should > build fine with gcc 4.8 > > install -m 0644 ./iconv.3 /usr/ports/converters/ > libiconv/work/stage/usr/local/man/man3/iconv.3 > install -m 0644 ./iconv_close.3 /usr/ports/converters/ > libiconv/work/stage/usr/local/man/man3/iconv_close.3 > install -m 0644 ./iconv_open.3 /usr/ports/converters/ > libiconv/work/sta
Re: Makefile cannot download from Sourceforge
This is it, although I needed to change portname from zipios++ to zipios
since the working directory lacked the ++ suffix.
Thanks for the help!
On Tue, Oct 17, 2017 at 8:12 PM, Tijl Coosemans wrote:
> On Tue, 17 Oct 2017 00:32:26 +0800 blubee blubeeme
> wrote:
> > I'm trying to download some files from sourceforge but it fails
> constantly.
> >
> > PORTNAME= zipios++
> > PORTVERSION= 2.1.1
> > MASTER_SITES= SF/zipios/
>
> It looks like this should be SF/zipios/${PORTNAME}/${PORTVERSION}
>
> > DISTFILES=zipios-2.1.1.tar.gz
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
libtool warning
Hello Anyone on this list seen these errors before? A lot of the files don't get copied to the staging area. /bin/mkdir -p '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi' /bin/sh ../libtool --mode=install install -s -m 555 main '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-main' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/main /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-main /bin/sh ../libtool --mode=install install -s -m 555 version '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-version' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/version /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-version /bin/sh ../libtool --mode=install install -s -m 555 help '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-help' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/help /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-help /bin/sh ../libtool --mode=install install -s -m 555 list '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-list' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/list /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-list /bin/sh ../libtool --mode=install install -s -m 555 scan '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-scan' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/scan /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-scan /bin/sh ../libtool --mode=install install -s -m 555 scan-cli '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi/./utsushi-scan-cli' libtool: warning: '../lib/libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../filters/libflt-all.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-usb.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '../connexions/libcnx-hexdump.la' has not been installed in '/usr/local/lib/utsushi' libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ libutsushi.la' has not been installed in '/usr/local/lib/utsushi' libtool: install: install -m 555 -s .libs/scan-cli /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsus
Re: libtool warning
It doesn't install the .la files but it should make the .so and put them in the proper place, the .so files aren't copied over either. Why is that? On Sun, Oct 22, 2017 at 10:31 PM, Adam Weinberger wrote: > > On 22 Oct, 2017, at 6:39, blubee blubeeme wrote: > > > > Hello > > > > Anyone on this list seen these errors before? A lot of the files don't > get > > copied to the staging area. > > > > /bin/mkdir -p > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi' > > /bin/sh ../libtool --mode=install install -s -m 555 main > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-main' > > libtool: warning: '../lib/libutsushi.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../filters/libflt-all.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-usb.la' has not been installed > in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been > installed > > in '/usr/local/lib/utsushi' > > libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi' > > libtool: install: install -m 555 -s .libs/main > > /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-main > > /bin/sh ../libtool --mode=install install -s -m 555 version > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-version' > > libtool: warning: '../lib/libutsushi.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../filters/libflt-all.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-usb.la' has not been installed > in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been > installed > > in '/usr/local/lib/utsushi' > > libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi' > > libtool: install: install -m 555 -s .libs/version > > /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-version > > /bin/sh ../libtool --mode=install install -s -m 555 help > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-help' > > libtool: warning: '../lib/libutsushi.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../filters/libflt-all.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-usb.la' has not been installed > in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been > installed > > in '/usr/local/lib/utsushi' > > libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi' > > libtool: install: install -m 555 -s .libs/help > > /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-help > > /bin/sh ../libtool --mode=install install -s -m 555 list > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-list' > > libtool: warning: '../lib/libutsushi.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../filters/libflt-all.la' has not been installed in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-usb.la' has not been installed > in > > '/usr/local/lib/utsushi' > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been > installed > > in '/usr/local/lib/utsushi' > > libtool: warning: '/usr/ports/graphics/utsushi/work/utsushi-3461931/lib/ > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi' > > libtool: install: install -m 555 -s .libs/list > > /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/ > utsushi/./utsushi-list > > /bin/sh ../libtool --mode=install install -s -m 555 scan > > '/usr/ports/graphics/utsushi/work/stage/usr/lo
Re: libtool warning
I've had a lot of help with this project but here's the Makefile as it
stands now.
---
# Created by: blubee
# $FreeBSD: head/graphics/utsushi $
PORTNAME= utsushi
PORTVERSION= 0.32.0
CATEGORIES= graphics
MAINTAINER= he...@blubee.me
COMMENT= EPSON scanner support
LICENSE= GPLv3+
LICENSE_FILE= ${WRKSRC}/COPYING
BUILD_DEPENDS= autoconf-archive>0:devel/autoconf-archive \
gsed:textproc/gsed \
xsltproc:textproc/libxslt
LIB_DEPENDS= libboost_system.so:devel/boost-libs \
libltdl.so:devel/libltdl \
libudev.so:devel/libudev-devd \
libfontconfig.so:x11-fonts/fontconfig \
libfreetype.so:print/freetype2
USE_GITHUB= yes
GH_ACCOUNT= teamblubee
GH_TAGNAME= 3461931
BINARY_ALIAS= sed=gsed
CONFIGURE_ARGS= --without-boost-unit-test-framework \
--without-magick --without-magick-pp
GNU_CONFIGURE= yes
USES= autoreconf compiler:c++11-lib gettext-tools gmake libtool \
localbase pkgconfig
USE_CXXSTD= gnu++11
OPTIONS_DEFINE= JPEG NLS SANE TIFF X11
OPTIONS_RADIO= MAGICK
OPTIONS_RADIO_MAGICK= GRAPHMAGICK IMAGEMAGICK
OPTIONS_DEFAULT= GRAPHMAGICK JPEG SANE TIFF X11
GRAPHMAGICK_CONFIGURE_ON= \
--with-magick=GraphicsMagick \
--with-magick-pp=GraphicsMagick
GRAPHMAGICK_LIB_DEPENDS=libGraphicsMagick++.so:graphics/GraphicsMagick
IMAGEMAGICK_CONFIGURE_ON= \
--with-magick=ImageMagick \
--with-magick-pp=ImageMagick
IMAGEMAGICK_LIB_DEPENDS=libMagick++-6.so:graphics/ImageMagick
JPEG_CONFIGURE_WITH= jpeg
JPEG_USES= jpeg
NLS_CONFIGURE_ENABLE= nls
NLS_USES= gettext-runtime
SANE_CONFIGURE_ENABLE= sane-config
SANE_CONFIGURE_WITH= sane
SANE_LIB_DEPENDS= libsane.so:graphics/sane-backends
TIFF_CONFIGURE_WITH= tiff
TIFF_LIB_DEPENDS= libtiff.so:graphics/tiff
X11_CONFIGURE_WITH= gtkmm
X11_USE= GNOME=gtkmm24
USE_GNOME= gdkpixbuf2
.include
On Sun, Oct 22, 2017 at 10:39 PM, Adam Weinberger wrote:
> > On 22 Oct, 2017, at 8:36, blubee blubeeme wrote:
> >
> > It doesn't install the .la files but it should make the .so and put them
> in the proper place, the .so files aren't copied over either.
> >
> > Why is that?
>
> Ah, I missed that part. Can you show us the Makefile you're using?
>
> # Adam
>
>
> --
> Adam Weinberger
> ad...@adamw.org
> https://www.adamw.org
>
>
> >
> > On Sun, Oct 22, 2017 at 10:31 PM, Adam Weinberger
> wrote:
> > > On 22 Oct, 2017, at 6:39, blubee blubeeme wrote:
> > >
> > > Hello
> > >
> > > Anyone on this list seen these errors before? A lot of the files don't
> get
> > > copied to the staging area.
> > >
> > > /bin/mkdir -p
> > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/utsushi'
> > > /bin/sh ../libtool --mode=install install -s -m 555 main
> > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/
> utsushi/./utsushi-main'
> > > libtool: warning: '../lib/libutsushi.la' has not been installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../filters/libflt-all.la' has not been installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../connexions/libcnx-usb.la' has not been
> installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been
> installed
> > > in '/usr/local/lib/utsushi'
> > > libtool: warning: '/usr/ports/graphics/utsushi/
> work/utsushi-3461931/lib/
> > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi'
> > > libtool: install: install -m 555 -s .libs/main
> > > /usr/ports/graphics/utsushi/work/stage/usr/local/libexec/
> utsushi/./utsushi-main
> > > /bin/sh ../libtool --mode=install install -s -m 555 version
> > > '/usr/ports/graphics/utsushi/work/stage/usr/local/libexec/
> utsushi/./utsushi-version'
> > > libtool: warning: '../lib/libutsushi.la' has not been installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../filters/libflt-all.la' has not been installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../connexions/libcnx-usb.la' has not been
> installed in
> > > '/usr/local/lib/utsushi'
> > > libtool: warning: '../connexions/libcnx-hexdump.la' has not been
> installed
> > > in '/usr/local/lib/utsushi'
> > > libtool: warning: '/usr/ports/graphics/utsushi/
> work/utsushi-3461931/lib/
> > > libutsushi.la' has not been installed in '/usr/local/lib/utsushi'
> > > libtool: install: ins
PR bug for a port
Zipios++ is a small C++ library for reading and writing zip files. Can a commiter take a look at this port and submit it to the tree? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223176 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PR bug for a port
Kurt, thanks for the heads up. I cleaned up the file and updated the bug request. On Mon, Oct 23, 2017 at 12:23 PM, Kurt Jaeger wrote: > Hi! > > > Zipios++ is a small C++ library for reading and writing zip files. > > > > Can a commiter take a look at this port and submit it to the tree? > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223176 > > I ran a test using portlint. portlint -AC says: > > WARN: /home/pi/m/archivers/zipios/pkg-plist: [14]: installing shared > libraries, please define USE_LDCONFIG as appropriate > WARN: /home/pi/m/archivers/zipios/pkg-plist: [15]: installing shared > libraries, please define USE_LDCONFIG as appropriate > FATAL: Makefile: [4]: use a tab (not space) after a variable name > FATAL: Makefile: [5]: use a tab (not space) after a variable name > FATAL: Makefile: [6]: use a tab (not space) after a variable name > FATAL: Makefile: [7]: use a tab (not space) after a variable name > FATAL: Makefile: [9]: use a tab (not space) after a variable name > FATAL: Makefile: [10]: use a tab (not space) after a variable name > FATAL: Makefile: [12]: use a tab (not space) after a variable name > FATAL: Makefile: [13]: use a tab (not space) after a variable name > FATAL: Makefile: [15]: use a tab (not space) after a variable name > FATAL: Makefile: [16]: use a tab (not space) after a variable name > FATAL: Makefile: [20]: use a tab (not space) after a variable name > FATAL: Makefile: [21]: use a tab (not space) after a variable name > FATAL: Makefile: [22]: use a tab (not space) after a variable name > FATAL: Makefile: [24]: use a tab (not space) after a variable name > > -- > p...@opsec.eu+49 171 3101372 3 years to > go ! > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Linking against TK*
I am running -ldd on a executable and I am missing links to a bunch of: libTK**.so files such as: libTKGeomBase.so.11 => not found (0) libTKG3d.so.11 => not found (0) libTKG2d.so.11 => not found (0) libTKMath.so.11 => not found (0) I've searched quite a bit and can't find where those files are located. What's going on, how do I link against them? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linking against TK*
building opencascade community edition: https://github.com/tpaviot/oce but the executable is missing those libTK** shared objects. How would I link them in? On Tue, Oct 24, 2017 at 1:15 PM, Kurt Jaeger wrote: > Hi! > > > I am running -ldd on a executable and I am missing links to a bunch > > of: libTK**.so files > > > > such as: > > libTKGeomBase.so.11 => not found (0) > > libTKG3d.so.11 => not found (0) > > libTKG2d.so.11 => not found (0) > > libTKMath.so.11 => not found (0) > > > > I've searched quite a bit and can't find where those files are located. > > What's going on, how do I link against them? > > https://pkgs.org/download/libTKG2d.so.11()(64bit) says that > those libs are part of opencascade. > > Searching cad/opencascade/pkg-plist finds > > lib/libTKG2d.so > lib/libTKG2d.so.7 > lib/libTKG2d.so.7.1.0 > > So, that's close, but not exactly what you searched. Does this help ? > > -- > p...@opsec.eu+49 171 3101372 3 years to > go ! > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linking against TK*
I already took a look at the current opencascade port, most of those issues
that patch addresses are fixed in the oce from github. opencascade isn't
something u really run, you just link against it for maths the DRAWEXE is
used for testing and that's what's missing some shared objects.
I think I might be missing some USES or LIB_DEPENDS but this is a heavy
port to compile so iteration time is really slow. I'll try using lang/tcl86
and x11-toolkits/tk86 I think I might have missed those in previous
attempts.
On Tue, Oct 24, 2017 at 1:47 PM, Kevin Oberman wrote:
> On Mon, Oct 23, 2017 at 10:29 PM, blubee blubeeme
> wrote:
>
>> building opencascade community edition: https://github.com/tpaviot/oce
>>
>> but the executable is missing those libTK** shared objects. How would I
>> link them in?
>>
>> On Tue, Oct 24, 2017 at 1:15 PM, Kurt Jaeger wrote:
>>
>> > Hi!
>> >
>> > > I am running -ldd on a executable and I am missing links to a bunch
>> > > of: libTK**.so files
>> > >
>> > > such as:
>> > > libTKGeomBase.so.11 => not found (0)
>> > > libTKG3d.so.11 => not found (0)
>> > > libTKG2d.so.11 => not found (0)
>> > > libTKMath.so.11 => not found (0)
>> > >
>> > > I've searched quite a bit and can't find where those files are
>> located.
>> > > What's going on, how do I link against them?
>> >
>> > https://pkgs.org/download/libTKG2d.so.11()(64bit) says that
>> > those libs are part of opencascade.
>> >
>> > Searching cad/opencascade/pkg-plist finds
>> >
>> > lib/libTKG2d.so
>> > lib/libTKG2d.so.7
>> > lib/libTKG2d.so.7.1.0
>> >
>> > So, that's close, but not exactly what you searched. Does this help ?
>> >
>> > --
>> > p...@opsec.eu+49 171 3101372 3 years
>> to
>> > go !
>> >
>>
>
> Looking at the current port (cad/opencascade), I'd guess
> -DINSTALL_DIR_LIB=${PREFIX}/lib as an argument to cmake. I suggest
> looking at the port to see how to get the newer version to build as you
> wish. Also look at the patches in files to see if any are appropriate and
> should be updated to the current version.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linking against TK*
I am a bit stumped.
I just realized that those libTK** files are installed insto
${STAGEDIR}/${PREFIX}/lib/libTK***.so
The question is how do I set cmake options to link to those shared
libraries installed into that directory?
On Tue, Oct 24, 2017 at 1:56 PM, blubee blubeeme
wrote:
> I already took a look at the current opencascade port, most of those
> issues that patch addresses are fixed in the oce from github. opencascade
> isn't something u really run, you just link against it for maths the
> DRAWEXE is used for testing and that's what's missing some shared objects.
>
> I think I might be missing some USES or LIB_DEPENDS but this is a heavy
> port to compile so iteration time is really slow. I'll try using lang/tcl86
> and x11-toolkits/tk86 I think I might have missed those in previous
> attempts.
>
> On Tue, Oct 24, 2017 at 1:47 PM, Kevin Oberman
> wrote:
>
>> On Mon, Oct 23, 2017 at 10:29 PM, blubee blubeeme
>> wrote:
>>
>>> building opencascade community edition: https://github.com/tpaviot/oce
>>>
>>> but the executable is missing those libTK** shared objects. How would I
>>> link them in?
>>>
>>> On Tue, Oct 24, 2017 at 1:15 PM, Kurt Jaeger wrote:
>>>
>>> > Hi!
>>> >
>>> > > I am running -ldd on a executable and I am missing links to a bunch
>>> > > of: libTK**.so files
>>> > >
>>> > > such as:
>>> > > libTKGeomBase.so.11 => not found (0)
>>> > > libTKG3d.so.11 => not found (0)
>>> > > libTKG2d.so.11 => not found (0)
>>> > > libTKMath.so.11 => not found (0)
>>> > >
>>> > > I've searched quite a bit and can't find where those files are
>>> located.
>>> > > What's going on, how do I link against them?
>>> >
>>> > https://pkgs.org/download/libTKG2d.so.11()(64bit) says that
>>> > those libs are part of opencascade.
>>> >
>>> > Searching cad/opencascade/pkg-plist finds
>>> >
>>> > lib/libTKG2d.so
>>> > lib/libTKG2d.so.7
>>> > lib/libTKG2d.so.7.1.0
>>> >
>>> > So, that's close, but not exactly what you searched. Does this help ?
>>> >
>>> > --
>>> > p...@opsec.eu+49 171 3101372 3
>>> years to
>>> > go !
>>> >
>>>
>>
>> Looking at the current port (cad/opencascade), I'd guess
>> -DINSTALL_DIR_LIB=${PREFIX}/lib as an argument to cmake. I suggest
>> looking at the port to see how to get the newer version to build as you
>> wish. Also look at the patches in files to see if any are appropriate and
>> should be updated to the current version.
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Okular or any pdf reader
Whenever I try to launch any audio pdf viewer program my computer hard locks up and I have to power cycle. Does anyone have any info as to why? uname -v: FreeBSD 12.0-CURRENT #0 r319752: Sat Jun 10 01:59:26 CST 2017 blubee.me: /usr/obj/usr/src/sys/GENERIC ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Okular or any pdf reader
Typo on the [audio] Here's my /var/log/messages for the past hour or so, the failure should be logged in there somewhere: https://pastebin.com/FCkXEn1v Other than that there's this: https://ibb.co/gUBVkm On Wed, Oct 25, 2017 at 5:29 PM, Hans Petter Selasky wrote: > On 10/25/17 11:30, blubee blubeeme wrote: > >> any audio pdf viewer >> > > Audio?? > > Do you have a kernel trace or dmesg ? > > --HPS > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Okular or any pdf reader
lid0: on
acpi0
Oct 25 17:52:52 blubee kernel: acpi_acad0: on acpi0
Oct 25 17:52:52 blubee kernel: battery0: on
acpi0
Oct 25 17:52:52 blubee kernel: acpi_tz0: on acpi0
Oct 25 17:52:52 blubee kernel: atkbdc0: port
0x60,0x64 irq 1 on acpi0
Oct 25 17:52:52 blubee kernel: atkbd0: irq 1 on atkbdc0
Oct 25 17:52:52 blubee kernel: kbd0 at atkbd0
Oct 25 17:52:52 blubee kernel: atkbd0: [GIANT-LOCKED]
Oct 25 17:52:52 blubee kernel: psm0: irq 12 on atkbdc0
Oct 25 17:52:52 blubee kernel: psm0: [GIANT-LOCKED]
Oct 25 17:52:52 blubee kernel: psm0: model Synaptics Touchpad, device ID 0
Oct 25 17:52:52 blubee kernel: orm0: at iomem
0xce800-0xcf7ff on isa0
Oct 25 17:52:52 blubee kernel: ppc0: cannot reserve I/O port range
Oct 25 17:52:52 blubee kernel: est0:
on cpu0
Oct 25 17:52:52 blubee kernel: est1:
on cpu1
Oct 25 17:52:52 blubee kernel: est2:
on cpu2
Oct 25 17:52:52 blubee kernel: est3:
on cpu3
Oct 25 17:52:52 blubee kernel: est4:
on cpu4
Oct 25 17:52:52 blubee kernel: est5:
on cpu5
Oct 25 17:52:52 blubee kernel: est6:
on cpu6
Oct 25 17:52:52 blubee kernel: est7:
on cpu7
Oct 25 17:52:52 blubee kernel: ZFS filesystem version: 5
Oct 25 17:52:52 blubee kernel: ZFS storage pool version: features support
(5000)
Oct 25 17:52:52 blubee kernel: Timecounters tick every 1.000 msec
Oct 25 17:52:52 blubee kernel: iwm0: hw rev 0x180, fw ver 17.352738.0,
address 60:57:18:94:c6:4a
Oct 25 17:52:52 blubee kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0
Oct 25 17:52:52 blubee kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
Oct 25 17:52:52 blubee kernel: nvd0: NVMe namespace
Oct 25 17:52:52 blubee kernel: nvd0: 244198MB (500118192 512 byte sectors)
Oct 25 17:52:52 blubee kernel: hdacc0: at cad 0
on hdac0
Oct 25 17:52:52 blubee kernel: hdaa0:
at nid 1 on hdacc0
Oct 25 17:52:52 blubee kernel: pcm0: at nid 20
and 24 on hdaa0
Oct 25 17:52:52 blubee kernel: pcm1: at nid 23 on hdaa0
Oct 25 17:52:52 blubee kernel: pcm2: at nid
30 on hdaa0
Oct 25 17:52:52 blubee kernel: WARNING: WITNESS option enabled, expect
reduced performance.
Oct 25 17:52:52 blubee kernel: Trying to mount root from
zfs:zroot/ROOT/default []...
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: uhub0: 24 ports with 24 removable, self
powered
Oct 25 17:52:52 blubee kernel: ugen0.2: at usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: ugen0.3: at
usbus0
Oct 25 17:52:52 blubee kernel: Root mount waiting for: usbus0
Oct 25 17:52:52 blubee kernel: ugen0.4: at usbus0
Oct 25 17:52:52 blubee kernel: wlan0: Ethernet address: 60:57:18:94:c6:4a
Oct 25 17:52:52 blubee kernel: wlan0: link state changed to UP
Oct 25 17:52:52 blubee kernel: re0: link state changed to DOWN
Oct 25 17:52:52 blubee kernel: ulpt0 on uhub0
Oct 25 17:52:52 blubee kernel: ulpt0: on usbus0
Oct 25 17:52:52 blubee kernel: ulpt0: using bi-directional mode
Oct 25 17:52:52 blubee kernel: ubt0 on uhub0
Oct 25 17:52:52 blubee kernel: ubt0: on usbus0
Oct 25 17:52:52 blubee kernel: WARNING: attempt to domain_add(bluetooth)
after domainfinalize()
Oct 25 17:52:52 blubee kernel: WARNING: attempt to domain_add(netgraph)
after domainfinalize()
Oct 25 17:52:52 blubee kernel: ubt0: ubt_ctrl_write_callback:780: control
transfer failed: USB_ERR_TIMEOUT
Oct 25 17:52:52 blubee kernel: ng_hci_process_command_timeout: ubt0hci -
unable to complete HCI command OGF=0x3, OCF=0x3. Timeout
Oct 25 17:52:53 blubee ntpd[825]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
Oct 25 17:52:53 blubee ntpd[825]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z
last=2017-01-01T00:00:00Z ofs=37
Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20170531/nsarguments-205)
Oct 25 17:52:58 blubee last message repeated 6 times
Oct 25 17:52:58 blubee kernel: acquiring duplicate lock of same type:
"os.lock_mtx"
Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841
Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841
Oct 25 17:52:58 blubee kernel: stack backtrace:
Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at
witness_debugger+0x70
Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at
witness_checkorder+0xe23
Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at
__mtx_lock_flags+0x93
Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at
os_acquire_spinlock+0x1b
Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185
Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20170531/nsarguments-205)
Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0
(GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0
On W
Re: Okular or any pdf reader
The GPUT thing is pretty terrible so I know i'm risking things with that, have no choice until I can take some time to try that drm-kmod. Speaking of which, those commands do not work; I am on a laptop and if I try to change terms like that the nvidia drivers just panic and die. screen looks like when old nintendo would freeze with the colorful junk on screen. I don't have another machine that can ssh into this one, any other options? On Wed, Oct 25, 2017 at 5:58 PM, Hans Petter Selasky wrote: > On 10/25/17 11:55, blubee blubeeme wrote: > >> "os.lock_mtx" >> Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841 >> Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841 >> Oct 25 17:52:58 blubee kernel: stack backtrace: >> Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at >> witness_debugger+0x70 >> Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at >> witness_checkorder+0xe23 >> Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at >> __mtx_lock_flags+0x93 >> Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at >> os_acquire_spinlock+0x1b >> Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185 >> Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: >> Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] >> (20170531/nsarguments-205) >> Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0 >> (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0 >> >> >> > Hi, > > Try: CTRL+ALT+F1 > Or SSH into this machine. > > Then do: > > procstat -ak > > It will reveal any hangs and deadlocks. > > Further I note you're using 12-current with the NVIDIA driver. That might > not be a supported configuration :-( Especially nowadays some core kernel > structures are changing, which means NVIDIA needs to recompile their binary > blob aswell! > > --HPS > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Okular or any pdf reader
Okay, I tried using chatbot for android to ssh into this laptop and that works just fine. Then when I launch okular the computer had locks up and the ssh dies on the phone as well. So it seems not even ssh works when this this freezes up. Any other suggestions? On Wed, Oct 25, 2017 at 6:05 PM, blubee blubeeme wrote: > The GPUT thing is pretty terrible so I know i'm risking things with that, > have no choice until I can take some time to try that drm-kmod. > > Speaking of which, those commands do not work; I am on a laptop and if I > try to change terms like that the nvidia drivers just panic and die. screen > looks like when old nintendo would freeze with the colorful junk on screen. > > I don't have another machine that can ssh into this one, any other options? > > On Wed, Oct 25, 2017 at 5:58 PM, Hans Petter Selasky > wrote: > >> On 10/25/17 11:55, blubee blubeeme wrote: >> >>> "os.lock_mtx" >>> Oct 25 17:52:58 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841 >>> Oct 25 17:52:58 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841 >>> Oct 25 17:52:58 blubee kernel: stack backtrace: >>> Oct 25 17:52:58 blubee kernel: #0 0x80ab6f30 at >>> witness_debugger+0x70 >>> Oct 25 17:52:58 blubee kernel: #1 0x80ab6e23 at >>> witness_checkorder+0xe23 >>> Oct 25 17:52:58 blubee kernel: #2 0x80a35293 at >>> __mtx_lock_flags+0x93 >>> Oct 25 17:52:58 blubee kernel: #3 0x82f4097b at >>> os_acquire_spinlock+0x1b >>> Oct 25 17:52:58 blubee kernel: #4 0x82c45b15 at _nv012002rm+0x185 >>> Oct 25 17:52:58 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: >>> Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] >>> (20170531/nsarguments-205) >>> Oct 25 17:52:59 blubee kernel: nvidia-modeset: Allocated GPU:0 >>> (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0 >>> >>> >>> >> Hi, >> >> Try: CTRL+ALT+F1 >> Or SSH into this machine. >> >> Then do: >> >> procstat -ak >> >> It will reveal any hangs and deadlocks. >> >> Further I note you're using 12-current with the NVIDIA driver. That might >> not be a supported configuration :-( Especially nowadays some core kernel >> structures are changing, which means NVIDIA needs to recompile their binary >> blob aswell! >> >> --HPS >> > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Okular or any pdf reader
I've had the pdf viewers work with these nvidia drivers before, then a few months back they stopped working. I've avoided dealing with the problem by using chrome to view pdfs but that's getting old. About this laptop it's a bios switch to use either the gtx 1070 or the intel gpu vgapci0@pci0:1:0:0: class=0x03 card=0x6a021558 chip=0x1ba110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GP104M [GeForce GTX 1070]' class = display subclass = VGA hw.machine: amd64 hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz hw.ncpu: 8 hw.machine_arch: amd64 I havent had time to try the kmod drivers yet, maybe i'll install that port, disable the nvidia-drivers, make the switch in the gpu and try again. On Wed, Oct 25, 2017 at 7:23 PM, Hans Petter Selasky wrote: > On 10/25/17 13:15, blubee blubeeme wrote: > >> Okay, I tried using chatbot for android to ssh into this laptop and that >> works just fine. >> Then when I launch okular the computer had locks up and the ssh dies on >> the >> phone as well. So it seems not even ssh works when this this freezes up. >> >> Any other suggestions? >> > > Try to set: > > sysctl net.inet.tcp.per_cpu_timers=1 > > Before connecting via SSH. > > Does the same happen when using VESA driver or is this specific to using > the NVIDIA driver. If the NVIDIA is at cause, I cannot help. > > --HPS > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
po/Makefile.in.in was not created by intltoolize."
I found this really old thread: https://mail.gnome.org/archives/gtkmm-list/2009-August/msg00072.html and this really old script to "work around" the issue. #! /bin/sh -etest -n "$srcdir" || srcdir=`dirname "$0"`test -n "$srcdir" || srcdir=.( cd "$srcdir" && AUTOPOINT='intltoolize --automake --copy' autoreconf --force --install --verbose) || exittest -n "$NOCONFIGURE" || "$srcdir/configure" "$@" Do I just have to implement this in the ports Makefile or is there some workaround? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
can't link against math.h
I wrote a simple test program to test and see if math.h has the function:
exp10f
#include
int main(int argc, char** argv)
{
(void)argv;
return ((int*)(&exp10))[argc];
}
tried compiling it with clang:
clang++ test.cpp -o test -lm
test.cpp:7:17: error: use of undeclared identifier 'expf10'
return ((int*)(&expf10))[argc];
^
1 error generated.
tried with gcc:
gcc test.cpp -o test -lm
test.cpp: In function 'int main(int, char**)':
test.cpp:7:17: error: 'expf10' was not declared in this scope
return ((int*)(&expf10))[argc];
Does FreeBSD math.h have expf10 and if so, how do I link against it?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
lang/ghc fails to build
I've created a bug report, can anyone take a look at this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223249 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: can't link against math.h
Thanks for the tips
I didn't know that it wasn't in the std c library and was GNU specific
code. I think I'll take Montgomery-Smith
advice and implement it as this:
#define exp10f(x) (powf(10.,x))
Porting software is some interesting work.
On Thu, Oct 26, 2017 at 4:41 PM, Bob Eager wrote:
> On Thu, 26 Oct 2017 10:05:00 +0800
> blubee blubeeme wrote:
>
> > I wrote a simple test program to test and see if math.h has the
> > function: exp10f
> >
> > #include
> >
> > int main(int argc, char** argv)
> > {
> > (void)argv;
> > return ((int*)(&exp10))[argc];
> > }
> >
> > tried compiling it with clang:
> > clang++ test.cpp -o test -lm
> > test.cpp:7:17: error: use of undeclared identifier 'expf10'
> > return ((int*)(&expf10))[argc];
> > ^
> > 1 error generated.
> >
> > tried with gcc:
> > gcc test.cpp -o test -lm
> > test.cpp: In function 'int main(int, char**)':
> > test.cpp:7:17: error: 'expf10' was not declared in this scope
> > return ((int*)(&expf10))[argc];
> >
> > Does FreeBSD math.h have expf10 and if so, how do I link against it?
>
> It's not in the C standard (C99 or C11). So why would it be available?
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Strange compiler error
CMAKE_ARGS= -DFREECAD_USE_EXTERNAL_PIVY:BOOL=ON \
-DBUILD_QT5_WEBKIT:BOOL=OFF \
-DCMAKE_CXX_COMPILER=${LOCALBASE}/bin/mpicxx \
BUILD_DEPENDS= pyside-rcc:devel/pyside-tools \
swig:devel/swig13 \
${LOCALBASE}/libdata/pkgconfig/eigen3.pc:math/eigen3 \
${LOCALBASE}/bin/mpicc:net/mpich2
I've tried this but still no go, any ideas?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
strage compile error [with attachments]
error: FAILED: lib/libSMESH.so : && /usr/bin/c++ -fPIC -Wall -Wextra -Wno-write-strings -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -std=c++11 -Wno-undefined-var-template -D_OCC64 -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable -Wno-unused-private-field -Wno-unused-function -Wno-sometimes-uninitialized -Wno-overloaded-virtual -Wno-dynamic-class-memaccess -Wno-comment -Wno-unused-parameter -Wno-self-assign -Wno-reorder -Wno-switch-enum -Wno-unknown-pragmas -Wno-logical-op-parentheses -Wno-unused-variable -Wno-unused-function -Wno-overloaded-virtual -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -Wl,--no-undefined -shared -Wl,-soname,libSMESH.so -o lib/libSMESH.so src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/libmesh.c.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Read.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Write.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_Family.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_R_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_Field.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/GEOMUtils.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Algorithm.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_CoordUtils.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Factory.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussDef.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussUtils.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Structures.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Utilities.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_V2_2_Wrapper.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Wrapper.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Algo.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Block.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Exception.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Gen.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Group.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_HypoFilter.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Hypothesis.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Mesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshAlgos.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshEditor.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshVSLink.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MesherHelper.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Octree.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_OctreeNode.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Pattern.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_ProxyMesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_TryCatch.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_subMesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/Utils_ExceptHandlers.cpp.o src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/Controls/SMESH_Controls.cpp.o -Wl,-rpath,/usr/ports/cad/Freecad/work/.build/lib:/usr/local/lib:/usr/local/lib/vtk-6.2: lib/libDriverSTL.so lib/libDriverDAT.so lib/libDriverUNV.so /usr/local/lib/libmedC.so /usr/local/lib/libmed.so -lz /usr/local/lib/libexpat.so lib/libSMESHDS.so lib/libSMDS.so /usr/local/lib/vtk-6.2/libvtkFiltersVerdict-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkverdict-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkIOXML-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkIOGeometry-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkjsoncpp-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkIOXMLParser-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkIOLegacy-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkIOCore-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersExtraction-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersStatistics-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkImagingFourier-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkImagingCore-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkalglib-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersSources-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersGeneral-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkCommonComputationalGeometry-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersGeometry-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkFiltersCore-6.2.so.1 /usr/local/lib/vtk-6.2/libvtkCommonExecutionModel-6.2.so.1 /usr/local/lib/vtk-6
Re: strage compile error [with attachments]
The header file includes these headers: // SMESH SMESH : implementaion of SMESH idl descriptions // File : SMESH_Algo.cxx // Author : Paul RASCLE, EDF // Module : SMESH #include "SMESH_Algo.hxx" #include "SMDS_EdgePosition.hxx" #include "SMDS_FacePosition.hxx" #include "SMDS_MeshElement.hxx" #include "SMDS_MeshNode.hxx" #include "SMDS_VolumeTool.hxx" #include "SMESHDS_Mesh.hxx" #include "SMESHDS_SubMesh.hxx" #include "SMESH_Comment.hxx" #include "SMESH_Gen.hxx" #include "SMESH_HypoFilter.hxx" #include "SMESH_Mesh.hxx" #include "SMESH_MeshAlgos.hxx" #include "SMESH_TypeDefs.hxx" #include "SMESH_subMesh.hxx" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "utilities.h" #include #include #include "SMESH_ProxyMesh.hxx" #include "SMESH_MesherHelper.hxx" #include using namespace std; I don't really see anything that would cause such errors.. On Fri, Oct 27, 2017 at 8:24 PM, blubee blubeeme wrote: > error: > FAILED: lib/libSMESH.so > : && /usr/bin/c++ -fPIC -Wall -Wextra -Wno-write-strings -O2 -pipe > -fstack-protector -isystem /usr/local/include -fno-strict-aliasing > -isystem /usr/local/include -std=c++11 -Wno-undefined-var-template > -D_OCC64 -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable > -Wno-unused-private-field -Wno-unused-function -Wno-sometimes-uninitialized > -Wno-overloaded-virtual -Wno-dynamic-class-memaccess -Wno-comment > -Wno-unused-parameter -Wno-self-assign -Wno-reorder -Wno-switch-enum > -Wno-unknown-pragmas -Wno-logical-op-parentheses -Wno-unused-variable > -Wno-unused-function -Wno-overloaded-virtual -O2 -pipe -fstack-protector > -isystem /usr/local/include -fno-strict-aliasing -isystem > /usr/local/include -Wl,--no-undefined -shared -Wl,-soname,libSMESH.so -o > lib/libSMESH.so > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/libmesh.c.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Read.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverGMF_Write.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/DriverMED_Family.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/ > SMESH/DriverMED_R_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/ > CMakeFiles/SMESH.dir/src/SMESH/DriverMED_W_Field.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/ > SMESH/DriverMED_W_SMESHDS_Mesh.cpp.o src/3rdParty/salomesmesh/ > CMakeFiles/SMESH.dir/src/SMESH/GEOMUtils.cpp.o src/3rdParty/salomesmesh/ > CMakeFiles/SMESH.dir/src/SMESH/MED_Algorithm.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_CoordUtils.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Factory.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussDef.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_GaussUtils.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Structures.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Utilities.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_V2_2_Wrapper.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/MED_Wrapper.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Algo.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Block.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Exception.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Gen.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Group.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_HypoFilter.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Hypothesis.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Mesh.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshAlgos.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshEditor.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MeshVSLink.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_MesherHelper.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Octree.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_OctreeNode.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_Pattern.cpp.o > src/3rdParty/salomesmesh/CMakeFiles/SMESH.dir/src/SMESH/SMESH_ProxyMesh.cpp.o > src/3rdParty/sal
Re: Strange compiler error
Apologies, for forwarding the email to both lists.
I am trying to compile FreeCAD.
It seems FreeCAD uses a version of the SMESH framework but they bundle
their own and make changes to it, changes that cause the linker to go nuts
[for me] and won't link the program, so I get those strange errors.
The FreeCAD forum seems 'meh' when it comes to solving problems for any OS
other than Debian/Ubuntu, so i asked here hoping that some of the more
experienced members could assist.
On Fri, Oct 27, 2017 at 9:55 PM, Rares Aioanei wrote:
> What *exactly* are you trying to do, what are the complete and precise
> steps and what are the errors? Not CC-ing freebsd-current@ as this
> looks like a ports issue.
>
> On Fri, Oct 27, 2017 at 3:08 PM, blubee blubeeme
> wrote:
> > CMAKE_ARGS= -DFREECAD_USE_EXTERNAL_PIVY:BOOL=ON \
> > -DBUILD_QT5_WEBKIT:BOOL=OFF \
> > -DCMAKE_CXX_COMPILER=${LOCALBASE}/bin/mpicxx \
> >
> > BUILD_DEPENDS= pyside-rcc:devel/pyside-tools \
> > swig:devel/swig13 \
> > ${LOCALBASE}/libdata/pkgconfig/eigen3.pc:math/eigen3 \
> > ${LOCALBASE}/bin/mpicc:net/mpich2
> >
> > I've tried this but still no go, any ideas?
> > ___
> > freebsd-curr...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
SF mastersites
These SF mater_sites give me a real tough time trying to figure it out and
try to find github mirrors whenever possible but I need to figure this out.
I'm trying to download: https://sourceforge.net/projects/spacenav/
PORTNAME= freespacenav
PORTVERSION= 0.2.3
MASTER_SITES= SF/spacenav
DISTNAME= libspnav-${PORTVERSION}
I would think the version above would work since it leads to:
https://downloads.sourceforge.net/project/spacenav/libspnav-0.2.3.tar.gz
but that doesn't work!
The documentation on:
https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html
5.4.2.2. Magic MASTER_SITES Macros
also leaves me more confused that relieved.
Can anyone help me sort this out?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: SF mastersites
I literally copy the entire url and add it to master_sites and it doesn't
work!
what does [:tl] even mean here? There's nothing about it on the whole page:
https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html
SF ${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}
MASTER_SITES= SF/spacenav/files/spacenav%20library%20%28SDK%29/
DISTNAME= libspnav-${PORTVERSION}
=> libspnav-0.2.3.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch
https://downloads.sourceforge.net/project/spacenav/files/spacenav%20library%20%28SDK%29/libspnav-0.2.3.tar.gz
fetch:
https://downloads.sourceforge.net/project/spacenav/files/spacenav%20library%20%28SDK%29/libspnav-0.2.3.tar.gz:
Not Found
=> Attempting to fetch
https://cytranet.dl.sourceforge.net/project/spacenav/files/spacenav%20library%20%28SDK%29/libspnav-0.2.3.tar.gz
fetch:
https://cytranet.dl.sourceforge.net/project/spacenav/files/spacenav%20library%20%28SDK%29/libspnav-0.2.3.tar.gz:
Not Found
=> Attempting to fetch
https://excellmedia.dl.sourceforge.net/project/spacenav/files/spacenav%20library%20%28SDK%29/libspnav-0.2.3.tar.gz
still giving me not found errors!
On Sat, Oct 28, 2017 at 1:06 PM, blubee blubeeme
wrote:
> These SF mater_sites give me a real tough time trying to figure it out and
> try to find github mirrors whenever possible but I need to figure this out.
>
> I'm trying to download: https://sourceforge.net/projects/spacenav/
>
> PORTNAME= freespacenav
> PORTVERSION= 0.2.3
>
> MASTER_SITES= SF/spacenav
> DISTNAME= libspnav-${PORTVERSION}
>
> I would think the version above would work since it leads to:
> https://downloads.sourceforge.net/project/spacenav/libspnav-0.2.3.tar.gz
>
> but that doesn't work!
>
> The documentation on: https://www.freebsd.org/
> doc/en/books/porters-handbook/makefile-distfiles.html
> 5.4.2.2. Magic MASTER_SITES Macros
> also leaves me more confused that relieved.
>
> Can anyone help me sort this out?
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: SF mastersites
thanks for that tip but how would I know to look at man [1 make] for something like that? On Sat, Oct 28, 2017 at 2:38 PM, Herbert J. Skuhra wrote: > On Sat, 28 Oct 2017 07:33:36 +0200, > blubee blubeeme wrote: > > > > I literally copy the entire url and add it to master_sites and it doesn't > > work! > > > > what does [:tl] even mean here? There's nothing about it on the whole > page: > > https://www.freebsd.org/doc/en/books/porters-handbook/ > makefile-distfiles.html > > % man 1 make > > :tl Converts variable to lower-case letters. > > -- > Herbert > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
graphics/togl [undefined reference]
I ran into an issue with linking -ltogl from graphics/togl I looked into it with ld -L/usr/local/lib -ltogl and there's undefined references to libc Is the port broken? How can I fix it? == attempt to open /usr/local/lib/libtogl.so succeeded -ltogl (/usr/local/lib/libtogl.so) libX11.so.6 needed by /usr/local/lib/libtogl.so found libX11.so.6 at /usr/local/lib/libX11.so.6 libGL.so.1 needed by /usr/local/lib/libtogl.so found libGL.so.1 at /usr/local/lib/libGL.so.1 libXmu.so.6 needed by /usr/local/lib/libtogl.so found libXmu.so.6 at /usr/local/lib/libXmu.so.6 libxcb.so.1 needed by /usr/local/lib/libX11.so.6 found libxcb.so.1 at /usr/local/lib/libxcb.so.1 libc.so.7 needed by /usr/local/lib/libX11.so.6 found libc.so.7 at //lib/libc.so.7 libnvidia-tls.so.1 needed by /usr/local/lib/libGL.so.1 found libnvidia-tls.so.1 at /usr/local/lib/libnvidia-tls.so.1 libnvidia-glcore.so.1 needed by /usr/local/lib/libGL.so.1 found libnvidia-glcore.so.1 at /usr/local/lib/libnvidia-glcore.so.1 libXext.so.6 needed by /usr/local/lib/libGL.so.1 found libXext.so.6 at /usr/local/lib/libXext.so.6 libXt.so.6 needed by /usr/local/lib/libXmu.so.6 found libXt.so.6 at /usr/local/lib/libXt.so.6 libXau.so.6 needed by /usr/local/lib/libxcb.so.1 found libXau.so.6 at /usr/local/lib/libXau.so.6 libpthread-stubs.so.0 needed by /usr/local/lib/libxcb.so.1 found libpthread-stubs.so.0 at /usr/local/lib/libpthread-stubs.so.0 libXdmcp.so.6 needed by /usr/local/lib/libxcb.so.1 found libXdmcp.so.6 at /usr/local/lib/libXdmcp.so.6 libm.so.5 needed by /usr/local/lib/libnvidia-glcore.so.1 found libm.so.5 at //lib/libm.so.5 libSM.so.6 needed by /usr/local/lib/libXt.so.6 found libSM.so.6 at /usr/local/lib/libSM.so.6 libICE.so.6 needed by /usr/local/lib/libXt.so.6 found libICE.so.6 at /usr/local/lib/libICE.so.6 ld: warning: cannot find entry symbol _start; not setting start address //lib/libc.so.7: undefined reference to `__progname' //lib/libc.so.7: undefined reference to `environ' ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: SF mastersites
@MarkMillard
Thank you for explaining that. Like you said there's lots of stuff that's
just not documented. How should I know that I should check the man page for
Makefile? I appreciate the help with that at least I'll be better informed
in the future.
Things like that should be in the porter handbook as subsections or
something.
On Sun, Oct 29, 2017 at 9:29 AM, Dave Horsfall wrote:
> On Sat, 28 Oct 2017, Mark Millard wrote:
>
> ${NAME:tl} is Makefile notation even in Makefiles having nothing to do
>> with ports (or potentially even FreeBSD). There probably is lots of
>> involved Makefile notation not separately documented in
>> makefile-distfiles.html or other parts of porters-handbook/ .
>>
>
> I've been using "make" since the PWB days, and this is news... The
> trouble is, one would have to suspect that this is yet another variant
> before looking for specific documentation (and I thought "gmake" was bad
> enough).
>
> At least my Makefiles and shell scripts will work anywhere; I don't make
> use of local "features".
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
> suffer."
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: graphics/togl [undefined reference]
Anyone have any tips on why compiling this i'm getting undefined reference? On Sat, Oct 28, 2017 at 11:47 PM, blubee blubeeme wrote: > I ran into an issue with linking -ltogl from graphics/togl > > > I looked into it with > ld -L/usr/local/lib -ltogl and there's undefined references to libc > > Is the port broken? How can I fix it? > > == > attempt to open /usr/local/lib/libtogl.so succeeded > -ltogl (/usr/local/lib/libtogl.so) > libX11.so.6 needed by /usr/local/lib/libtogl.so > found libX11.so.6 at /usr/local/lib/libX11.so.6 > libGL.so.1 needed by /usr/local/lib/libtogl.so > found libGL.so.1 at /usr/local/lib/libGL.so.1 > libXmu.so.6 needed by /usr/local/lib/libtogl.so > found libXmu.so.6 at /usr/local/lib/libXmu.so.6 > libxcb.so.1 needed by /usr/local/lib/libX11.so.6 > found libxcb.so.1 at /usr/local/lib/libxcb.so.1 > libc.so.7 needed by /usr/local/lib/libX11.so.6 > found libc.so.7 at //lib/libc.so.7 > libnvidia-tls.so.1 needed by /usr/local/lib/libGL.so.1 > found libnvidia-tls.so.1 at /usr/local/lib/libnvidia-tls.so.1 > libnvidia-glcore.so.1 needed by /usr/local/lib/libGL.so.1 > found libnvidia-glcore.so.1 at /usr/local/lib/libnvidia-glcore.so.1 > libXext.so.6 needed by /usr/local/lib/libGL.so.1 > found libXext.so.6 at /usr/local/lib/libXext.so.6 > libXt.so.6 needed by /usr/local/lib/libXmu.so.6 > found libXt.so.6 at /usr/local/lib/libXt.so.6 > libXau.so.6 needed by /usr/local/lib/libxcb.so.1 > found libXau.so.6 at /usr/local/lib/libXau.so.6 > libpthread-stubs.so.0 needed by /usr/local/lib/libxcb.so.1 > found libpthread-stubs.so.0 at /usr/local/lib/libpthread-stubs.so.0 > libXdmcp.so.6 needed by /usr/local/lib/libxcb.so.1 > found libXdmcp.so.6 at /usr/local/lib/libXdmcp.so.6 > libm.so.5 needed by /usr/local/lib/libnvidia-glcore.so.1 > found libm.so.5 at //lib/libm.so.5 > libSM.so.6 needed by /usr/local/lib/libXt.so.6 > found libSM.so.6 at /usr/local/lib/libSM.so.6 > libICE.so.6 needed by /usr/local/lib/libXt.so.6 > found libICE.so.6 at /usr/local/lib/libICE.so.6 > ld: warning: cannot find entry symbol _start; not setting start address > //lib/libc.so.7: undefined reference to `__progname' > //lib/libc.so.7: undefined reference to `environ' > > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Linker name mismatch
I'm compiling a port and the linker is failing because the linker is looking for -lUppercaseSoname but the shared object name doesn't start with an uppercase. Can I change the way the linker flags are passed to replace: -lSoname with -lsoname ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linker name mismatch
I'm pretty sure this is the reason the build is failing because running both these commands: % ld -L/usr/local/lib -lSoname ld: cannot find -lTogl % ld -L/usr/local/lib -lsoname ld: warning: cannot find entry symbol _start; not setting start address //lib/libc.so.7: undefined reference to `__progname' //lib/libc.so.7: undefined reference to `environ' On Sun, Oct 29, 2017 at 2:06 PM, blubee blubeeme wrote: > I'm compiling a port and the linker is failing because the linker is > looking for > > -lUppercaseSoname > > but the shared object name doesn't start with an uppercase. > > Can I change the way the linker flags are passed to replace: > -lSoname with -lsoname > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
USE_XORG
There's a program that uses these two X11 headers #include #include looking through this file: /usr/ports/Mk/bsd.xorg.mk to try to understand just which USE_XORG= x11 and what other modules flag to set? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: USE_XORG
@Yuri: that make stage-qa is very nice! Thanks On Mon, Oct 30, 2017 at 2:14 PM, Yuri wrote: > On 10/29/17 22:57, blubee blubeeme wrote: > >> looking through this file: /usr/ports/Mk/bsd.xorg.mk >> to try to understand just which USE_XORG= x11 >> >> and what other modules flag to set? >> > > > 'make stage-qa' usually suggests USE_XORG, and other USE_xxx values. > > > Yuri > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports with no SONAME
There's an unmaintained port [graphics/togl] that I need but doing stage-qa
on my port it says this needed port has no SONAME.
Since the togl is unmaintained I'll like to fix it. This port does a lot of
stuff like this:
# do-install:
# @${MKDIR} ${STAGEDIR}${TOGL_INSTDIR}
# .for i in togl.h togl_ws.h pkgIndex.tcl
# ${INSTALL_DATA} ${WRKSRC}/${i} ${STAGEDIR}${TOGL_INSTDIR}
# .endfor
# ${INSTALL_LIB} ${WRKSRC}/libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}
# ${LN} -s libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}/libtogl.so.1
# ${LN} -s ${TOGL_INSTDIR}/libTogl1.7.so
${STAGEDIR}${PREFIX}/lib/libtogl.so
# ${LN} -s ${TOGL_INSTDIR}/libTogl1.7.so
${STAGEDIR}${PREFIX}/lib/libtogl.so.1
# do-install-DOCS-on:
# @${MKDIR} ${STAGEDIR}${DOCSDIR}
# ${INSTALL_DATA} ${WRKSRC}/Togl.html ${STAGEDIR}${DOCSDIR}
# do-install-EXAMPLES-on:
# @${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/Makefile ${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/ben.rgb ${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/double.c ${WRKSRC}/double.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/gears.c ${WRKSRC}/gears.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/image.c ${WRKSRC}/image.h
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/index.c ${WRKSRC}/index.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/overlay.c ${WRKSRC}/overlay.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/stereo.c ${WRKSRC}/stereo.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/texture.c ${WRKSRC}/texture.tcl
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/togl.c ${WRKSRC}/togl.h
${STAGEDIR}${EXAMPLESDIR}
# ${INSTALL_DATA} ${WRKSRC}/tree2.rgba ${STAGEDIR}${EXAMPLESDIR}
I think this is the reason it's not registering the SONAME because of those
commands but I'm not sure.
I ask because reading the porter handbook on installing ports there's a
Makefile macro ${COPYTREE_SHARE} but there's a warning that using that
macro doesn't add the files to pkg-plist, you have to manually do that.
Anyways, that's a long way to say how can I rework this project to make
sure all files are installed and registered properly?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports with no SONAME
Seems like the soname issue has to do with the linker flags set during the
compilation process.
On Mon, Oct 30, 2017 at 7:37 PM, blubee blubeeme
wrote:
> There's an unmaintained port [graphics/togl] that I need but doing
> stage-qa on my port it says this needed port has no SONAME.
>
> Since the togl is unmaintained I'll like to fix it. This port does a lot
> of stuff like this:
>
> # do-install:
> # @${MKDIR} ${STAGEDIR}${TOGL_INSTDIR}
> # .for i in togl.h togl_ws.h pkgIndex.tcl
> # ${INSTALL_DATA} ${WRKSRC}/${i} ${STAGEDIR}${TOGL_INSTDIR}
> # .endfor
> # ${INSTALL_LIB} ${WRKSRC}/libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}
> # ${LN} -s libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}/libtogl.so.1
> # ${LN} -s ${TOGL_INSTDIR}/libTogl1.7.so ${STAGEDIR}${PREFIX}/lib/
> libtogl.so
> # ${LN} -s ${TOGL_INSTDIR}/libTogl1.7.so ${STAGEDIR}${PREFIX}/lib/
> libtogl.so.1
>
> # do-install-DOCS-on:
> # @${MKDIR} ${STAGEDIR}${DOCSDIR}
> # ${INSTALL_DATA} ${WRKSRC}/Togl.html ${STAGEDIR}${DOCSDIR}
>
> # do-install-EXAMPLES-on:
> # @${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/Makefile ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/ben.rgb ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/double.c ${WRKSRC}/double.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/gears.c ${WRKSRC}/gears.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/image.c ${WRKSRC}/image.h
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/index.c ${WRKSRC}/index.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/overlay.c ${WRKSRC}/overlay.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/stereo.c ${WRKSRC}/stereo.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/texture.c ${WRKSRC}/texture.tcl
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/togl.c ${WRKSRC}/togl.h
> ${STAGEDIR}${EXAMPLESDIR}
> # ${INSTALL_DATA} ${WRKSRC}/tree2.rgba ${STAGEDIR}${EXAMPLESDIR}
>
> I think this is the reason it's not registering the SONAME because of
> those commands but I'm not sure.
>
> I ask because reading the porter handbook on installing ports there's a
> Makefile macro ${COPYTREE_SHARE} but there's a warning that using that
> macro doesn't add the files to pkg-plist, you have to manually do that.
>
> Anyways, that's a long way to say how can I rework this project to make
> sure all files are installed and registered properly?
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports with no SONAME
PLTRELSZ0x6f0
PLTREL 0x7
JMPREL 0x3ca8
RELA0x2520
RELASZ 0x1788
RELAENT 0x18
VERDEF 0x24a8
VERDEFNUM 0x3
VERNEED 0x2500
VERNEEDNUM 0x1
VERSYM 0x2372
RELACOUNT 0xdd
Version definitions:
1 0x01 0x0cca1178 libjpeg.so.8
2 0x00 0x0939efd0 LIBJPEGTURBO_8.0
3 0x00 0x04cdfde0 LIBJPEG_8.0
Version References:
required from libc.so.7:
0x077a28b0 0x00 04 FBSD_1.0
Sections:
Idx Name Size VMA LMA File off
Algn
0 .hash 047c 0158 0158 0158
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .gnu.hash 04ac 05d8 05d8 05d8
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynsym 0e70 0a88 0a88 0a88
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynstr 0a79 18f8 18f8 18f8
2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .gnu.version 0134 2372 2372 2372
2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.version_d 0054 24a8 24a8 24a8
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version_r 0020 2500 2500 2500
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rela.dyn 1788 2520 2520 2520
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.plt 06f0 3ca8 3ca8 3ca8
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .init 0013 4398 4398 4398
2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .plt 04b0 43ac 43ac 43ac
2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .text 00044b28 4860 4860 4860
2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .fini 000e 00049388 00049388 00049388
2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .rodata 00023520 000493a0 000493a0 000493a0
2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 .eh_frame_hdr 0bcc 0006c8c0 0006c8c0 0006c8c0
2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 .eh_frame 34bc 0006d490 0006d490 0006d490
2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .ctors0010 00271000 00271000 00071000
2**3
CONTENTS, ALLOC, LOAD, DATA
17 .dtors0010 00271010 00271010 00071010
2**3
CONTENTS, ALLOC, LOAD, DATA
18 .jcr 0008 00271020 00271020 00071020
2**3
CONTENTS, ALLOC, LOAD, DATA
19 .data.rel.ro 0590 00271030 00271030 00071030
2**4
CONTENTS, ALLOC, LOAD, DATA
20 .dynamic 01c0 002715c0 002715c0 000715c0
2**3
CONTENTS, ALLOC, LOAD, DATA
21 .got 0240 00271780 00271780 00071780
2**3
CONTENTS, ALLOC, LOAD, DATA
22 .got.plt 0268 002719c0 002719c0 000719c0
2**3
CONTENTS, ALLOC, LOAD, DATA
23 .data 0018 00271c28 00271c28 00071c28
2**3
CONTENTS, ALLOC, LOAD, DATA
24 .bss 0008 00271c40 00271c40 00071c40
2**2
ALLOC
25 .comment 00e1 00071c40
2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols
How can I edit the makefile to add the soname to the lib?
On Mon, Oct 30, 2017 at 11:52 PM, blubee blubeeme
wrote:
> Seems like the soname issue has to do with the linker flags set during the
> compilation process.
>
> On Mon, Oct 30, 2017 at 7:37 PM, blubee blubeeme
> wrote:
>
>> There's an unmaintained port [graphics/togl] that I need but doing
>> stage-qa on my port it says this needed port has no SONAME.
>>
>> Since the togl is unmaintained I'll like to fix it. This port does a lot
>> of stuff like this:
>>
>> # do-install:
>> # @${MKDIR} ${STAGEDIR}${TOGL_INSTDIR}
>> # .for i in togl.h togl_ws.h pkgIndex.tcl
>> # ${INSTALL_DATA} ${WRKSRC}/${i} ${STAGEDIR}${TOGL_INSTDIR}
>> # .endfor
>> # ${INSTALL_LIB} ${WRKSRC}/libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}
>> # ${LN} -s libTogl1.7.so ${STAGEDIR}${TOGL_INSTDIR}/libtogl.so.1
>> # ${LN} -s ${TOGL_INSTDIR}/libTogl1.7.so ${STAGEDIR}${PREFIX}/lib/libt
>> ogl.so
>> # ${LN} -s ${
[New PR] audio/amsynth
can I have someone take a look at this bug report for a new port amsynth: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223361 also can someone please check the status of this other post as well archivers/zipios https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223176 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Port adding NLS switch
This is a portlint warning that I am getting for a port, how do I fix it? WARN: Makefile: Consider adding support for a NLS knob to conditionally disable gettext support. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting message [set runtime path of...]
I am creating a port and doing make it shows -- Set runtime path of "/usr/ports/lib.so" to "/usr/local/lib" Does that mean that I should set a symbolic link or is it just something that the port make system is doing automatically. Do I need to worry about it? If I do, how do I fix it? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
