mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2021-12-07T15:17:57+01:00https://git.ufz.de/mhm/mhm/-/issues/213LAI time coordinate needs proper clipping and selecting in v62021-12-07T15:17:57+01:00Robert SchweppeLAI time coordinate needs proper clipping and selecting in v6In branch mpr_finalize there is currently no check for LAI periods (daily time step, monthly time step, yearly time step, average monthly values). Prior, the stepping method was given in the namelist and then the correct period matching ...In branch mpr_finalize there is currently no check for LAI periods (daily time step, monthly time step, yearly time step, average monthly values). Prior, the stepping method was given in the namelist and then the correct period matching the simulation period was selected.
This feature needs to implemented as well. When reading the restart file or the data arrays from MPR, the LAI coordinate must be checked (against certain naming conventions) and array must then be selected. The check routine in read_nc `get_time_vector_and_select` is already there and the indexing is done already for the land_cover_periods. The LAI stepping method needs to be inferred and correctly set (not done so far).6.xRobert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/230MPI related bugs (failing check cases)2022-08-30T14:43:30+02:00Sebastian MüllerMPI related bugs (failing check cases)There seem to be some issues with MPI. We already disabled some check cases for MPI in `run_mhm_checks.py`:
```python
# case 5 and 7 don't work with MPI. case 4 has a bug working with ifort+debug
SKIP_CASES_MPI = ["case_04", "case_05", "...There seem to be some issues with MPI. We already disabled some check cases for MPI in `run_mhm_checks.py`:
```python
# case 5 and 7 don't work with MPI. case 4 has a bug working with ifort+debug
SKIP_CASES_MPI = ["case_04", "case_05", "case_07"]
```
And it seems we also need to add `"case_11"` there, since it fails occasionally for different reasons:
- https://git.ufz.de/muellese/mhm/-/jobs/355821
```bash
##################################################
# SUMMARY: case_11
##################################################
2 of 103 records differ
0 of 103 records differ more than 0.0001
Missing: b6_discharge.nc, b6_daily_discharge.out
```
- https://git.ufz.de/muellese/mhm/-/jobs/355446
```bash
b6_daily_discharge.out
6 of 6 records differ
6 of 6 records differ more than 0.0001
Differing: No, Day, Mon, Year, Qobs_0000000398, Qsim_0000000398
Shape missmatch: No (in: (59,), ref: (1461,)), Day (in: (59,), ref: (1461,)), Mon (in: (59,), ref: (1461,)), Year (in: (59,), ref: (1461,)), Qobs_0000000398 (in: (59,), ref: (1461,)), Qsim_0000000398 (in: (59,), ref: (1461,))
```
Maybe this is related to #220
For now I will disable case 11, but we need to keep track of it.v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/225mhm fails on restart run; Issue with the number of dimension slices of landco...2022-06-01T17:00:58+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.demhm fails on restart run; Issue with the number of dimension slices of landcover, soil and LAImhm fails on restart run.
@najafi found this error while trying to run subdaily runs from restart file. After further testing on test_domians, we were able to reproduce the issue.
It seems there is an Issue with the number of dimensi...mhm fails on restart run.
@najafi found this error while trying to run subdaily runs from restart file. After further testing on test_domians, we were able to reproduce the issue.
It seems there is an Issue with the number of dimension slices of landcover, soil and LAI, either the way it is read from the restart file or at some point after it. The point of failure is [here](https://git.ufz.de/mhm/mhm/-/blob/develop/src/common_mHM_mRM/mo_common_mHM_mRM_restart.f90#L62).
My hunch is its reading the `bnds` dimension from the restart files, as mhm makes complains like `landcover should be 1 but is 2`, `soil horizons should be 4 but its 2`, `LAI time slices should be 12 but is 2`. This `bnds` dimension in the restart file (what does it represent?) is the dimension which is 2 in the tests we made (Ahr setup, test domains) .
Following are the namelist files for the write restart and read restart steps from the test_domains check that is producing the error:
[mhm_write_restart_test_domains.nml](/uploads/72d30692d628bc981adb351866d988dd/mhm_write_restart_test_domains.nml)
[mhm_read_restart_test_domains.nml](/uploads/4b7e1533f4c8ce7472587260fdc48d53/mhm_read_restart_test_domains.nml)v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/222Ignored files need to be updated2022-06-17T21:00:15+02:00Sebastian MüllerIgnored files need to be updated```
test_domain/output_b1/**
!test_domain/output_b1/.gitkeep
test_domain_2/output/**
!test_domain_2/output/.gitkeep
test_domain/restart/**
!test_domain/restart/.gitkeep
test_domain_2/restart/**
!test_domain_2/restart/.gitkeep
``````
test_domain/output_b1/**
!test_domain/output_b1/.gitkeep
test_domain_2/output/**
!test_domain_2/output/.gitkeep
test_domain/restart/**
!test_domain/restart/.gitkeep
test_domain_2/restart/**
!test_domain_2/restart/.gitkeep
```v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/220mHM discharge.nc writing sometimes broken2022-09-07T13:45:57+02:00Stephan ThobermHM discharge.nc writing sometimes brokenUsers have reported that discharge.nc is not written correctly, see
https://github.com/mhm-ufz/mhm/discussions/49
discharge.nc uses var2nc subroutine and not latest netcdf library. This should be changed as other nc files are written co...Users have reported that discharge.nc is not written correctly, see
https://github.com/mhm-ufz/mhm/discussions/49
discharge.nc uses var2nc subroutine and not latest netcdf library. This should be changed as other nc files are written correctly in the occuring cases.v5.12Pallav Kumar Shresthapallav-kumar.shrestha@ufz.dePallav Kumar Shresthapallav-kumar.shrestha@ufz.dehttps://git.ufz.de/mhm/mhm/-/issues/203internal calibration and FinalParam.nml (processCase(3) = 4 and processCase(5...2021-09-19T03:07:51+02:00Mehmet Cüneyd Demirelinternal calibration and FinalParam.nml (processCase(3) = 4 and processCase(5) = -1)Dear @muellese
When the user calibrates the model with these options (processCase(3) = 4 and processCase(5) = -1) using DDS method and KGE (opti 9), the resultant best parameter file (FinalParam.nml) contains &soilmoisture1 and &PET0 i...Dear @muellese
When the user calibrates the model with these options (processCase(3) = 4 and processCase(5) = -1) using DDS method and KGE (opti 9), the resultant best parameter file (FinalParam.nml) contains &soilmoisture1 and &PET0 instead of &soilmoisture4 and &PETminus1.
This seems to be a small bug.
[ConfigFile.log](/uploads/6240754c106a349f9646f8e196d0bdaf/ConfigFile.log)
[dds_results.out](/uploads/61e3bd30c6ee876a0d80cfc97be606d5/dds_results.out)
[FinalParam.nml](/uploads/5dc78c9592af4008a14a42f2e8b299d6/FinalParam.nml)
[FinalParam.out](/uploads/9a83c27d64e5ffef1a77537352f5815f/FinalParam.out)Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/200check_dir behaves differently with Intel (18) and GNU (83)2023-01-30T16:06:04+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.decheck_dir behaves differently with Intel (18) and GNU (83)The `check_dir` subroutine behaves differently with intel and gnu for long directory paths. Gnu works fine with long directories while executable compiled with Intel, for some reason, introduces a line break during the check. As a result...The `check_dir` subroutine behaves differently with intel and gnu for long directory paths. Gnu works fine with long directories while executable compiled with Intel, for some reason, introduces a line break during the check. As a result, Intel compiled executable always has False value for check_dir for long directory paths. Screenshots below -
**with GCC83**
![Screenshot_2021-08-05_at_22.09.54](/uploads/9ed3f187dfbd2d622c747beed52e0993/Screenshot_2021-08-05_at_22.09.54.png)
**with Intel18**
![Screenshot_2021-08-05_at_22.12.57](/uploads/c8c7cbb20acc60075aedcee486ff0947/Screenshot_2021-08-05_at_22.12.57.png)
Similar issue with line breaks was encountered in #40 which could already provide some clues to debug this.v5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/197UBUNTU LTS 20.4: Couldn't read `mhm.nml` - EOF error2021-07-14T09:46:27+02:00Mehmet Cüneyd DemirelUBUNTU LTS 20.4: Couldn't read `mhm.nml` - EOF errorHi @muellese and @thober,
I am getting the following error when running calibration with one or two basins using
optimize=true, opti_function = 1, opti_method = 1. I believe that other options hit on the same wall/bug which seems to req...Hi @muellese and @thober,
I am getting the following error when running calibration with one or two basins using
optimize=true, opti_function = 1, opti_method = 1. I believe that other options hit on the same wall/bug which seems to require a simple .f90 editing.
![image](/uploads/ae77991a25637c202f48d65d3cc540dd/image.png)
p.s. I compile the mhm-develop using the codes below.
```bash
sudo apt-get install gfortran netcdf-bin libnetcdf-dev libnetcdff-dev cmake
wget https://git.ufz.de/mhm/mhm/-/archive/develop/mhm-develop.tar.gz
tar -zxvf mhm-develop.tar.gz
cd mhm-develop
mkdir build
cd build
cmake -DCMAKE_WITH_OpenMP:STRING=ON -DCMAKE_BUILD_TYPE=Release ..
make
cp ./mhm ..
cd ..
./mhm
```
Cheers,
CüneydSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/194With mHM - v5.11.1 (segmentation issue - when routing process switched off i....2021-07-08T18:27:28+02:00Eshrat Fatimaeshrat.fatima@ufz.deWith mHM - v5.11.1 (segmentation issue - when routing process switched off i.e., processCase(8) = 0)At line 217 of file /cygdrive/d/mhm-v5.11.1/src/mHM/mo_mhm_read_config.f90 (unit = 30, file = 'mhm.nml')
Fortran runtime error: ![Error](/uploads/84d7f989310060d9a7db17028d5d57f9/Error.PNG)At line 217 of file /cygdrive/d/mhm-v5.11.1/src/mHM/mo_mhm_read_config.f90 (unit = 30, file = 'mhm.nml')
Fortran runtime error: ![Error](/uploads/84d7f989310060d9a7db17028d5d57f9/Error.PNG)v5.11.2Rohini KumarRohini Kumarhttps://git.ufz.de/mhm/mhm/-/issues/160cmake error in compiling mhm-develop2020-11-30T14:16:48+01:00Mehmet Cüneyd Demirelcmake error in compiling mhm-developDear @muellese and @thober
I get the following cmake errors. I tried bringing cmake related files from v5.10_fixed but didnt help.
![image](/uploads/4154d36f744e1631ad510adf8080d7b2/image.png)
Also I don't see MakeFile in https://g...Dear @muellese and @thober
I get the following cmake errors. I tried bringing cmake related files from v5.10_fixed but didnt help.
![image](/uploads/4154d36f744e1631ad510adf8080d7b2/image.png)
Also I don't see MakeFile in https://git.ufz.de/mhm/mhm.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/147fate of MHM2MRM definition2020-10-08T12:03:47+02:00Robert Schweppefate of MHM2MRM definitionCurrently, there is this line in the top-level `CMakeLists.txt`:
```
cpp_definitions("-DMRM2MHM" "CMAKE_MRM2MHM" "ON" "If set to ON the model runs with mRM")
```
so that we be default compile mHM with mRM. If one would turn it off, ther...Currently, there is this line in the top-level `CMakeLists.txt`:
```
cpp_definitions("-DMRM2MHM" "CMAKE_MRM2MHM" "ON" "If set to ON the model runs with mRM")
```
so that we be default compile mHM with mRM. If one would turn it off, there will be errors, e.g:
```
Error: Symbol ‘kge_q’ at (1) has no IMPLICIT type; did you mean ‘kge_et’?
/Users/ottor/nc/Home/local_libs/fortran/mhm_mpr/src/mHM/mo_objective_function.f90:854:63:
854 | call init_indexarray_for_opti_data(domainMeta, 1, nQDomains, opti_domain_indices_Q)
| 1
Error: Symbol ‘nqdomains’ at (1) has no IMPLICIT type; did you mean ‘netdomains’?
```
because `nQDomains` is defined within the `#def MHM2MRM` block but also called outside it.
What is the policy on the MHM2MRM definition (@muellese, @thober)?
- keep it, then we should also test it and fix it (maybe @kaluza?)!
- drop it, then we can get rid of it altogether!5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/142[EVE] NAG loadscript loads wrong netcdf version2020-08-31T16:23:44+02:00Sebastian Müller[EVE] NAG loadscript loads wrong netcdf versionThe module versions in the NAG load scripts are not fixed so they are loading wrong modules now.The module versions in the NAG load scripts are not fixed so they are loading wrong modules now.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/140Hacky output dirs in test cases2020-11-30T08:58:34+01:00Sebastian MüllerHacky output dirs in test casesMost output directories for the test-cases are given with sth like `output_b1/b1_`.
But this is just a hack to prepend a prefix `b1_` to the output files.
When there will be checks for folders with automatically creation in the future, t...Most output directories for the test-cases are given with sth like `output_b1/b1_`.
But this is just a hack to prepend a prefix `b1_` to the output files.
When there will be checks for folders with automatically creation in the future, this would create two folders `output_b1/b1_/` with the output files in `b1_/`.
This is related to !415.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/131L0 resolutions with repeating decimals2022-07-07T10:38:33+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deL0 resolutions with repeating decimals**Background**
* MERIT DEM is at 3 arc seconds i.e. 0 deg 0 min 3 secs OR 0.00083333.....33333…..
* I use ASCII input format. All of input .asc files and header.txt have the L0 resolution in decimal degrees.
**Issue**
* I noticed that...**Background**
* MERIT DEM is at 3 arc seconds i.e. 0 deg 0 min 3 secs OR 0.00083333.....33333…..
* I use ASCII input format. All of input .asc files and header.txt have the L0 resolution in decimal degrees.
**Issue**
* I noticed that in order to avoid truncation errors the user needs to enter a lot of decimal places in the .asc files and header.txt. E.g. 18 decimal places were not enough. So I entered 100 decimal places - worked. (note: the error occurs at lines 546-547 of mo_grid.f90, calculation of xllcorner and yllcorner from L0 and L2 resolutions)
**Solution (?)**
* In mHM we have two coordinate systems - metric and lat lon. The latter has numeral format of decimal degrees. However, data which come as deg-min-sec when converted to decimal degrees could bear “repeating decimals” leading to truncation errors as in case of MERIT DEM resolution.
* Wouldn’t it be better if users had the option to enter the resolution in deg-min-sec or decimal degrees as deemed fit? That would be more elegant/ intuitive than entering a lot of decimal places.
* I don’t have experience in using .nc files for L0 data (except lai.nc). Does that solve this issue already?v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/128mHM initialization fails for small basins: percentile_0d_dp: n < 22020-09-15T17:19:28+02:00Oldrich RakovecmHM initialization fails for small basins: percentile_0d_dp: n < 2Hi @thober @shresthp (cc @kaluza)
[update 6.7.2020]
After re-running all the 5000+ global basins with the latest mHM develop setup, routing process = 3;
20% of the basin runs are broken during the mRM initialization due to `percentile_0...Hi @thober @shresthp (cc @kaluza)
[update 6.7.2020]
After re-running all the 5000+ global basins with the latest mHM develop setup, routing process = 3;
20% of the basin runs are broken during the mRM initialization due to `percentile_0d_dp: n < 2`
That was not the case earlier (with revision 8271b54 and routing process = 2).
Initially I thought it came with with the bugfix in `./src/mRM/mo_mrm_net_startup.f90` saying:
```fortran
! Stephan Thober, Pallav Kumar Shrestha, Sep 2020 - bug fix in cut off Length at 40 percentile, neglecting links with -9999. that occur if multiple outlets are present
```
lines 1434-1438:
```fortran
! cut off Length at 40 percentile to neglect short paths in headwaters
if ((processMatrix(8, 1) .eq. 2) .or. (processMatrix(8, 1) .eq. 3)) then
length = percentile(pack(nLinkLength(:), nLinkLength(:) .ge. 0._dp), 40._dp)
nLinkLength(:) = merge(nLinkLength(:), length, (nLinkLength(:) .gt. length))
end if
```
But it looks the reason is elsewhere, after rolling it back prior the aforementioned bugfix.
Any hints appreciated (? @kaluza )
Thanks,
Olda5.11Maren KaluzaMaren Kaluzahttps://git.ufz.de/mhm/mhm/-/issues/127mLM fork: Provision for lakes that outflows directly to another lake2020-07-02T00:14:04+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.demLM fork: Provision for lakes that outflows directly to another lake**Background**
* There would be cases in which a reservoir lake extent would extend upstream such that it reaches the outflow L0 of upstream reservoir lake.
* Or there could be natural lakes where the lake downstream has extent up to t...**Background**
* There would be cases in which a reservoir lake extent would extend upstream such that it reaches the outflow L0 of upstream reservoir lake.
* Or there could be natural lakes where the lake downstream has extent up to the waterfall L0 cell of the upstream lake.
**Issue**
* The code at the moment only checks nodes for being outlets and not lakes as in aforementioned cases.
* Conversely, it could be that the reservoirs are close to each other but not connected. However, if user gives high values for dam crest level of downstream reservoir, this condition can (erroneously) arise.
* I came across such case in Khuzestan where the lake of Masjed e-Soleyman (downstream) extended up to the outflow L0 cell of Shahid Abbaspour reservoir (upstream) with high dam crest level.
![image](/uploads/2f6dce62b770979dfe760feca33fe789/image.png)
**Solution**
* There needs to be a provision where lakes are checked for being lake outlets of upstream lakes.
* If such cases arise, which would be very rare, the user is informed at runtime with lake indices of the upstream-downstream lakes
* User is also provided with the hint that lowering dam crest level of the downstream dam may solve the issue, in case the lake connection is erroneous.
* Lowering of the dam crest level for Masjed e-Soleyman (downstream reservoir) helped to avoid this situation as follows -
![image](/uploads/5508fc5c43b75bc34a6b8fd68b1f4795/image.png)Pallav Kumar Shresthapallav-kumar.shrestha@ufz.dePallav Kumar Shresthapallav-kumar.shrestha@ufz.dehttps://git.ufz.de/mhm/mhm/-/issues/126use of ceiling in calculate_grid_properties2022-07-07T10:38:33+02:00Stephan Thoberuse of ceiling in calculate_grid_propertiesHi Robert,
in calculate_grid_properties in mo_grid, the Fortran intrinsic ceiling is used to calculate Ncols, Nrows. If the cell factor is close to 1, but not exactly one, this can lead to additional rows and cols. I changed to nint in ...Hi Robert,
in calculate_grid_properties in mo_grid, the Fortran intrinsic ceiling is used to calculate Ncols, Nrows. If the cell factor is close to 1, but not exactly one, this can lead to additional rows and cols. I changed to nint in Ulysses. Do you have any objection to changing it in mhm develop too?
Thanks
Stephan
p.s.: This is my last message during my holidays ;)v5.12Robert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/121PGI-Fortran support2022-04-28T15:23:40+02:00Sebastian MüllerPGI-Fortran supportWe now have the PGI Fortran compiler on EVE (https://git.ufz.de/it/eve/software/-/issues/176).
ATM there are some problems/bugs that need to be resolved in order to make it work:
* [x] we need a load-script for the PGI compiler on EVE
*...We now have the PGI Fortran compiler on EVE (https://git.ufz.de/it/eve/software/-/issues/176).
ATM there are some problems/bugs that need to be resolved in order to make it work:
* [x] we need a load-script for the PGI compiler on EVE
* [ ] in `mhm_driver.f90`:
* the pointer `eval` should be of type `eval_interface` from `mo_optimization_utils`
https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mhm_driver.f90#L172
* the pointer `obj_func` should be of type `objective_interface` from `mo_optimization_utils`
https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mhm_driver.f90#L173
* [ ] in https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_read_latlon.f90#L106, an error occures:
```
0: SHAPE: arg not associated with array
```
(very descriptive) ... my educated guess is, that PGI has a problem with the generic procedures in `mo_netcdf` (https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_read_latlon.f90#L106)
* [ ] there are a lot of pre-processor directives across the code-base to handle PGI-Fortran compilation. We would need to test, which of these are still necessary and if we would need more of them to handle problems like the one described above (what a mess)
* [ ] is it worth the hassle?
List TBC...v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/107hourly meteo forcing nc2023-01-12T11:13:47+01:00Stephan Thoberhourly meteo forcing ncThis is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this...This is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this already long time ago…
FYI, I have attached 3-meteo files with modified time step for the test basin at hourly time,
This can be used in the test example with modified time window:
```fortran
warming_Days(1) = 0
!> first year of wanted simulation period
eval_Per(1)%yStart = 1989
!> first month of wanted simulation period
eval_Per(1)%mStart = 01
!> first day of wanted simulation period
eval_Per(1)%dStart = 02
!> last year of wanted simulation period
eval_Per(1)%yEnd = 1989
!> last month of wanted simulation period
eval_Per(1)%mEnd = 02
!> last day of wanted simulation period
eval_Per(1)%dEnd = 02
```
The first thing is that `./src/common/mo_read_forcing_nc.f90` fails to recognize, these data are at hourly time step.
If `inctimestep` is hardcoded in there to `-4`, then seq fault occurs later in the code.
I did not go deeper, but just want to confirm, there is an issue to be checked.
Thanks!
Best regards,
Olda
[pet.nc](/uploads/042c56ffde633de2f2efb26a126d6c2a/pet.nc)
[tavg.nc](/uploads/005f8ee487b8fa381e8def6fcf7432b2/tavg.nc)
[header.txt](/uploads/4ae6bdb6d30e8de7a3a1cf0fa499dbf2/header.txt)
[pre.nc](/uploads/71f9ed2044168a54a6a9c1bb5bddf115/pre.nc)v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/100Bsymbolic flag in makefile (cmake error)2020-12-01T09:30:59+01:00Mehmet Cüneyd DemirelBsymbolic flag in makefile (cmake error)In Ubuntu TLS (win10), the -Bsymbolic is causing compilation error at the latest stage (100%). After removing it, compilation is successful. May be this is not a bug but a suggestion. @kaluza @thober @ottor
![B3122BDE-52BC-4104-A0F6-A9...In Ubuntu TLS (win10), the -Bsymbolic is causing compilation error at the latest stage (100%). After removing it, compilation is successful. May be this is not a bug but a suggestion. @kaluza @thober @ottor
![B3122BDE-52BC-4104-A0F6-A9563A5B68EB](/uploads/75ff0cccd63a7f7ea46c16ebd3e03782/B3122BDE-52BC-4104-A0F6-A9563A5B68EB.jpeg)
https://stackoverflow.com/questions/15090198/ld-unknown-option-bsymbolic-when-trying-to-build-iniparser-on-osx5.11Sebastian MüllerSebastian Müller