Update libtool to version 2.5.3 (includes support for aarch64-w64-mingw32)
Hello, GCC development branch includes experimental support Windows on ARM64 (WOA), which will be officially released with version 15, at least according to latest news. I already compiled successfully GCC, binutils and lot of the "noarch" packages already available for i686 and x86_64, by using the new aarch64-w64-mingw32 cross compiler. Unfortunately, I discovered that there was a bug in libtool that blocked the creation of shared libraries with aarch64-w64-mingw32. I reported the bug here: https://savannah.gnu.org/support/?111081 and it has been fixed by a patch included into the latest 2.5.3 version. That patch includes support for pe-aarch64 and it solved the issues, at least on my side. I already downloaded the src package of libtool for CYGWIN and I updated my local copy. However, I'm wondering if it would be possible to release an official update of libtool to version 2.5.3, for having this fix available to everyone. Sincerely, Carlo Bramini. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: CYGPORT not setting CMAKE_SYSTEM_PROCESSOR when cross compiling with aarch64-w64-mingw32.
Hello,
thank you for your reply.
The patch is a good start to me.
However, I think that it would be better to remove the error if CHOST
or CTARGET include something different from x86_64, i686 or aarch64.
Otherwise, you won't be able to cross compile anything with CMake,
except for those CPUs.
Instead, in my opinion it would be better to return an empty string,
to be assigned to a variable at the calling function.
So, if that variable will not empty, then CMAKE_SYSTEM_PROCESSOR will
be appended to crossargs with that value.
Otherwise, CMAKE_SYSTEM_PROCESSOR won't be added to crossargs and it
will work as it worked until now.
According to the documentation:
https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html
when it is not cross compiling, CMake assignes the return value of
"uname" to CMAKE_SYSTEM_PROCESSOR.
So, some of the possible values of that variable could be:
alpha
arc
arm
aarch64_be (arm64 big endian)
aarch64 (arm64)
armv8b (arm64 compat big endian)
armv8l (arm64 compat little endian)
blackfin
c6x
cris
frv
h8300
hexagon
ia64
m32r
m68k
metag
microblaze
mips (native or compat)
mips64 (mips)
mn10300
nios2
openrisc
parisc (native or compat)
parisc64 (parisc)
ppc (powerpc native or compat)
ppc64 (powerpc)
ppcle (powerpc native or compat little endian)
ppc64le (powerpc little endian)
s390 (s390x compat)
s390x
score
sh
sh64 (sh)
sparc (native or compat)
sparc64 (sparc)
tile
unicore32
i386 (x86)
i686 (x86 compat)
x86_64 (x64)
xtensa
If there will be the need to add some of them in the future, somebody
may add them.
Perhaps, it would be useful to add also this information to the patch
as a comment, just for reference.
Thank you very much for your time.
Sincerely,
Carlo Bramini.
Il giorno sab 20 lug 2024 alle ore 20:18 Jon Turney
ha scritto:
>
> On 19/07/2024 09:08, Carlo B. via Cygwin wrote:
> > Hello,
> >
> > GCC development branch includes experimental support Windows on ARM64
> > (WOA), which will be officially released next year with version 15, at
> > least according to latest news.
> > So, I compiled it and I created a number of packages for CYGWIN
> > including binutils, gcc, mingw runtime and several libraries, not
> > released yet to my repository.
> > Although the "aarch64-w64-mingw32" target is still experimental, I
> > have to say that this cross compiler worked very well, at least until
> > now.
>
> Great work! We'd certainly welcome and appreciate your help getting
> packages for this into our repository, also.
>
> > However, some problems appear because there are some thirdy party
> > tools not expecting to have mingw combined with something different
> > than i686 or x86_64.
> > For example, it is impossible to create a shared library when using
> > libtool, more details could be found here:
> > https://savannah.gnu.org/support/?111081
>
> Huh. I guess someone should fix that, then!
>
> I think for a start, the regex around line 5724 in libtool (near the
> comment about keeping it in sync with _LT_CHECK_MAGIC_METHOD) needs
> updating to match arm64 archives...
>
> > For this reason, you have to use CMake or other alternative tools
> > instead of autotools.
> >
> > Actually, another problem can happen when creating the packages for
> > CYGWIN with CYGPORT utility.
> > For example, I tried to build a noarch package of libpng for CYGWIN,
> > by using the new aarch64-w64-mingw32.
> > I have used CMake to bypass the above trouble with libtool.
> > Unfortunately, the build process still fails because it didn't compile
> > the sources for adding the functions with NEON acceleration.
> > The cause of the problem is the variable CMAKE_SYSTEM_PROCESSOR that is
> > empty.
> > This is not a bug of CMake, because CMAKE_SYSTEM_PROCESSOR is
> > typically set into CMAKE_TOOLCHAIN_FILE by the user when cross
> > compiling.
> > At the moment, I bypassed the trouble by adding
> > "-DCMAKE_SYSTEM_PROCESSOR=aarch64" to CYGCMAKE_ARGS into my script.
> > I gave a look into /usr/share/cygport/cygclass/cmake.cygclass and it
> > seems to me that there is nothing for setting the CPU type.
> > Perhaps it would be worth to add support for setting
> > CMAKE_SYSTEM_PROCESSOR into cmake.cygclass, by checking the content of
> > ${CTARGET}, if it exists with a known CPU.
>
> Interesting.
>
> I took a look and there are several existing packages which have been
> cross-built for x86 and x86_64 MinGW using cmake, so either it seems
> this hasn't yet appeared as a problem for those ar
CYGPORT not setting CMAKE_SYSTEM_PROCESSOR when cross compiling with aarch64-w64-mingw32.
Hello,
GCC development branch includes experimental support Windows on ARM64
(WOA), which will be officially released next year with version 15, at
least according to latest news.
So, I compiled it and I created a number of packages for CYGWIN
including binutils, gcc, mingw runtime and several libraries, not
released yet to my repository.
Although the "aarch64-w64-mingw32" target is still experimental, I
have to say that this cross compiler worked very well, at least until
now.
However, some problems appear because there are some thirdy party
tools not expecting to have mingw combined with something different
than i686 or x86_64.
For example, it is impossible to create a shared library when using
libtool, more details could be found here:
https://savannah.gnu.org/support/?111081
For this reason, you have to use CMake or other alternative tools
instead of autotools.
Actually, another problem can happen when creating the packages for
CYGWIN with CYGPORT utility.
For example, I tried to build a noarch package of libpng for CYGWIN,
by using the new aarch64-w64-mingw32.
I have used CMake to bypass the above trouble with libtool.
Unfortunately, the build process still fails because it didn't compile
the sources for adding the functions with NEON acceleration.
The cause of the problem is the variable CMAKE_SYSTEM_PROCESSOR that is empty.
This is not a bug of CMake, because CMAKE_SYSTEM_PROCESSOR is
typically set into CMAKE_TOOLCHAIN_FILE by the user when cross
compiling.
At the moment, I bypassed the trouble by adding
"-DCMAKE_SYSTEM_PROCESSOR=aarch64" to CYGCMAKE_ARGS into my script.
I gave a look into /usr/share/cygport/cygclass/cmake.cygclass and it
seems to me that there is nothing for setting the CPU type.
Perhaps it would be worth to add support for setting
CMAKE_SYSTEM_PROCESSOR into cmake.cygclass, by checking the content of
${CTARGET}, if it exists with a known CPU.
Thank you very much for your time.
Sincerely,
Carlo Bramini.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Installing/upgrading only NOARCH packages.
Hello, after the 32-bit port of CYGWIN has been obsoleted, I was looking for a way for installing or upgrading the NOARCH packages, like the libraries for the mingw cross compilers for example. Unfortunately, I have not found an existing way for doing it. Is it possible to do it? Otherwise, I'm searching for the sources of the setup program for adding this feature in my local installation. I have seen that setup utility has a "--arch" option, but it accepts only "x86_64" or "x86", according to the "--help" printed on screen. So, I'm planning to add a "noarch" in addition to "x86_64" and "x86" to this option. Where can I get the latest development sources of the setup utility? Thank you very much for your replies. Sincerely, Carlo Bramini. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Bug in CYGWIN's UUID library: GUID_NULL not found.
I see... problem solved.
Thank you very much.
Sincerely,
Carlo Bramini.
Il giorno lun 20 feb 2023 alle ore 17:01 Takashi Yano
ha scritto:
>
> On Mon, 20 Feb 2023 16:48:50 +0100
> "Carlo B. wrote:
> > Hello,
> > I think that there is a bug into the uuid library, the one to be used
> > with the W32API for the POSIX core.
> > Please have a look to the following tiny test code:
> >
> > //
> > #include
> > #include
> > #include
> > #include
> >
> > int main()
> > {
> >
> > printf("GUID_NULL=\"%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\"\n",
> > GUID_NULL.Data1,
> > GUID_NULL.Data2, GUID_NULL.Data3,
> > GUID_NULL.Data4[0], GUID_NULL.Data4[1],
> > GUID_NULL.Data4[2], GUID_NULL.Data4[3],
> > GUID_NULL.Data4[4], GUID_NULL.Data4[5],
> > GUID_NULL.Data4[6], GUID_NULL.Data4[7]
> > );
> >
> > return 0;
> > }
> > //
> >
> > Compiling it with x86_64-pc-cygwin or i686-pc-cygwin does not work:
> >
> > $ gcc e.c -o e.exe -luuid
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> > /tmp/ccyJK3d9.o:e.c:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0):
> > undefined reference to `GUID_NULL'
> > collect2: error: ld returned 1 exit status
>
> You linked /usr/lib/libuuid.dll.a rather than /usr/lib/w32api/libuuid.a.
> You might want: gcc e.c -o e.exe -L/usr/lib/w32api -luuid
>
> --
> Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Bug in CYGWIN's UUID library: GUID_NULL not found.
Hello,
I think that there is a bug into the uuid library, the one to be used
with the W32API for the POSIX core.
Please have a look to the following tiny test code:
//
#include
#include
#include
#include
int main()
{
printf("GUID_NULL=\"%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\"\n",
GUID_NULL.Data1,
GUID_NULL.Data2, GUID_NULL.Data3,
GUID_NULL.Data4[0], GUID_NULL.Data4[1],
GUID_NULL.Data4[2], GUID_NULL.Data4[3],
GUID_NULL.Data4[4], GUID_NULL.Data4[5],
GUID_NULL.Data4[6], GUID_NULL.Data4[7]
);
return 0;
}
//
Compiling it with x86_64-pc-cygwin or i686-pc-cygwin does not work:
$ gcc e.c -o e.exe -luuid
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/tmp/ccyJK3d9.o:e.c:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0):
undefined reference to `GUID_NULL'
collect2: error: ld returned 1 exit status
But it works fine when using MinGW-w64 compilers:
$ x86_64-w64-mingw32-gcc e.c -o e.exe -luuid
$ ./e.exe
GUID_NULL="----"
I discovered this issue when making a new FluidSynth package for
CYGWIN for my repository of packages.
Can you confirm it?
Thank you very much for your time.
Sincerely,
Carlo Bramini.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: CYGPORT: using WAF build system.
Hello,
in addition to my previous message, I would like to say that I tried
to build the existing old sources of lv2-1.12.0-1.x86_64 package, but
an error is generated.
I attached what happens and I hope that you will find this report useful.
Sincerely.
=
$ cygport lv2.cygport all
>>> Preparing lv2-1.12.0-1.x86_64
>>> Unpacking source lv2-1.12.0.tar.bz2
*** Info: applying patch 1.12.0-cygwin-shlib.patch (-p2):
patching file plugins/eg-amp.lv2/wscript
patching file plugins/eg-fifths.lv2/wscript
patching file plugins/eg-metro.lv2/wscript
patching file plugins/eg-midigate.lv2/wscript
patching file plugins/eg-sampler.lv2/wscript
patching file plugins/eg-scope.lv2/wscript
>>> Preparing working source directory
>>> Compiling lv2-1.12.0-1.x86_64
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 293, in ant_iter
raise StopIteration
StopIteration
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 103, in waf_entry_point
run_commands()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 160, in run_commands
parse_options()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 133, in parse_options
Context.create_context('options').execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Options.py",
line 141, in execute
super(OptionsContext,self).execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 92, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 133, in recurse
user_function(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/wscript",
line 25, in options
opt.load('compiler_c')
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 89, in load
fun(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Tools/compiler_c.py",
line 36, in options
opt.load_special_tools('c_*.py',ban=['c_dumbpreproc.py'])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 296, in load_special_tools
lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in ant_glob
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
RuntimeError: generator raised StopIteration
*** ERROR: waf configure failed
Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis
ha scritto:
>
> On 2021-10-14 04:02, Carlo B. via Cygwin wrote:
> > I would like to make a package with LV2 plugins for CYGWIN.
> > The problem is that those plugins are using the WAF build system and
> > it is not clear to me how to proceed. Do you know if some of the
> > existing packages for CYGWIN are using WAF, so that they could be uses
> > as example for starting?
>
> In connection with other queries, I just came across a few lv2 packages
> already available in Cygwin:
>
> lv2
> lv2core
> lv2-calf
> lv2-devel
> lv2-examples
> lv2-swh
>
> slv2
> libslv2_9
> libslv2-devel
>
> with cygpo
Re: CYGPORT: using WAF build system.
Hello, thank you very much for the replies. I have successfully compiled lv2, lilv, serd, sord, sratom (but not suil yet) for CYGWIN and I made the packages for building the master branch of Audacity. I also tried to do the same thing for i686 and x86_64, by using provided MinGW-w64 cross compiler, but I'm getting this message: *** ERROR: waf.cygclass does not yet support cross-compiling I hope that somebody may fix this in the future. Sincerely. Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis ha scritto: > > On 2021-10-14 04:02, Carlo B. via Cygwin wrote: > > I would like to make a package with LV2 plugins for CYGWIN. > > The problem is that those plugins are using the WAF build system and > > it is not clear to me how to proceed. Do you know if some of the > > existing packages for CYGWIN are using WAF, so that they could be uses > > as example for starting? > > In connection with other queries, I just came across a few lv2 packages > already available in Cygwin: > > lv2 > lv2core > lv2-calf > lv2-devel > lv2-examples > lv2-swh > > slv2 > libslv2_9 > libslv2-devel > > with cygport build control script definitions and patches available > which use WAF: > > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2-swh.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/slv2.git > > so you could install cygport and any *lv2* package dependencies, clone > these repos or download and untar the current source packages which > contain these files plus upstream tars, and build the current packages > as a proof of concept and way of learning cygport, before trying to > build more current versions. > > The simple approach to running cygport is to change to the directory > containing the .cygport definitions and .patch file(s) or move them to a > working directory (normally named for the source package), then run e.g. > > $ cygport lv2.cygport get prep > > which downloads the upstream (not Cygwin) package sources for the > specified version to a central cache directory, creates a package build > directory, copies or untars sources if required, and (tries to) apply > any patches to the original sources, to give you working sources, which > you can then use to compile and make install-able Cygwin packages for > the current arch. > You can try one of the following examples, depending whether you want to > watch the builds run or review the results later: > > $ cygport lv2.cygport all |& tee lv2-cygport-`arch`-all.log > > $ cygport lv2.cygport all | tee lv2-cygport-`arch`-all.log 2>&1 > > $ cygport lv2.cygport all &> tee lv2-cygport-`arch`-all.log & > >$ cygport lv2.cygport all > tee lv2-cygport-`arch`-all.log 2>&1 & > > Browse the created build subdirectories to see what is produced and > review all detail logs generated during the process. > > After a successful build and package creation, it is always a good idea > to try to run any test suites with: > >$ cygport lv2.cygport check > tee lv2-cygport-`arch`-check.log 2>&1 & > > I use the cygport command check instead of test as test is used > ambiguously by cygport, as it may also refer to test vs stable or > production releases produced by cygport using commands e.g. all-test. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
CYGPORT: using WAF build system.
Hello, I would like to make a package with LV2 plugins for CYGWIN. The problem is that those plugins are using the WAF build system and it is not clear to me how to proceed. Do you know if some of the existing packages for CYGWIN are using WAF, so that they could be uses as example for starting? Thank you very much. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
> If you look at the Cygport Install Functions docs for docinto, ...into,
> defining target directories, you would see that an "absolute" path
> disables cygport from prefixing a subdirectory name with the package
> name, etc. so CMakeLists.txt is (linked) under ${S,B}/cmake, and cygport
> will automatically find that, so it should not be required or specified:
>
> https://cygwin.github.io/cygport/cmake_cygclass.html#robo767
>
cygport does not find it.
If CYGCMAKE_SOURCE is not defined into my liblo.cygport, it prints:
*** ERROR: cygcmake: cmake directory not found
If CYGCMAKE_SOURCE is defined as "${S}/cmake", it prints again:
*** ERROR: cygcmake: cmake directory not found
If CYGCMAKE_SOURCE is defined as an absolute path like I have written
in my previous message, it finally works.
> "This is only necessary when the top-level CMakeLists.txt is not in $S
> and cygcmake is not being run in the same subdirectory of $B which under
> $S contains the top-level CMakeLists.txt. (IOW if the top-level
> CMakeLists.txt is in $S/unix and cygcmake is run from $B/unix, setting
> CYGCMAKE_SOURCE would not be necessary.)"
"This is only necessary when the top-level CMakeLists.txt is not in $S"
true, it is under "$S/cmake"
"and cygcmake is not being run in the same subdirectory of $B which
under $S contains the top-level CMakeLists.txt."
also true in my opinion.
It could be possible that I have not understood something, but however
there is also an easy way:
- my cygport file was included in my first email and also attached
into this last one.
- the source archive can be downloaded from this direct link:
http://downloads.sourceforge.net/liblo/liblo-0.31.tar.gz
- put both them into a directory and execute:
cygport liblo.cygport all
and you will see with your eyes that it does not work.
Perhaps, there are other extra things to write in my cygport that I
don't know about.
thank you very much for your support.
Sincerely.
liblo.cygport
Description: Binary data
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
in addition to my previous message, I did some experiments with the
code of cygport and I added these lines to
/usr/share/cygport/cygclass/cmake.cygclass:
echo "CYGCMAKE_SOURCE=${CYGCMAKE_SOURCE}"
echo "B=${B}"
echo "S=${S}"
echo "PWD=${PWD}"
and the result is:
CYGCMAKE_SOURCE=/cmake
B=/home/carlo/liblo.src/liblo-0.31-1.x86_64/build
S=/home/carlo/liblo.src/liblo-0.31-1.x86_64/src/liblo-0.31
PWD=/home/carlo/liblo.src/liblo-0.31-1.x86_64/build
*** ERROR: cygcmake: cmake directory not found
But ${CYGCMAKE_SOURCE} was set as:
CYGCMAKE_SOURCE="${S}/cmake"
So, it seems to me that there is at least a bug into the
documentation, because ${CYGCMAKE_SOURCE} does not seem to allow the
use of {S}.
I was able to make it working by writing:
CYGCMAKE_SOURCE="$(pwd)/${NAME}-${VERSION}-${RELEASE}.${ARCH}/src/${NAME}-${VERSION}/cmake"
but I don't know if this is the right way to do it and could be accepted or not.
Sincerely.
Il giorno gio 16 set 2021 alle ore 17:18 Carlo B.
ha scritto:
>
> Hello,
> I'm trying to make a package for CYGWIN to provide liblo, but I'm
> having some difficulties.
> This library is available to the most used linux distributions (but
> not limited to), here there is the link to the one into a Debian as
> example:
>
> https://packages.debian.org/buster/liblo-dev
>
> I implemented a script for cygport but this is the output on the
> console when I execute it:
>
> $ cygport liblo.cygport all
> >>> Preparing liblo-0.31-1.x86_64
> >>> Unpacking source liblo-0.31.tar.gz
> >>> Preparing working source directory
> >>> Compiling liblo-0.31-1.x86_64
> *** ERROR: cygcmake: cmake directory not found
>
> The unique aspect of this library is that the CMakeLists.txt file is
> not into the root of the source tree, but it is located into a
> subfolder, see here:
>
> https://github.com/radarsat1/liblo/tree/master/cmake
>
> So, in my script, I configured ${CYGCMAKE_SOURCE} to point there, but
> it still cannot make it working. Since it seems that I'm not able to
> make it working in any way, I'm wondering if the behaviour of this
> variable has been ever tested, so I'm writing here with the hope to
> receive a suggestion.
>
> Thank you very much for your support.
>
> ===> And this is the content of my liblo.cygport file:
>
> inherit cmake
>
> NAME="liblo"
> VERSION=0.31
> RELEASE=1
> CATEGORY="Audio"
> SUMMARY="Open Sound Control protocol for POSIX systems"
> DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
> among computers, sound synthesizers, and other multimedia devices that
> is optimized for modern networking technology."
> HOMEPAGE="http://liblo.sourceforge.net/";
> SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz";
>
> PKG_NAMES="liblo1 liblo-devel"
> PKG_IGNORE="
> usr/share/doc/liblo/AUTHORS
> usr/share/doc/liblo/COPYING
> usr/share/doc/liblo/ChangeLog
> usr/share/doc/liblo/NEWS
> usr/share/doc/liblo/README
> usr/share/doc/liblo/TODO
> "
>
> liblo1_CATEGORY="Libs"
> liblo1_SUMMARY="${SUMMARY}"
> liblo1_CONTENTS="
> usr/bin/cyglo-7.dll
> usr/bin/oscdump.exe
> usr/bin/oscsend.exe
> "
> liblo_devel_CATEGORY="Libs"
> liblo_devel_SUMMARY="${SUMMARY}"
> liblo_devel_CONTENTS="
> usr/include/lo/*
> usr/lib/liblo.dll.a
> usr/lib/pkgconfig/liblo.pc
> usr/lib/cmake/liblo/libloConfig.cmake
> "
>
> CYGCMAKE_SOURCE="${S}/cmake"
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
thank you for your message,
> Worked just fine for a recent update of fortune-mod.
>
I gave a look to the source tree inside the package
fortune-mod-3.6.1-1-src.tar.xz and the CMakeLists.txt is into the
top-level directory, so it is not the same thing. And it seems to me
that ${CYGCMAKE_SOURCE} is not used by fortune-mod.cygport.
> See online or under your Cygwin directory:
>
> https://cygwin.github.io/cygport/cmake_cygclass.html#robo765
>
> cygstart /usr/share/doc/cygport/html/manual/cmake_cygclass.html
>
Yes, I had read that.
> Try directory specification rather than path - cygport often just DTRT:
>
> CYGCMAKE_SOURCE=cmake
>
Yes, I had also tried that, but without success.
Sincerely.
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>
>
> > ===> And this is the content of my liblo.cygport file:
> >
> > inherit cmake
> >
> > NAME="liblo"
> > VERSION=0.31
> > RELEASE=1
> > CATEGORY="Audio"
> > SUMMARY="Open Sound Control protocol for POSIX systems"
> > DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
> > among computers, sound synthesizers, and other multimedia devices that
> > is optimized for modern networking technology."
> > HOMEPAGE="http://liblo.sourceforge.net/";
> > SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz";
> >
> > PKG_NAMES="liblo1 liblo-devel"
> > PKG_IGNORE="
> > usr/share/doc/liblo/AUTHORS
> > usr/share/doc/liblo/COPYING
> > usr/share/doc/liblo/ChangeLog
> > usr/share/doc/liblo/NEWS
> > usr/share/doc/liblo/README
> > usr/share/doc/liblo/TODO
> > "
> >
> > liblo1_CATEGORY="Libs"
> > liblo1_SUMMARY="${SUMMARY}"
> > liblo1_CONTENTS="
> > usr/bin/cyglo-7.dll
> > usr/bin/oscdump.exe
> > usr/bin/oscsend.exe
> > "
> > liblo_devel_CATEGORY="Libs"
> > liblo_devel_SUMMARY="${SUMMARY}"
> > liblo_devel_CONTENTS="
> > usr/include/lo/*
> > usr/lib/liblo.dll.a
> > usr/lib/pkgconfig/liblo.pc
> > usr/lib/cmake/liblo/libloConfig.cmake
> > "
> >
> > CYGCMAKE_SOURCE="${S}/cmake"
>
> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
I'm trying to make a package for CYGWIN to provide liblo, but I'm
having some difficulties.
This library is available to the most used linux distributions (but
not limited to), here there is the link to the one into a Debian as
example:
https://packages.debian.org/buster/liblo-dev
I implemented a script for cygport but this is the output on the
console when I execute it:
$ cygport liblo.cygport all
>>> Preparing liblo-0.31-1.x86_64
>>> Unpacking source liblo-0.31.tar.gz
>>> Preparing working source directory
>>> Compiling liblo-0.31-1.x86_64
*** ERROR: cygcmake: cmake directory not found
The unique aspect of this library is that the CMakeLists.txt file is
not into the root of the source tree, but it is located into a
subfolder, see here:
https://github.com/radarsat1/liblo/tree/master/cmake
So, in my script, I configured ${CYGCMAKE_SOURCE} to point there, but
it still cannot make it working. Since it seems that I'm not able to
make it working in any way, I'm wondering if the behaviour of this
variable has been ever tested, so I'm writing here with the hope to
receive a suggestion.
Thank you very much for your support.
===> And this is the content of my liblo.cygport file:
inherit cmake
NAME="liblo"
VERSION=0.31
RELEASE=1
CATEGORY="Audio"
SUMMARY="Open Sound Control protocol for POSIX systems"
DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
among computers, sound synthesizers, and other multimedia devices that
is optimized for modern networking technology."
HOMEPAGE="http://liblo.sourceforge.net/";
SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz";
PKG_NAMES="liblo1 liblo-devel"
PKG_IGNORE="
usr/share/doc/liblo/AUTHORS
usr/share/doc/liblo/COPYING
usr/share/doc/liblo/ChangeLog
usr/share/doc/liblo/NEWS
usr/share/doc/liblo/README
usr/share/doc/liblo/TODO
"
liblo1_CATEGORY="Libs"
liblo1_SUMMARY="${SUMMARY}"
liblo1_CONTENTS="
usr/bin/cyglo-7.dll
usr/bin/oscdump.exe
usr/bin/oscsend.exe
"
liblo_devel_CATEGORY="Libs"
liblo_devel_SUMMARY="${SUMMARY}"
liblo_devel_CONTENTS="
usr/include/lo/*
usr/lib/liblo.dll.a
usr/lib/pkgconfig/liblo.pc
usr/lib/cmake/liblo/libloConfig.cmake
"
CYGCMAKE_SOURCE="${S}/cmake"
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
GLM for MinGW at same version of the ones for CYGWIN?
Hello, with reference to this thread: https://cygwin.com/pipermail/cygwin/2020-December/247106.html recently, GLM for CYGWIN has been updated to 0.9.9.5. I'm wondering if it would be possible to do the same thing and update the GLM packages for MinGW to the same version. An update will simplify some things because, unlike 0.9.7, no additional patches are required. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: How to configuring a cross compiler for ARM Cortex M4F from GCC using Cygwin
Hello, Il giorno dom 28 feb 2021 alle ore 09:29 Welwin Joseph via Cygwin ha scritto: > > Hi, > I am new to the concept of configuring crosscompiler from GCC , can anyone > guide me on how to create/ Configure a cross compiler from GCC compiler for > ARM cortex M4F using Cygwin. I am using a windows 10 PC, my target is arm > cortexM4F TM4C129ENCPDT and I am using it as bareboard (no OS). > > > With regards, > Welwin > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple In my opinion, the best way for getting what you need is to use crosstool-ng: https://github.com/crosstool-ng/crosstool-ng You can clone the repo, build and install the program. Then, you can use ct-ng for configuring the build with the platform you want and finally start the creation. When the process finishes, you will find your cross compiler into the "x-tools" directory, inside your $HOME. When you get it, it is very easy to create a cross compiler: with this tool, I created an arm-none-eabi with NEWLIB, an aarch64 android cross compiler with NDK and an armhf linux cross compiler. I suggest you to do a try with this tiny thing. Please note that after you start the build, the tool automatically downloads the tar files with the sources that it needs, unless it already finds them in its directory, so be careful if you have a limited amount of internet traffic available. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Error with wxWidgets 3.0.5 for CYGWIN.
Hello, after updating some packages, I tried to rebuild my Kicad sources and I discovered that I could not do it anymore. During the process, it hangs with this error: error: 'wxRE_ADVANCED' was not declared in this scope. It seems that the new package of wxWidgets 3.0.5 had not been compiled with built-in regex support, including wxRE_ADVANCED option. I downgraded to wxWidgets 3.0.4 and I was able to build everything again. I hope that you could fix this issue. Sincerely. Carlo Bramini. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: New version of GLM package?
Hello, Il giorno dom 20 dic 2020 alle ore 14:32 Marco Atzeri via Cygwin ha scritto: > > On 20.12.2020 12:58, Carlo B. via Cygwin wrote: > > Hello, > > perhaps, if copying the files by hand is too heavy as another user > > said, it is possible to use version 0.9.9.5, as I had written here: > > > > https://cygwin.com/pipermail/cygwin/2020-August/245981.html > > > > it is not the latest version, but it is surely much newer than 0.9.7: > > you just need to change version number and remove the patch now > > useless from glm.cygport. > > > > Sincerely. > > > > bottom post here, please > > > 0.9.9.5 is up, let us know if there is any issue > > Regards > Marco Thank you very much, the package has been updated and it is working fine for me. Perhaps, while we are on the topic, it would be worth to update also the packages for MinGW. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: New version of GLM package?
Hello, perhaps, if copying the files by hand is too heavy as another user said, it is possible to use version 0.9.9.5, as I had written here: https://cygwin.com/pipermail/cygwin/2020-August/245981.html it is not the latest version, but it is surely much newer than 0.9.7: you just need to change version number and remove the patch now useless from glm.cygport. Sincerely. Il giorno dom 20 dic 2020 alle ore 11:56 Marco Atzeri via Cygwin ha scritto: > > back on the mailing list > > On 20.12.2020 00:23, Hans-Bernhard Bröker wrote: > > Am 19.12.2020 um 19:21 schrieb Marco Atzeri via Cygwin: > > > >> for what I can see upstream has completely removed the install > >> section from the cmake files on 0.9.9.8 . > >> > >> unclear why they performed such issue. > > > > Possibly because there isn't all that much to install for a "library" > > that does not actually contain any compiled files, because it consists > > of nothing but inlined templates in header files. > > > > I.e. the binary package would just be a subset of the source in a > > different place. > > > > They seem to assume that the cmake script snippet they offer is > > sufficient to make the package count as "installed", because that (with > > an environment variable on top) allows the package to be found by CMake > > packages. The canonical method would probably be a CPack package. > > Hi Hans, > > I have impression debian is using such assumption and copy just the > files in the proper place. > It is annoying anyway. > > The fact that the github repository seems to not have the "issues" > is another annoying problem of this package. > > Regards > Marco > > > > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
New version of GLM package?
Hello everyone, I'm wondering if it would be possible to release a newer version of this package and also fixing this bug if it is possible: https://cygwin.com/pipermail/cygwin/2020-August/245945.html Thank you very much for your time and your support. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Build of glm-0.9.7.6-1-src.tar.xz does not work.
Hello, thank you very much, your updated script allowed me to complete the rebuilt process. KiCad requires GLM version 0.9.8 or newer for compiling. Unfortunately, I discovered that just replacing the old sources with the latest ones is not enough for updating the library. Since version 0.9.9.6, the install and uninstall targets have been removed from generated Makefile: https://github.com/g-truc/glm/commit/5f352ecce21bb1ab37fa56fac0f383c779b351a3#diff-af3b638bc2a3e6c650974192a53c7291 So, the current cygport script is able to work up to version 0.9.9.5, which is enough for the task anyways. Perhaps, the newer versions are using CMake directly for doing installation, but I have no idea how this is expected to work in cygport. Thank you very much for your time and your support. Sincerely, Il giorno dom 23 ago 2020 alle ore 18:04 Marco Atzeri via Cygwin ha scritto: > > On 23.08.2020 17:30, Jon Turney wrote: > > On 22/08/2020 06:00, Marco Atzeri via Cygwin wrote: > >> On 21.08.2020 10:35, Carlo B. via Cygwin wrote: > >>> Hello, > >>> I tried to rebuild glm-0.9.7.6-1-src.tar.xz but the "install" command > >>> does not work. > >>> I'm getting this error message: > >>> > >>>>>> Installing glm-0.9.7.6-1.noarch > >>> make: *** Nessuna regola per generare l'obiettivo «install». Arresto. > >>> *** ERROR: make install DESTDIR failed > >>> > >>> Translated in english, it should be something like this: > >>> "No rules to generate target <>. Stop." > >>> > > [...] > >> > >> the error is caused by the build system using now cmake+ninja for > >> the execution > >> > >> while mingw64-i686-glm and mingw64-x86_64-glm builds stay on the > >> previous cmake+make > >> > > I am a bit confused by this. What causes the default generator used by > > cmake to change? Having old .cygports break due to that seems bad. > > > > not sure. > I guess that if ninja is available the glm cmake settings > give it a precedence. > > It is also possible that the latest cmake is behaving differently > than previous one. > > Regards > Marco > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Build of glm-0.9.7.6-1-src.tar.xz does not work.
Hello, I tried to rebuild glm-0.9.7.6-1-src.tar.xz but the "install" command does not work. I'm getting this error message: >>> Installing glm-0.9.7.6-1.noarch make: *** Nessuna regola per generare l'obiettivo «install». Arresto. *** ERROR: make install DESTDIR failed Translated in english, it should be something like this: "No rules to generate target <>. Stop." I did NO changes to the files into glm-0.9.7.6-1-src.tar.xz. Strangely, cygport cannot build the CYGWIN package, but it builds mingw64-i686-glm and mingw64-x86_64-glm without errors. The CYGWIN and MinGW-W64 scripts have some differences actually. If somebody could check this, perhaps it would be good to also evaluate the chance to update all GLM packages to a newer version. The current source packages for all builds, CYGWIN and MinGW-W64, include a patch for fixing a bug into the sources; nowadays, this bug has been resolved into the official sources and into the latest 0.9.9.8 version: https://github.com/g-truc/glm/blob/master/test/gtc/gtc_round.cpp#L451 so the packages could be also simplified, because they do not need a patch anymore. I'm trying to update GLM because it is a required dependency for building KiCad, an Open Source Electronics Design software, so I hope that somebody could understand the first issue and also update the package with a newer version. Sincerely, -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
MinGW pkg-config not working (part 2)
Hello, After the release of the new pkg-conf, with the use of symlinks instead of a script for using the personality feature, I got some strange errors at compile time. Let's think to have a directory called "mylibrary" into your home directory, so you have a path for example "/home/carlo/mylibrary". In this directory create a file called "test.pc" with these lines: Name: test Description: test MinGW pkg-config on CYGWIN Version: 1.2.3 Libs: Cflags: -I/home/carlo/mylibrary Finally, add this directory to PKG_CONFIG_PATH environment variable. Now, if you type this command on the console: $ x86_64-w64-mingw32-pkg-config --cflags test -I/usr/x86_64-w64-mingw32/sys-root/home/carlo/mylibrary which is wrong, because it changed all references to "home/carlo" by appending "/usr/x86_64-w64-mingw32/sys-root". Instead, if I type: $ pkg-config --cflags test -I/home/carlo/mylibrary then the path it returned unchanged as expected. Sadly, this behavior forces you to rebuild everything and to move all stuff that you could normally have in your home directory into "/usr/x86_64-w64-mingw32/sys-root/home/carlo", othewise it won't work anymore. Am I doing something wrong or it is the expected result and there is another way to make things working again? Thank you very much. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mingw pkg-config not working
Hello, I would like to report that I updated to the latest release, I tried to do some tests and it really seems that it has resolved the issue on my side. Thank you very much for your support. Sincerely, Carlo Bramini. Il giorno lun 6 apr 2020 alle ore 18:44 Yaakov Selkowitz ha scritto: > > On Sun, 2020-04-05 at 15:51 +0200, Carlo B. via Cygwin wrote: > > I wanted to report that I received a reply on the issue that I had opened > > here: > > > > https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 > > Thanks for following up. > > > The report has been closed and I got this reply: > > > > "You should use a symlink instead of a wrapper script when using the > > personality feature." > > > > I hope that somebody has understood what he means (posix is not > > exactly my primary platform) and it could be useful for fixing the > > issue. > > Yes, that gave me the information I needed. There is actually code > within pkgconf to automatically load $PREFIX.personality when called as > $PREFIX-pkg-config. This requires a packaging change on our end, which > I'm incorporating into the latest release. > > > Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. > > ha scritto: > > > Hello, > > > I implemented the solution to this problem as a patch to > > > pkgconf.cygport as requested. > > > I attached small patch to this email, which resolved the troubles with > > > CMake and Meson. > > > I hope that you will find it useful and some developers will gently > > > apply the correction to fix the issue. > > > > > > Thank you very much for your time and your support. > > > Sincerely, > > > > > > Carlo Bramini. > > > > > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > > > ha scritto: > > > > On 20/02/2020 11:06, Carlo B. wrote: > > > > [...] > > > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > > > example the one for i686 is: > > > > > > > > > > #!/bin/sh > > > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > > > > > But while this solution mostly works when you exec it from the command > > > > > line, it makes impossible to detect the presence of the tool from > > > > > meson and cmake build systems. > > > > > If you try to do this on the bash prompt, you get: > > > > > > > > > > $ i686-w64-mingw32-pkg-config --version > > > > > pkgconf: --version specified with other options or module names, > > > > > assuming --modversion. > > > > > Please specify at least one package name on the command line. > > > > > > > > > > and this is exactly what happens with those build systems (and perhaps > > > > > others, I don't know): it tries to call pkg-config with "--version" > > > > > and it executes the above script that calls pkgconf. But sadly, the > > > > > presence of the "--personality" option makes the process to fail, > > > > > because the "--version" is currently allowed only when no other > > > > > options are added. > > > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > > > > > I have also filed an issue here for pkgconf: > > > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > > > because the solution is actually to ignore the presence of the > > > > > "--personality" option when the "--version" is written, but > > > > > unfortunately I have not received any feedback. > > > > > > > > > > So, I'm also writing here, with the hope that you could find a > > > > > solution. > > > > [...] > > > > > > > > Thanks for reporting this issue. > > > > > > > > I guess the alternative to fixing pkgconf would be to modify those > > > > wrapper scripts to detect when the parameters are just '--version' (or > > > > equivalent) and not use --personality in that case? > > > > > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > > > see [1]) > > > > > > > > It's possible other distros have more sophisticated wrapper scripts, > > > > which avoid this problem? > > > > > > > > If you do write or discover some improved wrapper scripts, a patch to > > > > [1] to update them would be appreciated. > > > > > > > > [1] > > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 > > -- > Yaakov > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mingw pkg-config not working
Hello, I wanted to report that I received a reply on the issue that I had opened here: https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 The report has been closed and I got this reply: "You should use a symlink instead of a wrapper script when using the personality feature." I hope that somebody has understood what he means (posix is not exactly my primary platform) and it could be useful for fixing the issue. Thank you very much for your time. Sincerely, Carlo Bramini. Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. ha scritto: > > Hello, > I implemented the solution to this problem as a patch to > pkgconf.cygport as requested. > I attached small patch to this email, which resolved the troubles with > CMake and Meson. > I hope that you will find it useful and some developers will gently > apply the correction to fix the issue. > > Thank you very much for your time and your support. > Sincerely, > > Carlo Bramini. > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > ha scritto: > > > > On 20/02/2020 11:06, Carlo B. wrote: > > [...] > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > example the one for i686 is: > > > > > > #!/bin/sh > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > But while this solution mostly works when you exec it from the command > > > line, it makes impossible to detect the presence of the tool from > > > meson and cmake build systems. > > > If you try to do this on the bash prompt, you get: > > > > > > $ i686-w64-mingw32-pkg-config --version > > > pkgconf: --version specified with other options or module names, > > > assuming --modversion. > > > Please specify at least one package name on the command line. > > > > > > and this is exactly what happens with those build systems (and perhaps > > > others, I don't know): it tries to call pkg-config with "--version" > > > and it executes the above script that calls pkgconf. But sadly, the > > > presence of the "--personality" option makes the process to fail, > > > because the "--version" is currently allowed only when no other > > > options are added. > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > I have also filed an issue here for pkgconf: > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > because the solution is actually to ignore the presence of the > > > "--personality" option when the "--version" is written, but > > > unfortunately I have not received any feedback. > > > > > > So, I'm also writing here, with the hope that you could find a solution. > > [...] > > > > Thanks for reporting this issue. > > > > I guess the alternative to fixing pkgconf would be to modify those > > wrapper scripts to detect when the parameters are just '--version' (or > > equivalent) and not use --personality in that case? > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > see [1]) > > > > It's possible other distros have more sophisticated wrapper scripts, > > which avoid this problem? > > > > If you do write or discover some improved wrapper scripts, a patch to > > [1] to update them would be appreciated. > > > > [1] > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mingw pkg-config not working
Hello, I implemented the solution to this problem as a patch to pkgconf.cygport as requested. I attached small patch to this email, which resolved the troubles with CMake and Meson. I hope that you will find it useful and some developers will gently apply the correction to fix the issue. Thank you very much for your time and your support. Sincerely, Carlo Bramini. Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney ha scritto: > > On 20/02/2020 11:06, Carlo B. wrote: > [...] > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > example the one for i686 is: > > > > #!/bin/sh > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > But while this solution mostly works when you exec it from the command > > line, it makes impossible to detect the presence of the tool from > > meson and cmake build systems. > > If you try to do this on the bash prompt, you get: > > > > $ i686-w64-mingw32-pkg-config --version > > pkgconf: --version specified with other options or module names, > > assuming --modversion. > > Please specify at least one package name on the command line. > > > > and this is exactly what happens with those build systems (and perhaps > > others, I don't know): it tries to call pkg-config with "--version" > > and it executes the above script that calls pkgconf. But sadly, the > > presence of the "--personality" option makes the process to fail, > > because the "--version" is currently allowed only when no other > > options are added. > > And, for this reason, meson and cmake fail the detection of the tool. > > > > I have also filed an issue here for pkgconf: > > https://todo.sr.ht/~kaniini/pkgconf/10 > > because the solution is actually to ignore the presence of the > > "--personality" option when the "--version" is written, but > > unfortunately I have not received any feedback. > > > > So, I'm also writing here, with the hope that you could find a solution. > [...] > > Thanks for reporting this issue. > > I guess the alternative to fixing pkgconf would be to modify those > wrapper scripts to detect when the parameters are just '--version' (or > equivalent) and not use --personality in that case? > > These wrapper scripts are specific to cygwin (generated by the cygport, > see [1]) > > It's possible other distros have more sophisticated wrapper scripts, > which avoid this problem? > > If you do write or discover some improved wrapper scripts, a patch to > [1] to update them would be appreciated. > > [1] > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 pkgconf.cygport.patch Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
